From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Me3hR-0000gf-B2 for qemu-devel@nongnu.org; Thu, 20 Aug 2009 05:12:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Me3hM-0000gL-Ig for qemu-devel@nongnu.org; Thu, 20 Aug 2009 05:12:48 -0400 Received: from [199.232.76.173] (port=58291 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Me3hM-0000gI-Di for qemu-devel@nongnu.org; Thu, 20 Aug 2009 05:12:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61935) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Me3hL-0006oi-Uk for qemu-devel@nongnu.org; Thu, 20 Aug 2009 05:12:44 -0400 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n7K9CgPQ001730 for ; Thu, 20 Aug 2009 05:12:42 -0400 From: Juan Quintela In-Reply-To: <4A8D0C00.6080402@redhat.com> (Avi Kivity's message of "Thu, 20 Aug 2009 11:40:32 +0300") References: <927bb26f5425c58febd666db8fec67f55a229b5c.1250646771.git.quintela@redhat.com> <4A8D0C00.6080402@redhat.com> Date: Thu, 20 Aug 2009 11:10:28 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Qemu-devel] Re: [PATCH 6/6] Continue a migrated vm is a bad idea List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel@nongnu.org Avi Kivity wrote: > On 08/19/2009 05:07 AM, Juan Quintela wrote: >> index ea5c33a..762a9a5 100644 >> --- a/monitor.c >> +++ b/monitor.c >> @@ -567,6 +567,11 @@ static void do_cont(Monitor *mon) >> { >> struct bdrv_iterate_context context = { mon, 0 }; >> >> + if (unlikely(vm_has_migrated)) { >> + monitor_printf(mon, "this vm has migrated to other machine\n"); >> + monitor_printf(mon, "You have to load other vm\n"); >> + return; >> + } >> > > You don't know whether the guest is running on the other side. It may > be that the control program started the other side stopped, and after > migration completes decides which side to continue running. Only works if migration suceeded and was done in _non_ autostart node. Have to debug this very bug. User thought that he had done _nothing_ on the destination side, and that then stoping it, and continue in the source side was a good idea. He didn't understand why he had disk corruption, obviosly qemu had a bug. I haven't found a better approach to fix this bug. If you have a better idea of what to do in this case, I am all ears. The reason that I created the patch is that if the user didn't got it right, it gets disk corruption. Later, Juan.