From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33304 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PrVwX-0008Rt-F7 for qemu-devel@nongnu.org; Mon, 21 Feb 2011 08:36:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PrVwW-0000NP-DM for qemu-devel@nongnu.org; Mon, 21 Feb 2011 08:36:49 -0500 Received: from e5.ny.us.ibm.com ([32.97.182.145]:52767) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PrVwW-0000KA-Aw for qemu-devel@nongnu.org; Mon, 21 Feb 2011 08:36:48 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e5.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p1LDBlX7025267 for ; Mon, 21 Feb 2011 08:11:47 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p1LDaAkD205150 for ; Mon, 21 Feb 2011 08:36:11 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p1LDaAfS004678 for ; Mon, 21 Feb 2011 08:36:10 -0500 Message-ID: <4D626A49.2020108@linux.vnet.ibm.com> Date: Mon, 21 Feb 2011 07:36:09 -0600 From: Michael Roth 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> <4D62231F.9020901@redhat.com> In-Reply-To: <4D62231F.9020901@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: Jes Sorensen Cc: agl@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com, markus_mueller@de.ibm.com, marcel.mittelstaedt@de.ibm.com, qemu-devel@nongnu.org, Luiz Capitulino , Anthony Liguori , ryanh@us.ibm.com, abeekhof@redhat.com On 02/21/2011 02:32 AM, Jes Sorensen wrote: > 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. > Another thing to consider is that virtagent is bi-directional, and may be tracking the state of state-full RPCs on behalf of the guest client, just as the guest daemon may be tracking the state of stateful RPCs on behalf of the host client. We cannot maintain consistent state without migrating the host-side state information along with the guest. The admin tool in your example, i.e. libvirt, is different in this regard, since it is purely a client and not a client/server like the host and guest components of virtagent. It doesn't need to maintain any state between migrations. > > Jes > >