Red Hat Bugzilla – Bug 623096
qemu need to provide memory information without full balloon statistics
Last modified: 2013-01-09 18:00:05 EST
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.
** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **
Copying comment #16 from original libvirt bug
Okay, I have been able to go into one of those boxes:
[root@intel-XE7450-512-1 ~]# w
20:47:10 up 9:03, 7 users, load average: 107.63, 105.43, 105.66
[root@intel-XE7450-512-1 ~]# ps auxwww | grep qemu-kvm | wc -l
all of those domains are running Windows 2008R2 in core mode and
under libvirt control
I could reproduce the problem with the help of Guannan Ren
[root@intel-XE7450-512-1 ~]# time virsh list > /tmp/list
I gdb' attached to the libvirtd daemon and traced into qemudDomainGetInfo
the first call to qemudGetProcessInfo returns immediately, but the
qemuMonitorGetBalloonInfo() call takes a bit of lag.
Then I experimented a bit and noticed the following:
[root@intel-XE7450-512-1 ~]# time virsh dominfo wintest1 > /dev/null
[root@intel-XE7450-512-1 ~]# time virsh dominfo wintest99 > /dev/null
So some VM takes way longuer to answer than others
I gdb attached again on libvirtd and traced again in qemudDomainGetInfo
when called asking for this specific domain info and no surprize gdb
waited for nearly 10 second returning from that step
5213 err = qemuMonitorGetBalloonInfo(priv->mon, &balloon);
tracing deeper we actually issue the command though JSON interface in
912 virJSONValuePtr cmd = qemuMonitorJSONMakeCommand("query-balloon",
916 *currmem = 0;
918 if (!cmd)
921 ret = qemuMonitorJSONCommand(mon, cmd, &reply);
and that step is taking nearly 10s for this domain
I hadn't a good way to retry this with a domain without balooning
in the immediate but I'm gonna try if possible,
I believe there are many changes required here
- A command to query the current balloon level / memory statistics known by QEMU
- A command to query trigger a refresh of memory statistics from the guest
- Event notification to client whenever the balloon level or memory statistics change.
IIUC, the original bug doesn't have anything to do with the query-balloon command, which makes this BZ low priority.
Having separate commands makes sense, but I fear that we'll be unable to change the current query-balloon command, as we're probably going to make the current QMP API stable.
I will discuss this issue upstream.
*** This bug has been marked as a duplicate of bug 626958 ***
oops, this is not a duplicate. Revert.
This is already fixed in rhel6 and upstream, the query-balloon command won't return any memory statistics.
For the next chapters on how the statistics will be returned, please see bug 626958.