5:08 p.m.
I'm trying to track balloon growth after issuing a setmem command to a KVM
guest with libvirt 0.10.2 and qemu-kvm 0.12.1.2 on CentOS 6.3. libvirt
0.10.2 was built from tar today and appears to be working fine. The guest
is running CentOS 6.3 as well.
Using the provided test programs under examples/domain-events/ in C and
Python, I'm not seeing VIR_DOMAIN_EVENT_ID_BALLOON_CHANGE ever tick,
although I do see other events like VIR_DOMAIN_EVENT_ID_LIFECYCLE,
VIR_DOMAIN_EVENT_ID_REBOOT, and VIR_DOMAIN_EVENT_ID_RTC_CHANGE. The balloon
is definitely changing, and is reflected by both virsh -c qemu:///system
dommemstat <dom> and free inside the guest. Here's the balloon in my config
for reference:
<memballoon model='virtio'>
<alias name='balloon0'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x05'
function='0x0'/>
</memballoon>
Is my understanding incorrect of what VIR_DOMAIN_EVENT_ID_BALLOON_CHANGE is?
Is there something else this event is tracking, other than a virsh -c
qemu:///system setmem <dom> <mem in KB> command and/or subsequent balloon
movement inside the guest? Or, is my old version of qemu-kvm not passing
this event back to libvirt? The latter doesn't seem correct because I'm
getting seemingly-valid values from dommemstat - ie, if I setmem 200MB when
the guest OS and applications are consuming 300MB, it reports near 300MB
(and the guest no longer responds) instead of just parroting the 200MB value
I fed it.
Thanks!
Ben Clay
rbclay(a)ncsu.edu
5:41 p.m.
On 10/03/2012 04:08 PM, Ben Clay wrote:
I'm trying to track balloon growth after issuing a setmem command
to a KVM
guest with libvirt 0.10.2 and qemu-kvm 0.12.1.2 on CentOS 6.3. libvirt
0.10.2 was built from tar today and appears to be working fine. The guest
is running CentOS 6.3 as well.
Is my understanding incorrect of what
VIR_DOMAIN_EVENT_ID_BALLOON_CHANGE is?
This event is only fired if you have qemu 1.2 or newer, or if the new
BALLOON_CHANGE event has been backported to the particular qemu you are
using.
Is there something else this event is tracking, other than a virsh
-c
qemu:///system setmem <dom> <mem in KB> command and/or subsequent balloon
movement inside the guest?
The event is currently tracking when qemu events occur.
Or, is my old version of qemu-kvm not passing
this event back to libvirt?
Correct.
The latter doesn't seem correct because I'm
getting seemingly-valid values from dommemstat - ie, if I setmem 200MB when
the guest OS and applications are consuming 300MB, it reports near 300MB
(and the guest no longer responds) instead of just parroting the 200MB value
I fed it.
You are seeing different values because libvirt is doing polling under
the hood, when talking to a qemu too old to send the event. If you
upgrade qemu to something that sends the JSON event, then libvirt will
quit polling, and instead rely on the event and forward the event back
to you.
We could argue that since libvirt is already polling older qemu, that
libvirt should then synthesize VIR_DOMAIN_EVENT_ID_BALLOON_CHANGE any
time it happens to detect a change on one of its polls, but I'm not sure
if it is easier to write that patch than it is to just tell people to
upgrade to newer qemu. Besides, with libvirt polling, the events will
only happen insofar as libvirt detects change, which might be at a
different frequency than how newer qemu would fire the events (note that
the qemu 1.2 implementation rate-limits the event, to fire at most once
per second, with the last event firing as late as 1 second after the
actual final change of the memory). That is, synthesizing the event in
libvirt for older qemu would require implementing the same rate-limiting
code in libvirt.
Since you mentioned are using CentOS, you are at the mercy of what
others happen to package; if this feature is really important to you,
you might want to consider contributing patches upstream, and/or
switching to a RHEL contract to get Red Hat to implement it faster on
your behalf.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
6:04 p.m.
Eric-
Thanks for the quick response. I'm glad to hear about the rate-limiting,
that would've stumped me once I got it up and running. I'll give qemu 1.2 a
shot, and switch to a newer distro if needed.
Ben Clay
rbclay(a)ncsu.edu
-----Original Message-----
From: Eric Blake [mailto:eblake@redhat.com]
Sent: Wednesday, October 03, 2012 4:42 PM
To: Ben Clay
Cc: libvirt-users(a)redhat.com
Subject: Re: [libvirt-users] no callback on
VIR_DOMAIN_EVENT_ID_BALLOON_CHANGE in 0.10.2
On 10/03/2012 04:08 PM, Ben Clay wrote:
I'm trying to track balloon growth after issuing a setmem command
to a
KVM guest with libvirt 0.10.2 and qemu-kvm 0.12.1.2 on CentOS 6.3.
libvirt
0.10.2 was built from tar today and appears to be working fine. The
guest is running CentOS 6.3 as well.
Is my understanding incorrect of what
VIR_DOMAIN_EVENT_ID_BALLOON_CHANGE
is?
This event is only fired if you have qemu 1.2 or newer, or if the new
BALLOON_CHANGE event has been backported to the particular qemu you are
using.
Is there something else this event is tracking, other than a virsh -c
qemu:///system setmem <dom> <mem in KB> command and/or subsequent
balloon movement inside the guest?
The event is currently tracking when qemu events occur.
Or, is my old version of qemu-kvm not passing this event back to
libvirt?
Correct.
The latter doesn't seem correct because I'm getting
seemingly-valid
values from dommemstat - ie, if I setmem 200MB when the guest OS and
applications are consuming 300MB, it reports near 300MB (and the guest
no longer responds) instead of just parroting the 200MB value I fed
it.
You are seeing different values because libvirt is doing polling under the
hood, when talking to a qemu too old to send the event. If you upgrade qemu
to something that sends the JSON event, then libvirt will quit polling, and
instead rely on the event and forward the event back to you.
We could argue that since libvirt is already polling older qemu, that
libvirt should then synthesize VIR_DOMAIN_EVENT_ID_BALLOON_CHANGE any time
it happens to detect a change on one of its polls, but I'm not sure if it is
easier to write that patch than it is to just tell people to upgrade to
newer qemu. Besides, with libvirt polling, the events will only happen
insofar as libvirt detects change, which might be at a different frequency
than how newer qemu would fire the events (note that the qemu 1.2
implementation rate-limits the event, to fire at most once per second, with
the last event firing as late as 1 second after the actual final change of
the memory). That is, synthesizing the event in libvirt for older qemu
would require implementing the same rate-limiting code in libvirt.
Since you mentioned are using CentOS, you are at the mercy of what others
happen to package; if this feature is really important to you, you might
want to consider contributing patches upstream, and/or switching to a RHEL
contract to get Red Hat to implement it faster on your behalf.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
9:54 p.m.
Eric-
I got qemu 1.2 built and it's working as advertised. I also found where
they're rate limiting it - thanks for the heads up there.
I did find that event-test.py may have a small bug in it - the balloon event
callback method signature is:
def myDomainEventBalloonChangeCallback(conn, dom, utcoffset, actual)
which yields the following exception:
Traceback (most recent call last):
File "/usr/lib64/python2.6/site-packages/libvirt.py", line 3662, in
_dispatchDomainEventBalloonChangeCallback
cb(self, virDomain(self, _obj=dom), actual, opaque)
File "event-test.py", line 494, in myDomainEventBalloonChangeCallback
print "myDomainEventBalloonChangeCallback: Domain %s(%s) %d" %
(dom.name(), dom.ID(), actual)
TypeError: %d format: a number is required, not NoneType
Once I changed this to the following (from
http://libvirt.org/html/libvirt-libvirt.html#virConnectDomainEventBalloonCha
ngeCallback) it worked:
def myDomainEventBalloonChangeCallback(conn, dom, actual, opaque)
because actual was getting the None opaque previously supplied in the
callback registration.
Ben Clay
rbclay(a)ncsu.edu
-----Original Message-----
From: Ben Clay [mailto:rbclay@ncsu.edu]
Sent: Wednesday, October 03, 2012 5:04 PM
To: 'Eric Blake'
Cc: libvirt-users(a)redhat.com
Subject: RE: [libvirt-users] no callback on
VIR_DOMAIN_EVENT_ID_BALLOON_CHANGE in 0.10.2
Eric-
Thanks for the quick response. I'm glad to hear about the rate-limiting,
that would've stumped me once I got it up and running. I'll give qemu 1.2 a
shot, and switch to a newer distro if needed.
Ben Clay
rbclay(a)ncsu.edu
-----Original Message-----
From: Eric Blake [mailto:eblake@redhat.com]
Sent: Wednesday, October 03, 2012 4:42 PM
To: Ben Clay
Cc: libvirt-users(a)redhat.com
Subject: Re: [libvirt-users] no callback on
VIR_DOMAIN_EVENT_ID_BALLOON_CHANGE in 0.10.2
On 10/03/2012 04:08 PM, Ben Clay wrote:
I'm trying to track balloon growth after issuing a setmem command
to a
KVM guest with libvirt 0.10.2 and qemu-kvm 0.12.1.2 on CentOS 6.3.
libvirt
0.10.2 was built from tar today and appears to be working fine. The
guest is running CentOS 6.3 as well.
Is my understanding incorrect of what
VIR_DOMAIN_EVENT_ID_BALLOON_CHANGE
is?
This event is only fired if you have qemu 1.2 or newer, or if the new
BALLOON_CHANGE event has been backported to the particular qemu you are
using.
Is there something else this event is tracking, other than a virsh -c
qemu:///system setmem <dom> <mem in KB> command and/or subsequent
balloon movement inside the guest?
The event is currently tracking when qemu events occur.
Or, is my old version of qemu-kvm not passing this event back to
libvirt?
Correct.
The latter doesn't seem correct because I'm getting
seemingly-valid
values from dommemstat - ie, if I setmem 200MB when the guest OS and
applications are consuming 300MB, it reports near 300MB (and the guest
no longer responds) instead of just parroting the 200MB value I fed
it.
You are seeing different values because libvirt is doing polling under the
hood, when talking to a qemu too old to send the event. If you upgrade qemu
to something that sends the JSON event, then libvirt will quit polling, and
instead rely on the event and forward the event back to you.
We could argue that since libvirt is already polling older qemu, that
libvirt should then synthesize VIR_DOMAIN_EVENT_ID_BALLOON_CHANGE any time
it happens to detect a change on one of its polls, but I'm not sure if it is
easier to write that patch than it is to just tell people to upgrade to
newer qemu. Besides, with libvirt polling, the events will only happen
insofar as libvirt detects change, which might be at a different frequency
than how newer qemu would fire the events (note that the qemu 1.2
implementation rate-limits the event, to fire at most once per second, with
the last event firing as late as 1 second after the actual final change of
the memory). That is, synthesizing the event in libvirt for older qemu
would require implementing the same rate-limiting code in libvirt.
Since you mentioned are using CentOS, you are at the mercy of what others
happen to package; if this feature is really important to you, you might
want to consider contributing patches upstream, and/or switching to a RHEL
contract to get Red Hat to implement it faster on your behalf.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
4463
days inactive
4464
days old
3 comments
2 participants
participants (2)
-
Ben Clay -
Eric Blake