From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MOuoS-0005rY-3l for qemu-devel@nongnu.org; Thu, 09 Jul 2009 10:41:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MOuoN-0005mP-A9 for qemu-devel@nongnu.org; Thu, 09 Jul 2009 10:41:27 -0400 Received: from [199.232.76.173] (port=50455 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MOuoN-0005mA-3i for qemu-devel@nongnu.org; Thu, 09 Jul 2009 10:41:23 -0400 Received: from qw-out-1920.google.com ([74.125.92.145]:27703) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MOuoM-0003GP-Ix for qemu-devel@nongnu.org; Thu, 09 Jul 2009 10:41:22 -0400 Received: by qw-out-1920.google.com with SMTP id 5so51647qwc.4 for ; Thu, 09 Jul 2009 07:41:22 -0700 (PDT) Message-ID: <4A560190.6040502@codemonkey.ws> Date: Thu, 09 Jul 2009 09:41:20 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/3] move vm stop/start to migrate_set_state References: <1247140059-5034-1-git-send-email-pbonzini@redhat.com> <1247140059-5034-3-git-send-email-pbonzini@redhat.com> <4A55F46F.6060705@codemonkey.ws> <4A55F510.5090801@redhat.com> <4A55F641.6000701@codemonkey.ws> <4A55F772.6000200@redhat.com> In-Reply-To: <4A55F772.6000200@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org Paolo Bonzini wrote: > On 07/09/2009 03:53 PM, Anthony Liguori wrote: >> Paolo Bonzini wrote: >>> On 07/09/2009 03:45 PM, Anthony Liguori wrote: >>>> How does the disk become full during the final stage? The guest isn't >>>> running. >>> >>> The host disk can become full and cause a "migrate exec" to fail. Or >>> for network migration migration, you could have the connection drop >>> exactly during the final stage. In this case, the VM would be >>> unconditionally restarted. >> >> Because migration failed. Is that not the desired behavior? It seems >> like it is to me. > > By "unconditionally" I meant "even if the VM used to be paused". Oh, that's definitely a bug. But that's an easy fix too: diff --git a/migration.c b/migration.c index 190b37e..e6c8b16 100644 --- a/migration.c +++ b/migration.c @@ -261,12 +261,16 @@ void migrate_fd_put_ready(void *opaque) dprintf("iterate\n"); if (qemu_savevm_state_iterate(s->file) == 1) { int state; + int old_vm_running = vm_running; + dprintf("done iterating\n"); vm_stop(0); bdrv_flush_all(); if ((qemu_savevm_state_complete(s->file)) < 0) { - vm_start(); + if (old_vm_running) { + vm_start(); + } state = MIG_STATE_ERROR; } else { state = MIG_STATE_COMPLETED; Regards, Anthony Liguori > Paolo