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