From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39410) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZLEgQ-0003nf-Du for qemu-devel@nongnu.org; Fri, 31 Jul 2015 14:05:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZLEgL-0005Bo-Bp for qemu-devel@nongnu.org; Fri, 31 Jul 2015 14:05:26 -0400 Received: from mx4-phx2.redhat.com ([209.132.183.25]:55250) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZLEgL-0005Be-5D for qemu-devel@nongnu.org; Fri, 31 Jul 2015 14:05:21 -0400 Date: Fri, 31 Jul 2015 14:05:17 -0400 (EDT) From: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Message-ID: <1028101513.2049600.1438365917680.JavaMail.zimbra@redhat.com> In-Reply-To: <20150731175447.GZ2392@redhat.com> References: <1438364209-24940-1-git-send-email-marcandre.lureau@redhat.com> <20150731175447.GZ2392@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC 0/3] qga: add guest-get-memory-info (for 2.5) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: marcandre lureau , jbelka@redhat.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com Hi ----- Original Message ----- > On Fri, Jul 31, 2015 at 07:36:46PM +0200, marcandre.lureau@redhat.com wro= te: > > From: Marc-Andr=C3=A9 Lureau > >=20 > > 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. > >=20 > > 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_va= lidator.py#L137 > > and according to how they are populated in the code, I adapted it to > > the following GuestMemoryInfo structure fields: > >=20 > > - mem-total: Total usable RAM. > > - mem-free: Total of RAM that can be used without having to swap cont= ents > > 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. > >=20 > > Implemented on Linux and Win32 based on ovirt implementations. >=20 > Interesting, currently the libvirt virDomainGetMemoryStats() API is backe= d > by data we obtain from the virtio-balloon driver via QEMU monitor. For Li= nux > at least this provides equiv of your mem-total, mem-free, swap-in, swap-o= ut > 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 ballo= on 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: > >=20 > > http://serverfault.com/questions/709943/windows-equivalent-of-linux-vms= tat-pswpin-and-pgfault > >=20 > > Related to RFE: > > https://bugzilla.redhat.com/show_bug.cgi?id=3D1101915 >=20 > 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