Bug 615754 - After restarting libvirtd, "virsh vcpuinfo" doesn't work for the the guests which were running before restarting the daemon
After restarting libvirtd, "virsh vcpuinfo" doesn't work for the the guests ...
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: libvirt (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Daniel Veillard
Virtualization Bugs
Depends On:
  Show dependency treegraph
Reported: 2010-07-18 09:26 EDT by Mark Wu
Modified: 2011-01-13 18:14 EST (History)
9 users (show)

See Also:
Fixed In Version: libvirt-0.8.2-1.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-01-13 18:14:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2011:0060 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2011-01-12 12:22:30 EST

  None (edit)
Description Mark Wu 2010-07-18 09:26:05 EDT
Description of problem:
The command "virsh vcpuinfo domN" just print a blank line if domN was started before libvirtd restarted

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. start virtual machine "node1"
2. service libvirtd restart
3. virsh vcpuinfo node1

Actual results:
[root@dhcp-129-138 ~]# virsh vcpuinfo node1

[root@dhcp-129-138 ~]# 

Expected results:
"virsh vcpuinfo" still works fine after libvirtd restarting

Additional info:
Comment 1 Mark Wu 2010-07-18 10:06:28 EDT
Only nvcpupids > 0, the vcpuinfo can be reported in qemud 
qemudDomainGetVcpus(virDomainPtr dom,
                    virVcpuInfoPtr info,
                    int maxinfo,
                    unsigned char *cpumaps,
                    int maplen) {

    /* Clamp to actual number of vcpus */
    if (maxinfo > vm->nvcpupids)
        maxinfo = vm->nvcpupids;

    if (maxinfo >= 1) {
        if (info != NULL) {
            memset(info, 0, sizeof(*info) * maxinfo);
            for (i = 0 ; i < maxinfo ; i++) {
                info[i].number = i;
                info[i].state = VIR_VCPU_RUNNING;

                if (vm->vcpupids != NULL &&

But the vcpu pid is not persistent across reboot since it's logged in the status file(/var/run/libvirt/qemu/node1.xml).  So in function qemudReconnectVMs() which is called to get the status of already running guests during libvirtd start, it can't get the value of "nvcpupids" and "pid". 

In libvirt-0.7.7-5.fc13.rpm,  this problem has been fixed. 
Log vcpu pid in status file
static int qemuDomainObjPrivateXMLFormat(virBufferPtr buf, void *data)
   if (priv->nvcpupids) {
        int i;
        virBufferAddLit(buf, "  <vcpus>\n");
        for (i = 0 ; i < priv->nvcpupids ; i++) {
            virBufferVSprintf(buf, "    <vcpu pid='%d'/>\n", priv->vcpupids[i]);
        virBufferAddLit(buf, "  </vcpus>\n");

    return 0;

And parse it when reconnect to the running domain in qemuDomainObjPrivateXMLParse
Comment 3 Jiri Denemark 2010-09-02 07:58:53 EDT
Fixed in libvirt-0.8.2-1.el5
Comment 5 Johnny Liu 2010-10-20 02:27:44 EDT
Verified this bug with on RHEL5u6 Server X86_64 KVM, and PASSED.

1. Start a guest, and check vcpu info
# virsh list --all
 Id Name                 State
  1 rhel5u5              running

# virsh vcpuinfo rhel5u5
VCPU:           0
CPU:            3
State:          running
CPU time:       17.6s
CPU Affinity:   yyyy

VCPU:           1
CPU:            1
State:          running
CPU time:       11.0s
CPU Affinity:   yyyy

2. Restart libvirtd service.
# service libvirtd restart
Stopping libvirtd daemon:                                  [  OK  ]
Starting libvirtd daemon:                                  [  OK  ]

3. Re-check vcpu info
# virsh vcpuinfo rhel5u5
VCPU:           0
CPU:            1
State:          running
CPU time:       17.7s
CPU Affinity:   yyyy

VCPU:           1
CPU:            1
State:          running
CPU time:       11.0s
CPU Affinity:   yyyy
Comment 6 min zhan 2010-10-25 06:04:51 EDT
Verified with Passed in below environments according to steps in comment 5:

Comment 8 errata-xmlrpc 2011-01-13 18:14:13 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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