From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Goldish Subject: Re: kvm-autotest: The automation plans? Date: Thu, 14 May 2009 05:10:52 -0400 (EDT) Message-ID: <1902048503.208401242292252387.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> References: <819364962.208261242291936661.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm@vger.kernel.org, uril@redhat.com, mrodrigu@redhat.com, sudhir kumar To: jason wang Return-path: Received: from mx1.redhat.com ([66.187.233.31]:54000 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752137AbZENJKy convert rfc822-to-8bit (ORCPT ); Thu, 14 May 2009 05:10:54 -0400 In-Reply-To: <819364962.208261242291936661.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: ----- "jason wang" wrote: > sudhir kumar =E5=86=99=E9=81=93: > > 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. The=20 > migration is based on public bridge and workload adding is based on=20 > running benchmark in the background of guest. > > (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() of autotest framework, and that is what we have used i= n > our tests. We have make some helper routines such as get_free_port to > be reentrant through file lock. We'll probably have to use file locks anyway when we work with TAP, but= in VM.create(), not in get_free_port(), because we also want to prevent pa= rallel qemu instances from choosing the same TAP device. I'm not sure how qemu 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 running= qemu? > 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 following > weeks. > There are some other things could be improved: > 1) Current kvm_test.cfg.sample/kvm_test.cfg is transparent to autotes= t > 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. Would it not suffice to just modify the configuration, instead of compl= etely define it, inside the control file? This is possible using parse_string= (). =46or 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 m= ade in the control file.