Re: [PATCH 0/3] Launch other test during migration

From: Jason Wang <jasowang@redhat.com>
To: pradeep <psuriset@linux.vnet.ibm.com>
Cc: kvm@vger.kernel.org, mst@redhat.com, autotest@test.kernel.org,
	skannery@in.ibm.com
Subject: Re: [PATCH 0/3] Launch other test during migration
Date: Wed, 20 Oct 2010 08:48:56 +0800	[thread overview]
Message-ID: <19646.15480.85112.668806@gargle.gargle.HOWL> (raw)
In-Reply-To: <20101018152110.7b017326@skywalker>

pradeep writes:
 > On Mon, 18 Oct 2010 00:59:20 -0400 (EDT)
 > Jason Wang <jasowang@redhat.com> wrote:
 > 
 > > Hello guys:
 > > 
 > > Any further suggestion which I need to improve those patches?
 > > 
 > > I agree that there's no much tests need to be run is this way except
 > > for migration. In order to validate the function of migration, many
 > > tests need to be run in parallel with migration and this series is
 > > just aimed at this.
 > > 
 > > One major advantage of this is that it could greatly simplified the
 > > test design and could reuse existed test cases without modification.
 > > Without this, we must split the tests cases itself or split the
 > > migration test and modification to existed code is also required.
 > > 
 > > One major issue is that not all tests could be run in this way, tests
 > > which needs to do monitor operation may not work well, but ususally
 > > this kind of test is meaningless during migration.
 > > 
 > > Another probably issue is that we can not control precisely when the
 > > migration start, but it's not important to tests I post here because
 > > the background tests are usually launch as a kind of stress and need
 > > much more time than just a single migration to complete, so what we
 > > need to do here is just let the migration run until the background
 > > tests finish.
 > > 
 > > The fact is that these tests work well and have find real issues with
 > > migration.
 > > 
 > > Any comments or suggestions?
 > > 
 > Good to cover different aspects of live migration using KVM 
 > 
 > In cloud,  When we are targetting for minimal downtime for migration, always we need to think about the performance impact of the
 > resources and actions.
 > 
 > we feel, its good to cover couple of below combinations.
 > 
 >  any state change of  a VM + migration
 > 
 > 1. migration + reading data from host devices like CD, USB
 > 2. migrate +file trasfer
 > 3. migrate + reboot
 > 4. internet download + migration
 > 5. guest is given shutdown command and in parallel live migration
 > happens
 > 6.hotplugging of nic, storage, memory, cpu + live migration
 > 
 > 

Thanks for these suggestions, I would try to implement these in the after we
find a solution to run a test in parallel with migrations.

 > Thanks
 > Pradeep
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 