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 11:38:05 +0800 Message-ID: <4A0CE39D.30805@redhat.com> References: <1902048503.208401242292252387.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: kvm@vger.kernel.org, uril@redhat.com, mrodrigu@redhat.com, smalikphy@gmail.com To: Michael Goldish Return-path: Received: from mx2.redhat.com ([66.187.237.31]:49694 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753985AbZEODiU (ORCPT ); Thu, 14 May 2009 23:38:20 -0400 In-Reply-To: <1902048503.208401242292252387.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: > ----- "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 >>> =20 >> We have some patches of ping pong migration and workload adding. The= =20 >> migration is based on public bridge and workload adding is based on=20 >> running benchmark in the background of guest. >> =20 >>> (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 >>> =20 >> The parallelized instances could be easily achieved through=20 >> 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 t= o >> be reentrant through file lock. >> =20 > > We'll probably have to use file locks anyway when we work with TAP, b= ut in > VM.create(), not in get_free_port(), because we also want to prevent = parallel > qemu instances from choosing the same TAP device. I'm not sure how qe= mu > handles this internally, and I'd rather be on the safe side. > > Do you release the file lock inside get_free_port or only after runni= ng qemu? > =20 We record the port usage and release the file lock inside=20 get_free_port(). I agree with you that it's better to get/release the=20 file lock in VM.create() because it is easier and it also eliminates th= e=20 effort of doing lock in every helper function. =46or the TAP device, maybe we could give each TAP device used by qemu-= kvm=20 an random generated ifname to prevent qemu-kvm from choosing the same=20 TAP devices. This method works well in our test. >> We've implemented following test cases: timedrift(already sent here)= , >> savevm/loadvm, suspend/resume, jumboframe, migration between two=20 >> machines and others. We will sent it here for review in the followin= g >> weeks. >> There are some other things could be improved: >> 1) Current kvm_test.cfg.sample/kvm_test.cfg is transparent to autote= st >> server UI. This would make it hard to configure the tests in the >> server=20 >> side. During our test, we have merged it into control and make it >> could=20 >> be configured by "editing control file" function of autotest server >> side web UI. >> =20 > > Would it not suffice to just modify the configuration, instead of com= pletely > define it, inside the control file? This is possible using parse_stri= ng(). > For example: > > cfg =3D kvm_config.config("kvm_tests.cfg") > cfg.parse_string("only weekly") > cfg.parse_string("only Fedora RHEL Windows") > cfg.parse_string(""" > variants: > - 1: > only ide > - 2: > Fedora: > no rtl8139 > """) > list =3D cfg.get_list() > > (get_list() returns the test dictionaries.) > > The advantage here is that we can have a standard kvm_tests.cfg that = we all > agree on and only rather small environment-specific modifications are= made > in the control file. > =20 Thanks, this way makes the things easier.