Re: [Qemu-devel] [RFC 0/3] qga: add guest-get-memory-info (for 2.5)

[Daniel P. Berrange]

On Fri, Jul 31, 2015 at 07:36:46PM +0200, address@hidden wrote:
> From: Marc-André Lureau <address@hidden>
> 
> This series implement a new qemu guest agent command to get memory
> information from the guest. This is based on ovirt-guest-agent
> "memory-stats" message.
> 
> I couldn't find documentation for the ovirt message, but the list of
> fields are summarized in this test
> https://github.com/oVirt/ovirt-guest-agent/blob/master/tests/message_validator.py#L137
> and according to how they are populated in the code, I adapted it to
> the following GuestMemoryInfo structure fields:
> 
>  - mem-total: Total usable RAM.
>  - mem-free:  Total of RAM that can be used without having to swap contents 
> to disk.
>  - mem-cached: In-RAM cache.
>  - swap-total: Total amount of swap space available.
>  - swap-free: Amount of swap space that is currently unused.
>  - swap-in: Number of pages swapped-in per second.
>  - swap-out: Number of pages swapped-out per second.
>  - pf-major: Number of major page fault per second.
>  - pf-minor: Number of minor page fault per second.
> 
> Implemented on Linux and Win32 based on ovirt implementations.

Interesting, currently the libvirt virDomainGetMemoryStats() API is backed
by data we obtain from the virtio-balloon driver via QEMU monitor. For Linux
at least this provides equiv of your mem-total, mem-free, swap-in, swap-out
pf-major and pf-minor. So it lacks mem-cached, swap-total and swap-free
I'm unclear in the Windows balloon driver supports this data or not too.

> Note: the "per second" value differ between Linux and Win32. On Linux,
> the value is computed based on the average since the last query,
> however on win32 this seems to be an instantaneous value (they have
> spikes, but often at 0). I have asked for help on SF:
> 
> http://serverfault.com/questions/709943/windows-equivalent-of-linux-vmstat-pswpin-and-pgfault
> 
> Related to RFE:
> https://bugzilla.redhat.com/show_bug.cgi?id=1101915

I wonder if we would be better off extending the balloon driver to fill
in the gaps we have there vs this guest agent impl. With the balloon
agent we set things up so that the guest device periodically pushes the
updated stats to QEMU. So when we're querying QEMU for the stats we don't
actually block waiting on the guest OS at all, QEMU can answer directly.
This feels more appealing that querying the guest agent where we have
no reasonable expectation of prompt response. With a large enough number
of guests, I think the balloon driver push approach will scale better
than a guest agent approach.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|