Bug 623096
Summary: | qemu need to provide memory information without full balloon statistics | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Daniel Veillard <veillard> |
Component: | qemu-kvm | Assignee: | Luiz Capitulino <lcapitulino> |
Status: | CLOSED NOTABUG | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | high | Docs Contact: | |
Priority: | low | ||
Version: | 6.0 | CC: | abaron, acathrow, berrange, dallan, danken, ddumas, eblake, hateya, lcapitulino, llim, mgoldboi, mkenneth, tburke, virt-maint, xen-maint |
Target Milestone: | beta | Keywords: | Reopened, RHELNAK |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | 617286 | Environment: | |
Last Closed: | 2011-12-09 18:29:34 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 617286 | ||
Bug Blocks: | 580953 |
Comment 2
RHEL Program Management
2010-08-11 10:58:35 UTC
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. |