Michael Goldish 写道:
----- "sudhir kumar" <smalikphy@xxxxxxxxx> wrote:
On Thu, May 14, 2009 at 12:22 PM, 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.
Cool. I would like to have look on them. So how do you manage the
background process/thread?
Yes, we would try to sent it here as soon as possible. The background
workload could be added through various methods. We could an simple
algorithm as follows:
run_migration2():
pid = run_autotest_background(test,params,env,"dbench","control.60")
Do ping-pong migration ...
wait_autoteset_background(pid)
run_autotest_background() would fork a subprocess to run function
run_autotest() and catch its exception.
wait_autotest_background(pid) would wait until the background benchmark
complete and analyse the result through the return value of the subprocess.
The child process could work well depends the fact that the ssh
connection should alive during migration.
I believe this could be also achieved through job.parallel()
(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'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.
Not much clue here. But I would like to keep the control file as
simple as possible and as much independent of test scenarios as
possible. kvm_tests.cfg should be the right file untill and unless it
is impossible to do by using it.
2) Public bridge support: I've sent a patch(TAP network support in
kvm-autotest), this patch needs external DHCP server and requires
nmap
support. I don't know whether the method of original
kvm_runtes_old(DHCP
server of private bridge) is preferable.
The old approach is better. All might not be able to run an external
DHCP server for running the test. I do not see any issue with the old
approach.
We're taking more of a minimalist approach in kvm_runtest_2: the
framework should handle only the things directly related to testing.
Configuring and running a DHCP server is and should be beyond the scope
of the KVM-Autotest framework. To emulate the old behavior, you can just
start the DHCP server yourself locally. If you wish, maybe we can
bundle example scripts with the framework that will do this for the user,
but they should not be an integral part of the framework in my opinion.
--
Sudhir Kumar
--
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
--
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
