From mboxrd@z Thu Jan 1 00:00:00 1970 From: jason wang Subject: Re: kvm-autotest: The automation plans? Date: Thu, 14 May 2009 14:52:13 +0800 Message-ID: <4A0BBF9D.8050009@redhat.com> References: 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 To: sudhir kumar Return-path: Received: from mx2.redhat.com ([66.187.237.31]:56613 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752223AbZENGxA (ORCPT ); Thu, 14 May 2009 02:53:00 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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 in=20 our tests. We have make some helper routines such as get_free_port to b= e=20 reentrant through file lock. We've implemented following test cases: timedrift(already sent here),=20 savevm/loadvm, suspend/resume, jumboframe, migration between two=20 machines and others. We will sent it here for review in the following w= eeks. There are some other things could be improved: 1) Current kvm_test.cfg.sample/kvm_test.cfg is transparent to autotest=20 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 sid= e=20 web UI. 2) Public bridge support: I've sent a patch(TAP network support in=20 kvm-autotest), this patch needs external DHCP server and requires nmap=20 support. I don't know whether the method of original kvm_runtes_old(DHC= P=20 server of private bridge) is preferable.