Re: [Qemu-devel] [PATCH v2 0/3] re-enable balloon stats

[Luiz Capitulino <lcapitulino@redhat.com>]

On Sat, 15 Dec 2012 07:19:13 +0000
Dietmar Maurer <dietmar@proxmox.com> wrote:

> >  - drop qmp & hmp interface of old stats code
> 
> I think the old interface is not that bad (the new one is clumsy, because
> we need 6 qmp call instead of one to get all stats). Can't
> we try to make it functional and keep it?

No, because it breaks existing clients and that's why it's disabled since
qemu 0.12 or so.

Let me try once more to explain our options and why I think this is series
is our best choice.

Basically, we have try options:

1. Add stats to query-balloon

This breaks existing clients, because query-balloon is a synchronous command
that returns immediately. If we add stats to it (as we did) then it will
have to wait for the guest to respond, which can take a long time or even
doesn't happen at all if the guest is paused.

This broke libvirt, as explained here:

 https://bugzilla.redhat.com/show_bug.cgi?id=623903

2. Add a new command that just request the stats to be sent (ie. it doesn't
block), and then get the stats through an event

This was my last proposal:

 http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg00983.html

This sort of worked, but it has two problems. First, events can be lost.
Second, most failures can't be synchronously reported.

3. Add stats through device properties (this series)

While this isn't perfect, it does solve the issues with previous
implementations. Besides, it has the advantage of avoiding adding new
commands and it integrates nicely with the balloon driver, making some
errors automatically reported (eg. if the balloon is not enabled).

> Seriously, I think 'interval' should be a property we can pass at qemu
> startup. Then we can simply use the old interface to get cached values.

What if you want to change the interval or even set it case it wasn't set?
You'll need a new command. Any different behavior we want to add will require
a new command. Which is one of your own complaints against this series.

> I also do not understand you argument that you can't use the old
> interface because it was synchrounous  -

Explained above.

> removing the old interface is also
> not compatible ;-)

It's not, for two reasons. First, all fields are optional. Second, this was
never in a stable release (or was disabled right after the release).