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? 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. 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
