From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35275) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SQJNH-0000Zv-CD for qemu-devel@nongnu.org; Fri, 04 May 2012 10:20:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SQJNF-0001xw-2Q for qemu-devel@nongnu.org; Fri, 04 May 2012 10:20:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39253) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SQJNE-0001xa-QA for qemu-devel@nongnu.org; Fri, 04 May 2012 10:20:44 -0400 Date: Fri, 4 May 2012 10:33:38 -0300 From: Luiz Capitulino Message-ID: <20120504103338.6eb7606e@doriath.home> In-Reply-To: <4FA39840.7060902@redhat.com> References: <1335559216-13849-1-git-send-email-lcapitulino@redhat.com> <1335559216-13849-3-git-send-email-lcapitulino@redhat.com> <4FA0DD87.6080302@redhat.com> <20120502153453.3ee5dc8e@doriath.home> <4FA23A44.6040908@redhat.com> <20120503173053.4236de18@doriath.home> <4FA39840.7060902@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/3] runstate: introduce suspended state List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com On Fri, 04 May 2012 10:50:08 +0200 Gerd Hoffmann wrote: > Hi, > > > However, I've ran into a different issue today: migrating while suspended > > doesn't work. The target VM seems to be locked into S3, it just doesn't resume. > > > > Haven't investigated yet, but this is expected to work, right? > > Well, that one is still on the todo list. There is the temporary > stopgap to just resume the machine before migration so we don't have to > migrate the is_suspended bit (not merged). Ok. > I plan to fix that properly, it needs some discussion to figure a sane > way as we don't have a vmstate section for global state like this where > we could attach a subsection to. That didn't happen yet though ... There's a quite simple and stupid way to do it. When we migrate an stopped VM, it's automatically resumed on the target. We could do the same for a suspended VM: we could automatically resume it before migrating, as you said above. That's not the behavior I'd expect, I mean I would expect a stopped VM to remain stopped after it's migrated. But it has always been this way and I'm afraid we can't change this.