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.
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.
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.
---
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?
--
Chris Evich, RHCA, RHCE, RHCDS, RHCSS
Quality Assurance Engineer
e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214
_______________________________________________
Autotest-kernel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/autotest-kernel
