Hi ----- Original Message ----- > On Fri, Jul 31, 2015 at 07:36:46PM +0200, marcandre.lur...@redhat.com wrote: > > From: Marc-André Lureau <marcandre.lur...@redhat.com> > > > > 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.
Ah, I should have thought about it! However, many guests don't have a balloon driver. So it could still be useful as a fallback imho > > 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. I see, I think it really depends on the use case. Clearly for debugging, it doesn't need to be push-based. For load-balancing, I don't know either. Please Jiri give some details on how these fields are used by ovirt. Thanks
