sudhir kumar 写道: > 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!! > Thanks for pointing out this problem. The redirections indeed breaks the tap networking. TAP patch could be seen at http://marc.info/?l=kvm&m=124221382604554&w=2. The redirections also leads the problems of getting the ip address of a user mode nic. So maybe we could make the tap/user to be an exclusive option. >>> 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
