On 05/31/2012 05:25 PM, Alex Jia wrote:
> 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
s/have/haven't/
> 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
>>>>>> Autotest@test.kernel.org
>>>>>> http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
>> _______________________________________________
>> Autotest mailing list
>> Autotest@test.kernel.org
>> http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
> _______________________________________________
> Autotest mailing list
> Autotest@test.kernel.org
> http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
_______________________________________________
Autotest mailing list
Autotest@test.kernel.org
http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
