From mboxrd@z Thu Jan 1 00:00:00 1970 From: jason wang Subject: Re: kvm-autotest: The automation plans? Date: Fri, 15 May 2009 16:40:55 +0800 Message-ID: <4A0D2A97.9070909@redhat.com> References: <1660154190.211661242298240521.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: sudhir kumar , kvm@vger.kernel.org, uril@redhat.com, mrodrigu@redhat.com To: Michael Goldish Return-path: Received: from mx2.redhat.com ([66.187.237.31]:35876 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756159AbZEOIlL (ORCPT ); Fri, 15 May 2009 04:41:11 -0400 In-Reply-To: <1660154190.211661242298240521.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Michael Goldish =E5=86=99=E9=81=93: > ----- "sudhir kumar" wrote: > > =20 >> On Thu, May 14, 2009 at 12:22 PM, jason wang >> wrote: >> =20 >>> sudhir kumar =E5=86=99=E9=81=93: >>> =20 >>>> 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. >>>> >>>> =20 >>> We have some patches of ping pong migration and workload adding. >>> =20 >> The >> =20 >>> migration is based on public bridge and workload adding is based on >>> =20 >> running >> =20 >>> benchmark in the background of guest. >>> =20 >> Cool. I would like to have look on them. So how do you manage the >> background process/thread? >> =20 Yes, we would try to sent it here as soon as possible. The background=20 workload could be added through various methods. We could an simple=20 algorithm as follows: run_migration2(): pid =3D 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=20 run_autotest() and catch its exception. wait_autotest_background(pid) would wait until the background benchmark= =20 complete and analyse the result through the return value of the subproc= ess. The child process could work well depends the fact that the ssh=20 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. >>>> >>>> >>>> =20 >>> The parallelized instances could be easily achieved through >>> =20 >> job.parallel() >> =20 >>> of autotest framework, and that is what we have used in our tests. >>> =20 >> We have >> =20 >>> make some helper routines such as get_free_port to be reentrant >>> =20 >> through file >> =20 >>> lock. >>> We've implemented following test cases: timedrift(already sent >>> =20 >> here), >> =20 >>> savevm/loadvm, suspend/resume, jumboframe, migration between two >>> =20 >> machines >> =20 >>> 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 >>> =20 >> autotest >> =20 >>> server UI. This would make it hard to configure the tests in the >>> =20 >> server >> =20 >>> side. During our test, we have merged it into control and make it >>> =20 >> could be >> =20 >>> configured by "editing control file" function of autotest server >>> =20 >> side web >> =20 >>> UI. >>> =20 >> 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 i= t >> is impossible to do by using it. >> =20 >>> 2) Public bridge support: I've sent a patch(TAP network support in >>> kvm-autotest), this patch needs external DHCP server and requires >>> =20 >> nmap >> =20 >>> support. I don't know whether the method of original >>> =20 >> kvm_runtes_old(DHCP >> =20 >>> server of private bridge) is preferable. >>> =20 >> 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 ol= d >> approach. >> =20 > > 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 sco= pe > of the KVM-Autotest framework. To emulate the old behavior, you can j= ust > start the DHCP server yourself locally. If you wish, maybe we can > bundle example scripts with the framework that will do this for the u= ser, > but they should not be an integral part of the framework in my opinio= n. > > =20 >> >> --=20 >> Sudhir Kumar >> -- >> To unsubscribe from this list: send the line "unsubscribe kvm" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> =20