2009/5/14 sudhir kumar <smalikphy@xxxxxxxxx>: > 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? > >>> >>> (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 Did you send the patch on the mailing list? Can you please point me to it. In my knowledge -redir tcp *:* breaks with -net tap. If running an external dhcp/dns server is the solution then the patch should go in. Thanks in advance!! >> 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. >> >> > > > > -- > Sudhir Kumar > -- 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
