Bug 1437013
Summary: | libvirt don't check vcpu 0 status when try to hot-plug or unplug vcpu 0 | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Luyao Huang <lhuang> |
Component: | libvirt | Assignee: | Peter Krempa <pkrempa> |
Status: | CLOSED ERRATA | QA Contact: | Jingjing Shao <jishao> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.4 | CC: | dyuan, pkrempa, rbalakri, xuzhang, yalzhang |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | libvirt-3.2.0-2.el7 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-08-01 17:24:15 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Luyao Huang
2017-03-29 09:40:07 UTC
Fixed upstream by: commit 315f443dbb9f821fb207c30585e01dfbaac01878 Author: Peter Krempa <pkrempa> Date: Fri Mar 31 13:02:14 2017 +0200 qemu: hotplug: Iterate over vcpu 0 in individual vcpu hotplug code Buggy condition meant that vcpu0 would not be iterated in the checks. Since it's not hotpluggable anyways we would not be able to break the configuration of a live VM. Hi Peter, I try to verify this bug but I find a something I can not understand clearly. When the guest is down, it will give the info " vcpu '1' can't be modified as it is followed by non-hotpluggable online vcpus". what is the meaning ? shouldn't it be vcpu'0' ? Why is it vcpu '1' ? Can you help to check it ? Thank you in advance. # rpm -q libvirt libvirt-3.2.0-5.el7.x86_64 # virsh dumpxml r7.2 | grep vcpu -A7 <vcpu placement='static' current='4'>10</vcpu> <vcpus> <vcpu id='0' enabled='yes' hotpluggable='no'/> <vcpu id='1' enabled='yes' hotpluggable='no'/> <vcpu id='2' enabled='yes' hotpluggable='yes'/> <vcpu id='3' enabled='yes' hotpluggable='yes'/> <vcpu id='4' enabled='no' hotpluggable='yes'/> <vcpu id='5' enabled='no' hotpluggable='yes'/> <vcpu id='6' enabled='no' hotpluggable='yes'/> <vcpu id='7' enabled='no' hotpluggable='yes'/> <vcpu id='8' enabled='no' hotpluggable='yes'/> <vcpu id='9' enabled='no' hotpluggable='yes'/> </vcpus> # virsh list --all Id Name State ---------------------------------------------------- 13 r7.2 running # virsh setvcpu r7.2 0 --enable error: invalid argument: vcpu '0' is already in requested state # virsh setvcpu r7.2 0 --disable error: Operation not supported: vcpu '0' can't be unplugged # virsh destroy r7.2 Domain r7.2 destroyed # virsh setvcpu r7.2 0 --enable error: invalid argument: vcpu '1' can't be modified as it is followed by non-hotpluggable online vcpus # virsh setvcpu r7.2 0 --disable error: invalid argument: vCPU '0' must be enabled The off by one in the vcpu index is the same issue as it was pointed out in https://bugzilla.redhat.com/show_bug.cgi?id=1437010#c4 . I've already posted a patch to fix it. With that patch it will produce the same message but with fixed vcpu number. There is still the issue of the message not being entirely correct since vcpu 0 is in the desired state and no other vcpus need to be changed, so the message is invalid. I will fix that eventually. You can create a bug to track it. (In reply to Peter Krempa from comment #5) OK, thanks for Peter’s reply and file a bug to track this issue. https://bugzilla.redhat.com/show_bug.cgi?id=1451983 For hot-plug and unplug vcpu 0 for running guest , the result is expected in comment4, so change the status to verified Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:1846 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:1846 |