From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37838) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rnvat-0001Kj-8t for qemu-devel@nongnu.org; Thu, 19 Jan 2012 12:16:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rnvan-00012V-6T for qemu-devel@nongnu.org; Thu, 19 Jan 2012 12:16:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:62129) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rnvam-00012F-Vt for qemu-devel@nongnu.org; Thu, 19 Jan 2012 12:16:05 -0500 Message-ID: <4F184FCB.2010505@redhat.com> Date: Thu, 19 Jan 2012 10:15:55 -0700 From: Eric Blake MIME-Version: 1.0 References: <1326988591-27241-1-git-send-email-lcapitulino@redhat.com> In-Reply-To: <1326988591-27241-1-git-send-email-lcapitulino@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig0E28F0DA874680B6C18A7CA8" Subject: Re: [Qemu-devel] [RFC 0/5]: QMP: add balloon-get-memory-stats command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: aliguori@us.ibm.com, mdroth@linux.vnet.ibm.com, "libvir-list@redhat.com" , armbru@redhat.com, qemu-devel@nongnu.org, agl@us.ibm.com, amit.shah@redhat.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0E28F0DA874680B6C18A7CA8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/19/2012 08:56 AM, Luiz Capitulino wrote: > Long ago, commit 625a5be added the guest provided memory statistics to > the query-balloon command. Unfortunately, it also introduced a severe > bug: query-balloon would hang if the guest didn't respond. This, in tur= n, > would also cause a hang in libvirt. >=20 > Because of that, we decided to disable the guest memory stats feature > (commit 11724ff). >=20 > As we decided to let commands implement ad-hoc async mechanisms until w= e > get a proper way to do it, I decided to try to re-enable that feature. >=20 > My idea is to have a command and an event. The command gets the process= > started by sending a request to guest and returns. Later, when the gues= t > makes the memory stats info available, it's sent to the client by means= > of an QMP event (please, take a look at patch 05/05 for full details). >=20 > I'm not sure if that approach is good for libvirt though, so it would b= e > very helpful to get their input (Eric, I'm CC'ing you here, but feel fr= ee > to route this to someone else). [I went ahead and cc'd the libvirt list] Yes, libvirt can live with this approach. And having this in parallel to a qemu-ga verb is nice, since, as it was pointed out, this would allow interaction with guests that have a balloon device but not a guest agent. You may want to read this thread [1], for thoughts on the impact of making another existing blocking command be extended into one that starts an async event and ends when an event is raised; libvirt can expose both a blocking and an asynchronous implementation to the user on top of the qemu model being just asynchronous. [1] https://www.redhat.com/archives/libvir-list/2012-January/msg00562.htm= l Thinking aloud - do we need a means to poll the state of the balloon-stat query? On the one hand, if libvirtd issues the start command, then gets stopped, then the event occurs, then libvirtd is restarted, then libvirt won't know that the event was missed. On the other hand, since this involves guest interaction, libvirt already has to assume that the guest may be malicious and refuse to report stats and/or report invalid stats, so libvirt would already have to be prepared to give up if no event has arrived in a fixed amount of time, and that also means that restarting libvirtd can just ignore any balloon query that was in flight before the restart. So I guess I'm okay with just a start and an event, with no poll of the last-known guest response. But it does mean that qemu has to gracefully handle if libvirt makes two start requests in a row without any intervening events, and conversely that libvirt has to be prepared for an event that happens even when libvirt doesn't remember triggering the start command. > Another interesting point is that, there's another way of doing this an= d > it's using qemu-ga instead. That's, qemu-ga could read that information= > from proc and return it. This is easier & simpler, as it doesn't involv= e > guest communication. We also could return a lot more information if nee= ded. > The only disadvantage I can see is the dependency on qemu-ga... Most likely, we would want to teach libvirt to use both methods, and give the choice to the user on which approach to use when the guest supports both. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig0E28F0DA874680B6C18A7CA8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPGE/LAAoJEKeha0olJ0NqEgYH/jAHfg4zgZMnYt0/ocepyEv0 A+6/bEcHwQVHgOB9VNMHXnYi3ax8kDSFespR6UpVq5+Pg12heV+n2HFsVTwR5xYG RNG7VJ82Rrp2qpEXRBTxjET8nGLcxQbiYRVsgbF1duXoy0g44BCpZX6jejWu1r6j gJiDGmgT0XcSxJnkMJ+mI8mcVr17BOgYkUIEpzCaJAh5xx+TqbMBMkIgs9e1N5ZA rbOtcD+GqJAaf+rCpXgaUh5rtHW99q2f1mP8ui8Vqh5RwNlNooIMY4ywBRAOHL7W 3i91HLnWUmH0kCE4H8D5Bx5z9ct3SRz6vWaTtruqClF+Yv4X4Rl/OEfueO78KXA= =DIV4 -----END PGP SIGNATURE----- --------------enig0E28F0DA874680B6C18A7CA8--