Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Without <acpi> feature, virsh setvcpus not fail and xml/vcpucount/vcpuinfo updated.
Version-Release number of selected component (if applicable):
libvirt-1.1.1-2.el7.x86_64
How reproducible:
always
Steps to Reproduce:
1. edit domain
...
<features>
<apic/>
<pae/>
</features>
...
<vcpu current='1'>3</vcpu>
...
No <acpi> feature and current as 1.
2. start domain
# virsh start rhel7
Domain rhel7 started
Login the guest and check
# cat /proc/cpuinfo|grep processor|wc -l
1
3. Hotplug the vcpu
# virsh setvcpus rhel7 2
# echo $?
0
# virsh dumpxml rhel7
...
<vcpu placement='static' current='2'>4</vcpu>
...
# virsh vcpucount rhel7
maximum config 32
maximum live 32
current config 1
current live 2
# virsh vcpuinfo rhel7
VCPU: 0
CPU: 8
State: running
CPU time: 12.9s
CPU Affinity: yyyyyyyyyyyyyyyy
VCPU: 1
CPU: 12
State: running
CPU Affinity: yyyyyyyyyyyyyyyy
Login the guest and check
# cat /proc/cpuinfo|grep processor|wc -l
1
Actual results:
hotplug fail but vcpu info updated
Expected results:
xml not updated
Additional info:
Created attachment 792793[details]
setvcpus libvirtd log
(In reply to Peter Krempa from comment #2)
> What version of qemu did you use in the host? What is the guest OS? Could
> you please attach the libvirtd debug log?
pkgs:
libvirt-1.1.1-3.el7.x86_64
qemu-kvm-1.5.2-3.el7.x86_64
kernel-3.10.0-3.el7.x86_64
the guest os is rhel7.0 with:
kernel-3.10.0-2.el7.x86_64
the libvirtd log is attached
According to libvirt's log qemu adds the CPU successfully:
2013-09-02 10:23:32.197+0000: 24649: debug : qemuMonitorIOWrite:465 : QEMU_MONITOR_IO_WRITE: mon=0x7f1a00003370 buf={"execute":"cpu-add","arguments":{"id":2},"id":"libvirt-9"} len=61 ret=61 errno=11
and the reply is:
2013-09-02 10:23:32.210+0000: 24649: debug : qemuMonitorIOProcess:357 : QEMU_MONITOR_IO_PROCESS: mon=0x7f1a00003370 buf={"return": {}, "id": "libvirt-9"} len=35
If you then list the vcpu threads in qemu you get the following info:
2013-09-02 10:23:32.213+0000: 24649: debug : qemuMonitorIOWrite:465 : QEMU_MONITOR_IO_WRITE: mon=0x7f1a00003370 buf={"execute":"query-cpus","id":"libvirt-10"}
len=44 ret=44 errno=11
2013-09-02 10:23:32.223+0000: 24649: debug : qemuMonitorIOProcess:357 : QEMU_MONITOR_IO_PROCESS: mon=0x7f1a00003370 buf={"return": [{"current": true, "CPU": 0, "pc": -2130440442, "halted": true, "thread_id": 28843}, {"current": false, "CPU": 1, "pc": 4294967280, "halted": false, "thread_id": 28858}, {"current": false, "CPU": 2, "pc": 4294967280, "halted": false, "thread_id": 28864}], "id": "libvirt-10"}
len=288
Thus qemu correctly adds a second CPU thread and initializes it. This means that we don't detect any problem and update the count in the guest XML.
The main problem is that qemu doesn't complain about ACPI not being present. Libvirt unfortunately can't forbid cpu-hotplug on non-ACPI guests as the ACPI factor is platform specific and might not represent the state on other platforms.
Moving to qemu-kvm to investigate if the "cpu-add" QMP command should return success if ACPI is disabled on a x86-64 guest.
CPU is hotplugged even without ACPI but guest is not notified about it due to
lack of ACPI hardware component. Hence guest will see hotplugged CPU only after reboot, without shutting VM down.
Issue not critical, so won't fix for RHEL7 and RHEV7.1
for RHEV7.2 there will be an extra check for ACPI introduced by upstream commit:
5279569e pc: add cpu hotplug handler to PC_MACHINE
Description of problem: Without <acpi> feature, virsh setvcpus not fail and xml/vcpucount/vcpuinfo updated. Version-Release number of selected component (if applicable): libvirt-1.1.1-2.el7.x86_64 How reproducible: always Steps to Reproduce: 1. edit domain ... <features> <apic/> <pae/> </features> ... <vcpu current='1'>3</vcpu> ... No <acpi> feature and current as 1. 2. start domain # virsh start rhel7 Domain rhel7 started Login the guest and check # cat /proc/cpuinfo|grep processor|wc -l 1 3. Hotplug the vcpu # virsh setvcpus rhel7 2 # echo $? 0 # virsh dumpxml rhel7 ... <vcpu placement='static' current='2'>4</vcpu> ... # virsh vcpucount rhel7 maximum config 32 maximum live 32 current config 1 current live 2 # virsh vcpuinfo rhel7 VCPU: 0 CPU: 8 State: running CPU time: 12.9s CPU Affinity: yyyyyyyyyyyyyyyy VCPU: 1 CPU: 12 State: running CPU Affinity: yyyyyyyyyyyyyyyy Login the guest and check # cat /proc/cpuinfo|grep processor|wc -l 1 Actual results: hotplug fail but vcpu info updated Expected results: xml not updated Additional info: