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
101

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
real    8m32.513s
user    0m0.153s
sys     0m1.039s

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

real 0m1.988s
user 0m0.008s
sys 0m0.178s

but ....

[root@intel-XE7450-512-1 ~]# time virsh dominfo wintest99 > /dev/null

real 0m7.129s
user 0m0.012s
sys 0m0.396s
[root@intel-XE7450-512-1 ~]#

  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);
(gdb) 

tracing deeper we actually issue the command though JSON interface in
qemuMonitorJSONGetBalloonInfo()

912     virJSONValuePtr cmd = qemuMonitorJSONMakeCommand("query-balloon",
(gdb) 
916     *currmem = 0;
(gdb) 
918     if (!cmd)
(gdb) 
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,

Daniel

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.