Re: [Qemu-devel] [RFC 3/3] docs: document virtio-balloon stats

[Luiz Capitulino]

On Thu, 6 Dec 2012 13:24:11 +0000
"Daniel P. Berrange" <address@hidden> wrote:

> On Tue, Dec 04, 2012 at 01:04:48PM -0200, Luiz Capitulino wrote:
> > Signed-off-by: Luiz Capitulino <address@hidden>
> > ---
> >  docs/virtio-balloon-stats.txt | 73 
> > +++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 73 insertions(+)
> >  create mode 100644 docs/virtio-balloon-stats.txt
> > 
> > diff --git a/docs/virtio-balloon-stats.txt b/docs/virtio-balloon-stats.txt
> > new file mode 100644
> > index 0000000..7e7ddc4
> > --- /dev/null
> > +++ b/docs/virtio-balloon-stats.txt
> > @@ -0,0 +1,73 @@
> > +virtio balloon memory statistics
> > +================================
> > +
> > +The virtio balloon driver supports guest memory statistics reporting. These
> > +statistics are available to QEMU users as QOM (QEMU Obejct Model) device
> > +properties via a polling mechanism.
> > +
> > +Basically, clients have to enable polling. Then they can query the 
> > available
> > +statistics.
> > +
> > +There are two control properties and six memory statistics from the guest.
> > +
> > +The control properties are:
> > +
> > + o stats-polling-interval: a value greater than zero enables polling
> > +   in the specified interval (in seconds). When value equals zero,
> > +   polling is disabled. If polling is already enabled and a value
> > +   greater than zero is written, the polling interval time is changed
> > +
> > + o stats-last-update: last stats update timestamp, in seconds
> > +
> > +The memory statistics are:
> > +
> > + o stat-swap-in
> > + o stat-swap-out
> > + o stat-major-faults
> > + o stat-minor-faults
> > + o stat-free-memory
> > + o stat-total-memory
> > +
> > +All values are in bytes. A value of -1 means that the statistic isn't
> > +available right now.
> > +
> > +Here are a few examples. The virtio-balloon device is assumed to be in the
> > +'/machine/peripheral-anon/device[1]' QOM path.
> > +
> > +Enable polling with 2 seconds interval:
> > +
> > +{ "execute": "qom-set",
> > +             "arguments": { "path": "/machine/peripheral-anon/device[1]",
> > +                    "property": "stats-polling-interval", "value": 2 } }
> > +
> > +{ "return": {} }
> > +
> > +Change polling to 10 seconds:
> > +
> > +{ "execute": "qom-set",
> > +             "arguments": { "path": "/machine/peripheral-anon/device[1]",
> > +                    "property": "stats-polling-interval", "value": 10 } }
> > +
> > +{ "return": {} }
> > +
> > +Get last update timestamp and free memory stat:
> > +
> > +{ "execute": "qom-get",
> > +  "arguments": { "path": "/machine/peripheral-anon/device[1]",
> > +  "property": "stats-last-update" } }
> > +
> > +{ "return": 1354629634 }
> > +
> > +{ "execute": "qom-get",
> > +  "arguments": { "path": "/machine/peripheral-anon/device[1]",
> > +  "property": "stat-free-memory" } }
> > +
> > +{ "return": 845115392 }
> > +
> > +Disable polling:
> > +
> > +{ "execute": "qom-set",
> > +             "arguments": { "path": "/machine/peripheral-anon/device[1]",
> > +                    "property": "stats-polling-interval", "value": 0 } }
> > +
> > +{ "return": {} }
> 
> 
> What sort of performance implications are there for enabling polling of
> virtio stats. Is it the kind of thing that it is reasonable to just
> enable for all VMs on a 10 second interval, so we'll always have stats
> available without having to have thought to enable them ahead of time ?

I can't think of any performance implications. Would be nice to get a
second opinion from the CC'ed people though.

> eg, the use case I'm wondering is that someone comes along and just
> runs   'virsh memstats $DOMAIN' and wants to see the latest data
> right away. 
> 
> I'm not suggesting that libvirt would be actually asking QEMU for the
> stats every 10 seconds. Only that libvirt tells QEMU to collect them.
> Then libvirt can just ask for them whenver someone wants them.

Note that once you enable polling, the balloon driver will immediately make
a request to the guest, that is, it won't wait the specified time interval to
send the first request.

So, the first call to virsh memstats could start polling and also poll for it
(although you do need to be prepared for the case where the guest doesn't
respond).

Also, you could consider adding the time interval in libvirt's API and
virsh memstats.