Bug 822092 - RFE: QMP notification of balloon memory changes
RFE: QMP notification of balloon memory changes
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Daniel Berrange
Virtualization Bugs
: FutureFeature
Depends On:
Blocks: 822094
  Show dependency treegraph
Reported: 2012-05-16 06:18 EDT by Daniel Berrange
Modified: 2014-06-17 23:16 EDT (History)
11 users (show)

See Also:
Fixed In Version: qemu-kvm-1.4.0-1.el7
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-06-13 08:19:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Daniel Berrange 2012-05-16 06:18:18 EDT
Description of problem:
Currently whenever libvirt runs its virDomainGetXMLDesc or virDomainGetInfo APIs, it must issue a 'query-balloon' monitor call, to determine what level the guest has currently ballooned to. This is problematic because it slows down this APIs, which would otherwise be very fast and makes libvirt & the mgmt app susceptible to a "hung" QEMU monitor.  This has caused real world pain for RHEV-M, virt-manager and GNOME Boxes and thus it is well overdue time for us to fix this problem.

QEMU knows exactly when the guest changes its actual balloon level and can trivially emit a monitor event to notify mgmt application when this happens. This would avoid the need to poll 'query-balloon' at all, and thus avoids any potential for slow operation / hangs of the afore mentioned libvirt APIs.
Comment 1 Daniel Berrange 2012-05-16 06:51:50 EDT
Here is an suitable impl

Comment 2 Daniel Berrange 2012-05-16 09:16:01 EDT
It would also need the 'query-events' command to let libvirt detect whether the balloon event is present

Comment 3 Luiz Capitulino 2012-05-18 09:35:32 EDT
Daniel, are you going to keep pursuing this upstream? If you will, then I think this bz has to be re-assigned to you, because a backport won't be needed (ie. this will be automatically in RHEL7.0 if merged before QEMU 1.2).
Comment 4 Daniel Berrange 2012-05-18 09:44:41 EDT
Yes, I aim to continue posting updates upstream.  Depending on the final result, I may ultimately request a backport for RHEL-6, but I'll create a separate BZ for that when required.
Comment 5 Luiz Capitulino 2012-05-18 09:54:33 EDT
Ok, re-assigning to you then. If this misses the 1.2 deadline for whatever reason, then you can re-assign it back to me for the RHEL7.0 backport work.
Comment 6 Daniel Berrange 2012-05-21 15:33:13 EDT
V2 of the patches, with rate limiting added

Comment 7 Daniel Berrange 2012-06-15 12:44:02 EDT
All 3 patches now accepted upstream in Luiz' QMP tree

commit 4860853d60ecea44b65e9cdefce980de3a641dce
Author: Daniel P. Berrange <berrange@redhat.com>
Date:   Mon May 21 17:59:51 2012 +0100

    Add 'query-events' command to QMP to query async events

commit 1bcf107bbae883540f45e11e9fdc912a496c3094
Author: Daniel P. Berrange <berrange@redhat.com>
Date:   Wed May 16 11:01:58 2012 +0100

    Add event notification for guest balloon changes

commit d218a99b8d590224229969594e3411e940a77a7b
Author: Daniel P. Berrange <berrange@redhat.com>
Date:   Mon May 21 17:27:20 2012 +0100

    Add rate limiting of RTC_CHANGE, BALLOON_CHANGE & WATCHDOG events
Comment 8 Miroslav Rezanina 2013-04-23 08:48:40 EDT
Fixed in qemu-kvm-1.4.0-1.el7
Comment 10 langfang 2014-01-26 01:29:08 EST
Test this bug on latest version:
# uname -r
# rpm -q qemu-kvm

1.boot guest with 
 ...-device virtio-balloon-pci,bus=pci.0,id=balloon0

# telnet 4444
{"return": {"actual": 2147483648}}
{"return": {}}
{"timestamp": {"seconds": 1390717029, "microseconds": 460666}, "event": "BALLOON_CHANGE", "data": {"actual": 2146435072}}
{"timestamp": {"seconds": 1390717030, "microseconds": 460216}, "event": "BALLOON_CHANGE", "data": {"actual": 455081984}}
{"timestamp": {"seconds": 1390717030, "microseconds": 752577}, "event": "BALLOON_CHANGE", "data": {"actual": 300941312}}


After step 2, when change balloon size ,added the balloon events
After step 3,will see the balloon event:
...{"name": "BALLOON_CHANGE"},...{"name": "RTC_CHANGE"}..{"name": "WATCHDOG"}...

Test on old version:
# uname -r
# rpm -q qemu-kvm

i can get the same results.

Addtional test:

Also test change balloon size too small and big on latest version, not hit any problem.

Hi, Daniel

   According to above test , could we can verify pass this bug ?

Comment 11 Daniel Berrange 2014-01-27 05:03:22 EST
When the balloon target is set, the guest will slowly adjust to meat the target. This will result in a series of BALLOON_CHANGE events. You should wait for the last event to arrive, and then compare the value with the guest RAM shown in /proc/meminfo inside the guest. They should be pretty much the same, if not identical.
Comment 12 langfang 2014-01-29 06:56:32 EST
(In reply to Daniel Berrange from comment #11)
> When the balloon target is set, the guest will slowly adjust to meat the
> target. This will result in a series of BALLOON_CHANGE events. You should
> wait for the last event to arrive, and then compare the value with the guest
> RAM shown in /proc/meminfo inside the guest. They should be pretty much the
> same, if not identical.

yes ,test on latest version

1.Boot guest with 
/usr/libexec/qemu-kvm -m 4G ....-device virtio-balloon-pci,bus=pci.0,id=balloon0

2.Change balloon size 
# telnet 4445
Connected to
Escape character is '^]'.
{"QMP": {"version": {"qemu": {"micro": 3, "minor": 5, "major": 1}, "package": " (qemu-kvm-1.5.3-41.el7)"}, "capabilities": []}}
{"return": {}}
{"return": {"actual": 4294967296}}
{"return": {}}
{"timestamp": {"seconds": 1390995440, "microseconds": 402484}, "event": "BALLOON_CHANGE", "data": {"actual": 4293918720}}
{"timestamp": {"seconds": 1390995441, "microseconds": 402074}, "event": "BALLOON_CHANGE", "data": {"actual": 2600468480}}
{"timestamp": {"seconds": 1390995442, "microseconds": 279347}, "event": "BALLOON_CHANGE", "data": {"actual": 1073741824}}
{"return": {"actual": 1073741824}}

3.In guest
# cat /proc/meminfo
MemTotal:         770748 kB
MemFree:          503988 kB
Buffers:            1468 kB

4.extend the balloon size
{"execute":"balloon","arguments":{"value":  2147483648}}
{"timestamp": {"seconds": 1390995917, "microseconds": 311927}, "event": "BALLOON_CHANGE", "data": {"actual": 806354944}}
{"timestamp": {"seconds": 1390995917, "microseconds": 837996}, "event": "BALLOON_CHANGE", "data": {"actual": 2147483648}}

4.In guest
# cat /proc/meminfo
MemTotal:        1819324 kB
MemFree:         1552348 kB
Buffers:            1468 kB
Cached:            98656 kB
SwapCached:            0 kB
Active:            97880 kB

According to above test ,when balloon size change,will show the balloon events ,and the mem size in guest (cat /proc/meminfo) will change too.

    Could we can verify this bug now?
Comment 13 Daniel Berrange 2014-01-29 07:04:07 EST
Looks reasonable to me.
Comment 15 Ludek Smid 2014-06-13 08:19:28 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

Note You need to log in before you can comment on or make changes to this bug.