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 06:50:40 -0400 (EDT) Message-ID: <1660154190.211661242298240521.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> References: 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, jason wang To: sudhir kumar Return-path: Received: from mx1.redhat.com ([66.187.233.31]:47766 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752870AbZENKvR convert rfc822-to-8bit (ORCPT ); Thu, 14 May 2009 06:51:17 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: ----- "sudhir kumar" wrote: > On Thu, May 14, 2009 at 12:22 PM, 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. > >> > > > > 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? >=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. > >> > >> > > > > 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. 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 scope of the KVM-Autotest framework. To emulate the old behavior, you can jus= t start the DHCP server yourself locally. If you wish, maybe we can bundle example scripts with the framework that will do this for the use= r, but they should not be an integral part of the framework in my opinion. >=20 >=20 >=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