Re: [Qemu-devel] [RFC 0/5]: QMP: add balloon-get-memory-stats command

[Luiz Capitulino]

On Thu, 19 Jan 2012 10:43:35 -0600
Michael Roth <address@hidden> wrote:

> On 01/19/2012 09: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 turn,
> > would also cause a hang in libvirt.
> >
> > Because of that, we decided to disable the guest memory stats feature
> > (commit 11724ff).
> >
> > As we decided to let commands implement ad-hoc async mechanisms until we
> > get a proper way to do it, I decided to try to re-enable that feature.
> >
> > 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 guest
> > 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).
> >
> > I'm not sure if that approach is good for libvirt though, so it would be
> > very helpful to get their input (Eric, I'm CC'ing you here, but feel free
> > to route this to someone else).
> >
> > Another interesting point is that, there's another way of doing this and
> > 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 involve
> > guest communication. We also could return a lot more information if needed.
> > The only disadvantage I can see is the dependency on qemu-ga...
> 
> A nice plus with this is we retroactively get support for a wide range 
> of existing guest types that we wouldn't realistically expect to have a 
> qemu-ga package, and I think there's even balloon stats for Windows 
> guests as well. Event-based updates also lend themselves nicely to 
> things like qemu-centric UI integration.
> 
> Memory stats is one of the proposed use-cases of qemu-ga, but I don't 
> see these as necessarily being in conflict. We can extend the statistics 
> collection quite a bit more with an agent approach, but it's nice to 
> have some assurance that if you can balloon a guest, you can at the very 
> least get at the bare minimum information you need to make reasonable 
> decisions about ballooning.

That makes sense, we could have both.

> 
> >
> >   QMP/qmp-events.txt  |   28 ++++++++++++++++++++++++++++
> >   balloon.c           |   47 +++++++++++++++++++++++++++++++++++++----------
> >   balloon.h           |    7 ++++---
> >   hmp.c               |   25 +------------------------
> >   hw/virtio-balloon.c |   39 +++++++++++++++++++++++++++------------
> >   monitor.c           |    3 +++
> >   monitor.h           |    1 +
> >   qapi-schema.json    |   42 ++++++++++++++++++++++--------------------
> >   qmp-commands.hx     |    6 ++++++
> >   9 files changed, 129 insertions(+), 69 deletions(-)
> >
>