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 > 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 -- 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
