On Monday 15 October 2012 09:55:30 you wrote: > On 10/11/2012 11:08 AM, Plamen Dimitrov wrote: > > Dear autotest team, > > > > we need to execute tests on multiple virtual machines running in parallel. > > > > After spending some time trying to find a way to do it, possibly without > > any significant modification, we figured out the cheapest way is to start > > all of them with the "vms" parameter and then switch the "main_vm" > > parameter to run every test safely. > > > > However, a problem we encountered was that the "env" file was constantly > > matched/unmatched which led to multiple redundant starts and shutdowns > > of each VM as well as "Inappropriate ioctl for device" errors. > > > > Is this the best practice way to do this? If so, should we do something > > else? And lastly, shouldn't the cache keep information only about the VMs > > and not about which of them we use for testing at a given moment? > > > > Here is an extraction of the log file to clarify what I am talking about > > if someone needs more information about the errors. > > > The two VMs are intranator1 and intranator2: > Your use of "vms" is correct, but "main_vm" (and changing params during > testing) is ripe for problems :) "main_vm" is really a awkward name, > really it's meaning is "default VM" (the one to use when none is > specifically targeted). > > If you can, I would recommend trying to solve the problem within the > Cartesian system as much as possible. The env setup we have is keyed by > vm name, so define vm1...vmX for all the many types you'll need (ie. > total Cartesian combination result. > While my custom tests are actually made to work with multiple vms, the problem that I meant originally is in some very basic cases like the "install" (kvm steps) test. It only takes the "main_vm" as a parameter and works with it throughout the entire test. The usage of the "main_vm" parameter was mainly to cheat this test into installing multiple vms one after another.
> Then make several variant blocks and/or nested blocks to account for the > other changing variables. For each test variant, specify a unique set > of vms=vmX...vmY and main_vm= combination. > Using a different "main_vm"-"vms" combination is still the same trick because I simply add "main_vm" as an overwrite string before parsing. What I rather did regarding the other changing variables is that I developed a utility to read the "vms" parameter and append a "_*vmname*" postfix to each vm specific parameter. In this way I use this wonderful idea from autotest's "Params" class about dividing parameters according to postfixes. > The virttest/env_process module should then recognize the prior test's > vmA...vmB names aren't needed, and shut them down while starting up the > new vmX...vmY. In cases that make sense, the vm's can share image_name > and other parameters, only the names change. > So, even if I specify different test variants the install test as well as some other very basic virtual tests will still work only with the "main_vm". I now have the customized parameters parsed appropriately for each vm, but it seems the pre- or postprocessing experience cache matching as well as nic problems with this. > > This "10/11 16:29:14 INFO | aexpect:0786| [qemu output] qemu-kvm: > -netdev tap,id=idjGrywq,fd=37: TUNGETIFF ioctl() failed: Inappropriate > ioctl for device" I believe was a bug lmr solved a few months ago. > IIRC, it was caused in vm.create() because tap was being on the bridge. > Are you running older code or are we maybe seeing a new (similar) bug? I am running version 0.15.0-rc0. Actually most of the problems in the log I pasted arise mainly from this test and from the vm processing. The test seems to change some parameters in the vm to cause vm reset while at the same time finding a problem in the other vm (the nic problem due to the vm still not having OS I suppose). _______________________________________________ Autotest-kernel mailing list [email protected] https://www.redhat.com/mailman/listinfo/autotest-kernel
