From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35907 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PrRCR-00019N-O7 for qemu-devel@nongnu.org; Mon, 21 Feb 2011 03:32:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PrRCQ-0006EM-F9 for qemu-devel@nongnu.org; Mon, 21 Feb 2011 03:32:55 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51812) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PrRCQ-0006Di-5Z for qemu-devel@nongnu.org; Mon, 21 Feb 2011 03:32:54 -0500 Message-ID: <4D62231F.9020901@redhat.com> Date: Mon, 21 Feb 2011 09:32:31 +0100 From: Jes Sorensen MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC][PATCH v6 00/23] virtagent: host/guest RPC communication agent References: <1295270117-24760-1-git-send-email-mdroth@linux.vnet.ibm.com> <4D5BF581.3050803@redhat.com> <4D5C07CB.4040709@linux.vnet.ibm.com> <4D5CDBD0.2060900@redhat.com> <4D5D3331.1000707@linux.vnet.ibm.com> <4D5E69EB.5040805@redhat.com> <4D5E7D35.7090207@linux.vnet.ibm.com> <4D5E8291.7020900@redhat.com> <4D5E88BD.3050006@linux.vnet.ibm.com> In-Reply-To: <4D5E88BD.3050006@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: agl@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com, markus_mueller@de.ibm.com, marcel.mittelstaedt@de.ibm.com, Michael Roth , qemu-devel@nongnu.org, ryanh@us.ibm.com, abeekhof@redhat.com, Luiz Capitulino On 02/18/11 15:57, Anthony Liguori wrote: > On 02/18/2011 08:30 AM, Jes Sorensen wrote: >> However if there's an agent connection, it could be arranged in a way >> allowing the host to reconnect to the guest agent. In that way it really >> shouldn't be a big deal as long as our agent commands aren't too complex. > > Oh, but they'll be nice and complex :-) What happens if you do a live > migration in the middle of doing a live backup? You'll end up with the > guest waiting to be told that it's okay to unfreeze itself only to never > be told. Well that isn't really different from the current setup - if QEMU migrates, the admin tool has to connect to the new QEMU process and issue the fsthaw command there instead. > Terminating in QEMU means we can do intelligent things like delay live > migration convergence, save state, etc. We could easily add a flag for this in QEMU itself, so I don't see it being a big issue. Jes