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: libvirtAssignee: Peter Krempa <pkrempa>
Status: CLOSED ERRATA QA Contact: Jingjing Shao <jishao>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.4CC: 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
Description of problem:
libvirt don't check vcpu 0 status when try to hot-plug or unplug vcpu 0

Version-Release number of selected component (if applicable):
libvirt-3.1.0-2.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.prepare a running guest

# virsh dumpxml r7
<domain type='kvm' id='2'>
  <name>r7</name>
  <uuid>67c7a123-5415-4136-af62-a2ee098ba6cd</uuid>
  <maxMemory slots='16' unit='KiB'>15243264</maxMemory>
  <memory unit='KiB'>1048576</memory>
  <currentMemory unit='KiB'>1048576</currentMemory>
  <vcpu placement='static' current='5'>10</vcpu>
  <vcpus>
    <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/>
    <vcpu id='1' enabled='yes' hotpluggable='no' order='2'/>
    <vcpu id='2' enabled='yes' hotpluggable='no' order='3'/>
    <vcpu id='3' enabled='yes' hotpluggable='no' order='4'/>
    <vcpu id='4' enabled='yes' hotpluggable='no' order='5'/>
    <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>

2. try hot-plug and unplug on vcpu 0:

# virsh setvcpu r7 0 --enable
error: internal error: unable to execute QEMU command 'device_add': CPU[0] with APIC ID 0 exists

# virsh setvcpu r7 0 --disable
error: internal error: unable to execute QEMU command 'device_del': Device 'vcpu0' not found

3.

Actual results:

libvirt shouldn't try to use qmp cmd to hot-plug or unplug vcpu0 before a check

Expected results:

# virsh setvcpu r7 0 --enable
error: invalid argument: vcpu '0' is already in requested state

# virsh setvcpu r7 0 --disable
error: Operation not supported: vcpu '0' can't be unplugged

Additional info:

Comment 1 Peter Krempa 2017-04-04 07:22:40 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.

Comment 4 Jingjing Shao 2017-05-17 09:18:18 UTC
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

Comment 5 Peter Krempa 2017-05-17 15:40:59 UTC
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.

Comment 6 Jingjing Shao 2017-05-18 06:06:35 UTC
(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

Comment 7 errata-xmlrpc 2017-08-01 17:24:15 UTC
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

Comment 8 errata-xmlrpc 2017-08-02 00:03:43 UTC
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