Michael Goldish 写道:
----- "jason wang" <jasowang@xxxxxxxxxx> wrote:
sudhir kumar 写道:
Hi Uri/Lucas,
Do you have any plans for enhancing kvm-autotest?
I was looking mainly on the following 2 aspects:
(1).
we have standalone migration only. Is there any plans of enhancing
kvm-autotest so that we can trigger migration while a workload is
running?
Something like this:
Start a workload(may be n instances of it).
let the test execute for some time.
Trigger migration.
Log into the target.
Check if the migration is succesful
Check if the test results are consistent.
We have some patches of ping pong migration and workload adding. The
migration is based on public bridge and workload adding is based on
running benchmark in the background of guest.
(2).
How can we run N parallel instances of a test? Will the current
configuration be easily able to support it?
Please provide your thoughts on the above features.
The parallelized instances could be easily achieved through
job.parallel() of autotest framework, and that is what we have used in
our tests. We have make some helper routines such as get_free_port to
be reentrant through file lock.
We'll probably have to use file locks anyway when we work with TAP, but in
VM.create(), not in get_free_port(), because we also want to prevent parallel
qemu instances from choosing the same TAP device. I'm not sure how qemu
handles this internally, and I'd rather be on the safe side.
Do you release the file lock inside get_free_port or only after running qemu?
We record the port usage and release the file lock inside
get_free_port(). I agree with you that it's better to get/release the
file lock in VM.create() because it is easier and it also eliminates the
effort of doing lock in every helper function.
For the TAP device, maybe we could give each TAP device used by qemu-kvm
an random generated ifname to prevent qemu-kvm from choosing the same
TAP devices. This method works well in our test.
We've implemented following test cases: timedrift(already sent here),
savevm/loadvm, suspend/resume, jumboframe, migration between two
machines and others. We will sent it here for review in the following
weeks.
There are some other things could be improved:
1) Current kvm_test.cfg.sample/kvm_test.cfg is transparent to autotest
server UI. This would make it hard to configure the tests in the
server
side. During our test, we have merged it into control and make it
could
be configured by "editing control file" function of autotest server
side web UI.
Would it not suffice to just modify the configuration, instead of completely
define it, inside the control file? This is possible using parse_string().
For example:
cfg = kvm_config.config("kvm_tests.cfg")
cfg.parse_string("only weekly")
cfg.parse_string("only Fedora RHEL Windows")
cfg.parse_string("""
variants:
- 1:
only ide
- 2:
Fedora:
no rtl8139
""")
list = cfg.get_list()
(get_list() returns the test dictionaries.)
The advantage here is that we can have a standard kvm_tests.cfg that we all
agree on and only rather small environment-specific modifications are made
in the control file.
Thanks, this way makes the things easier.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
