On Thu, 19 Jan 2012 10:43:35 -0600 Michael Roth <mdr...@linux.vnet.ibm.com> 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(-) > > >
