From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Goldish <mgoldish@redhat.com>
Subject: Re: [PATCH 0/3] Launch other test during migration
Date: Mon, 01 Nov 2010 17:45:56 +0200
Message-ID: <4CCEE0B4.6050209@redhat.com>
References: <20100925092836.28158.64788.stgit@dhcp-91-158.nay.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: autotest@test.kernel.org, kvm@vger.kernel.org, mst@redhat.com
To: Jason Wang <jasowang@redhat.com>
Return-path: <autotest-bounces@test.kernel.org>
In-Reply-To: <20100925092836.28158.64788.stgit@dhcp-91-158.nay.redhat.com>
List-Unsubscribe: <http://test.kernel.org/cgi-bin/mailman/listinfo/autotest>,
	<mailto:autotest-request@test.kernel.org?subject=unsubscribe>
List-Archive: <http://test.kernel.org/pipermail/autotest>
List-Post: <mailto:autotest@test.kernel.org>
List-Help: <mailto:autotest-request@test.kernel.org?subject=help>
List-Subscribe: <http://test.kernel.org/cgi-bin/mailman/listinfo/autotest>,
	<mailto:autotest-request@test.kernel.org?subject=subscribe>
Sender: autotest-bounces@test.kernel.org
Errors-To: autotest-bounces@test.kernel.org
List-Id: kvm.vger.kernel.org

On 09/25/2010 11:36 AM, Jason Wang wrote:
> We could give a further test of migration by launch test during migartion. So
> the following series implements:
> 
> - A simple class to run a specified test in the background which could be used
> to launch other test during migartion. Its design is rather simple and its usage
> is a little tricky, but it work well.
> - Two sample tests which take advantages of the background class: Test reboot
> during guest migration and test file_transfer during guest migration.
> 
> In the future, we could even lauch autotest client test during guest migation.
> 
> ---
> 
> Jason Wang (3):
>       KVM Test: Introduce a helper class to run a test in the background
>       KVM test: Test reboot during migration
>       KVM test: Test the file transfer during migartion
> 
> 
>  client/tests/kvm/kvm_test_utils.py                 |   44 +++++++++++++++
>  .../kvm/tests/migration_with_file_transfer.py      |   59 ++++++++++++++++++++
>  client/tests/kvm/tests/migration_with_reboot.py    |   45 +++++++++++++++
>  client/tests/kvm/tests_base.cfg.sample             |   12 ++++
>  4 files changed, 159 insertions(+), 1 deletions(-)
>  create mode 100644 client/tests/kvm/tests/migration_with_file_transfer.py
>  create mode 100644 client/tests/kvm/tests/migration_with_reboot.py

It seems to me that this method is only applicable to tests/functions
that don't require a VM object (i.e. that require only a shell session
object).  kvm_test_utils.reboot() operates on a VM object, and the same
VM is destroyed by migrate() which runs in the background, so eventually
reboot() tries logging into a destroyed VM, which fails because
vm.get_address() fails.  Any monitor operation will also fail.  If the
autotest wrapper requires a VM object (currently it does) then it can't
be used either.

An alternative (somewhat ugly) way to migrate in the background is to
pass a boolean 'migrate' flag to various functions/tests, such as
reboot() and run_autotest().  If 'migrate' is True, these functions will
do something like

vm = kvm_test_utils.migrate(vm, ...)

in their waiting loops, where wait_for() is normally used.  This
guarantees that 'vm' is always a valid VM object.  For example:

# Log in after reboot
while time.time() < end_time:
    if migrate_in_bg:
        vm = kvm_test_utils.migrate(vm, ...)
    session = vm.remote_login()
    if session:
        break
    time.sleep(2)

This is much longer than the usual wait_for(...) but it does the job.
What do you think?