On 05/31/2012 01:57 PM, Alex Jia wrote:
> 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 may be different from my environment, I have directly installed a VM 
on the host
instead of using virt-v2v to covert a existing ESX VM into rhevm/ovirt, 
I guess it's a
reason why VM ip address hasn't been cache into network leases.
>>> 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

_______________________________________________
Autotest mailing list
[email protected]
http://test.kernel.org/cgi-bin/mailman/listinfo/autotest

Reply via email to