On 05/30/2012 07:43 PM, Cleber Rosa wrote:
> On 05/30/2012 07:52 AM, Alex Jia wrote:
>> On 05/30/2012 06:00 PM, Cleber Rosa wrote:
>>> On 05/30/2012 12:59 AM, Alex Jia wrote:
>>>> On 05/29/2012 10:52 PM, Chris Evich wrote:
>>>>> Alex,
>>>>>
>>>>> Interesting problem, these functions are sensitive because they
>>>>> happen
>>>>> in the context of an autotest test, but outside a virtualization
>>>>> sub-test. Probably the 'right' way to do this is starting with
>>>>> virt_test:virt_test class and make the calls to preprocess,
>>>>> postprocess_on_error, and postprocess more flexible. Perhaps they
>>>>> could be pulled in from test_module similar to run_func?
>>>>>
>>>>> The other item you may consider is, if there are only specific parts
>>>>> of pre/post process you need to run on remote host. If so, maybe the
>>>>> easy answer is to have wrap them in a check for a new params key that
>>>>> makes them run remotely.
>>>> Yeah, we have similar idea, thanks for sharing your idea.
>>>>> As for tcpdump, how exactly is it not valid? If it's related to the
>>>>> 1-hour time, this is 'timeout' parameter which defaults to 3000
>>>>> seconds. Just set it for your install test to something longer.
>>>>> Otherwise, I'm not sure I follow what you need it to do differently,
>>>>> please explain.
>>>> Yeah, I may increase timeout to resolve it such as 3600s, the
>>>> problem is
>>>> users can't stand to get a ip
>>>> more than 1 hour, however, I verified it on rhevm/ovirt via tcpdump
>>>> method to monitor 68 port,
>>>> as usual, it will be more than 1 hour, at present, I try to git
>>>> guest ip
>>>> via GA in rhevm/ovirt.
>>>
>>> First, let me see If I understand this correctly: somehow the
>>> combination of tcpdump + the network config/stack in an rhev-h/ovirt
>>> node takes about 1 hour to get an IP?
>> Yeah, I used a rhel6 OS as a ovirt node then install a VM in it.
>>>
>>> This reminds me of something I thought a while ago, when we decided
>>> to go with the libvirt private bridge as the default network for the
>>> KVM test: the dnsmasq daemon, which answers the DHCP requests, can
>>> be easily queried for leases, which can resolve the MAC -> IP for
>>> guests.
>> It's not always valid by querying leases, I often met IP isn't in
>> leases case, in addition, 'nmap' works well for us, however, it may
>> be not common
>> method on other platform, I think tcpdump should be more powerfull
>> and popular, so I also like it.
>
> Well, IMHO if a DHCP server (dnsmasq) provides that feature (querying
> leases) and a given lease is not returned in a query result, then
> that's a bug.
>
> BTW, would you care to explain how you're using nmap for that kind of
> resolution? Some kind of reverse ARP?
Basically, using nmap to scan guest subnet, you may paste the following shell
codes into mac2ip.sh:
#! /bin/bash
if [ $# -ne 2 ]; then
echo "Usage: $(basename $0)<SUBNET> <MAC>"
exit 1
fi
SUBNET=$1
MAC=$2
rpm -q nmap> /dev/NULL
if [ $? -ne 0 ]; then
echo "you need install nmap"
exit 1
fi
if [[ -n $SUBNET ]]; then
OUTPUT=$(nmap -sP -n $SUBNET | grep -i -B 2 $MAC)
if [[ -n $OUTPUT ]]; then
IP=$(echo $OUTPUT | sed -e 's/.*
\([0-9]*\.[0-9]*\.[0-9]*\.[0-9]*\).*/\1/')
fi
fi
echo $IP
And then run the following cmdline:
% mac=$(virsh dumpxml ${your domain name} | grep "mac address" | awk -F"'"
'{print $2}' | head -1)
% subnet=$(ip route | grep "${your guest interface}" | sed -n 1p | awk '{print
$1}')
% sh mac2ip.sh $subnet $mac
Note: for instance, your guest name is 'foo', and interface is 'virbr0'
>
> Thanks.
>
>>>
>>> That way, we could drop the requirement and the way we use tcpdump,
>>> which IMHO is as a nice little hack that we could live without.
>>>
>>>>> Thanks.
>>>>>
>>>>> On 05/29/2012 04:57 AM, Alex Jia wrote:
>>>>>> Hi Chris,
>>>>>> I have some new requirements for network relevant stuff recently, we
>>>>>> have
>>>>>> preprocess and postprocess functions in
>>>>>> ./client/virt/virt_env_process.py
>>>>>> module, at present, I need to run them on target host rather than
>>>>>> local
>>>>>> host, whether we may expend these 2 functions to support remotely
>>>>>> run?
>>>>>>
>>>>>> Another question, "tcpdump -npvi any 'dst port 68'" isn't always
>>>>>> valid in
>>>>>> preprocess function, for rhevm/ovirt, as usual, I need more than 1
>>>>>> hour to
>>>>>> get guest ip address, I used default rhevm network configuration
>>>>>> without
>>>>>> any modification, I guess it has relationship with /etc/resolv.conf,
>>>>>> which
>>>>>> is automatically generated by /sbin/dhclient-script, whether we
>>>>>> may find
>>>>>> a common/quick method to resolve the issue?
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Alex
>>>>>>
>>>>>>
>>>>>> Additional information:
>>>>>>
>>>>>> # ps -ef|grep [d]hclient
>>>>>> root 2101 1 0 May11 ? 00:00:01 /sbin/dhclient -1 -q
>>>>>> -lf /var/lib/dhclient/dhclient-rhevm.leases -pf
>>>>>> /var/run/dhclient-rhevm.pid rhevm
>>>>>>
>>>>>> # cat /etc/sysconfig/network-scripts/ifcfg-rhevm
>>>>>> DEVICE=rhevm
>>>>>> TYPE=Bridge
>>>>>> ONBOOT=yes
>>>>>> DELAY=0
>>>>>> IPV6FORWARDING=no
>>>>>> IPV6INIT=no
>>>>>> SKIPLIBVIRT=True
>>>>>> DELAY=0
>>>>>> BOOTPROTO=dhcp
>>>>>> IPV6_AUTOCONF=no
>>>>>> PEERNTP=yes
>>>>>> ONBOOT=yes
>>>>>>
>>>>>> # ifconfig rhevm
>>>>>> rhevm Link encap:Ethernet HWaddr B8:AC:6F:3E:62:75
>>>>>> inet addr:xx.xx.xx.xx Bcast:xx.xx.xx.255
>>>>>> Mask:255.255.254.0
>>>>>> inet6 addr: fe80::baac:6fff:fe3e:6275/64 Scope:Link
>>>>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>>>>>> RX packets:4056726459 errors:0 dropped:0 overruns:0
>>>>>> frame:0
>>>>>> TX packets:1678987190 errors:0 dropped:0 overruns:0
>>>>>> carrier:0
>>>>>> collisions:0 txqueuelen:0
>>>>>> RX bytes:4052148544568 (3.6 TiB) TX bytes:3904959346163
>>>>>> (3.5 TiB)
>>>>>>
>>>>>> # cat /etc/resolv.conf
>>>>>> ; generated by /sbin/dhclient-script
>>>>>> search xx.xx.redhat.com xx.xx.xx.xx.redhat.com
>>>>>> nameserver xx.xx.xx.xx
>>>>>> nameserver xx.xx.xx.xx
>>>>>> nameserver xx.xx.xx.xx
>>>>>
>>>> _______________________________________________
>>>> Autotest mailing list
>>>> [email protected]
>>>> http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
>>>
>>
>
_______________________________________________
Autotest mailing list
[email protected]
http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
