On 10/03/2012 04:08 PM, Ben Clay wrote: 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. The event is currently tracking when qemu events occur. Correct. 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

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: 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. The event is currently tracking when qemu events occur. Correct. 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