Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1518148 - Fail to attach interface after libvirtd restart
Summary: Fail to attach interface after libvirtd restart
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Ján Tomko
QA Contact: yalzhang@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-28 10:32 UTC by Jingjing Shao
Modified: 2018-04-10 11:01 UTC (History)
8 users (show)

Fixed In Version: libvirt-3.9.0-5.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-10 11:00:58 UTC


Attachments (Terms of Use)
Problematic vm xml (deleted)
2017-12-01 14:04 UTC, yalzhang@redhat.com
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:0704 None None None 2018-04-10 11:01:32 UTC
Red Hat Bugzilla 1434451 None CLOSED [RFE] allow to set device alias at XML define time 2019-01-10 14:26:19 UTC

Internal Links: 1434451

Description Jingjing Shao 2017-11-28 10:32:44 UTC
Description of problem:
Fail to attach interface after libvirtd restart

Version-Release number of selected component (if applicable):
libvirt-3.9.0-3.virtcov.el7.x86_64

How reproducible:
100%

Steps to reproduce:
1. Prepare a running guest with info as below
# virsh dumpxml rhel | grep /interface  -B7
    <interface type='network'>
      <mac address='52:54:00:c2:66:40'/>
      <source network='default' bridge='virbr0'/>
      <target dev='vnet0'/>
      <model type='rtl8139'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>


2.Restart the libvirtd
# service libvirtd restart
Redirecting to /bin/systemctl restart libvirtd.service


3. Attach the interface
#  virsh attach-interface rhel network default
error: Failed to attach interface
error: internal error: unable to execute QEMU command 'device_add': Bus 'pci' not found


Actual results:
As the step3 shows


Expected results:
Interface attached successfully


Addtional info:

Test on libvirt-3.9.0-2.el7.x86_64 no such issue

Comment 3 Ján Tomko 2017-11-28 13:53:19 UTC
Proposed upstream patch:
https://www.redhat.com/archives/libvir-list/2017-November/msg01139.html

Comment 5 Ján Tomko 2017-11-30 16:07:27 UTC
Pushed upstream as:
commit 309cd46b400d80420615b19adfebf7158492ae3b
    Introduce virDomainDeviceAliasIsUserAlias

commit dacfc6b10bcff1c275d21a37edf0bc83e0947492
    qemu: prefer the PCI bus alias from status XML

commit fdf354fb51e7f00b582d0daa18961d432155df83
    virQEMUCapsHasPCIMultiBus: use def->os.arch

commit 65108d94d093de082dc5a2d4a73844dd569506db
CommitDate: 2017-11-30 16:49:05 +0100

    virQEMUCapsHasPCIMultiBus: assume true if we have no version information

git describe: v3.10.0-rc1-9-g65108d94d

Comment 7 yalzhang@redhat.com 2017-12-01 14:02:05 UTC
Hi Ján Tomko,

I have test the scratch build with latest qemu-kvm-rhev-2.10.0-10.el7.x86_64 on a new created vm, it works well. 

But on one other vm, the hotplug always fail, coldplug is ok. 
I tried to find the difference between the 2 vm's xml, but can not find any clue. Then I tried on another host with the problematic xml, it still fail with the scratch build.The error message says:

# virsh attach-interface rhel7.4 network default
error: Failed to attach interface
error: internal error: unable to execute QEMU command 'device_add': Bus 'pci.0' does not support hotplugging

And I attached the problematic xml, could you please help to debug?

Comment 8 yalzhang@redhat.com 2017-12-01 14:04:10 UTC
Created attachment 1361609 [details]
Problematic vm xml

Problematic vm xml

Comment 9 Ján Tomko 2017-12-01 14:10:15 UTC
ACPI needs to be enabled for PCI hotplug: (I'm not sure if it can work through SHPC without ACPI)
<features>
  <acpi/>
</features>

Comment 10 jiyan 2017-12-04 10:25:56 UTC
Same issue for virtio input device
https://bugzilla.redhat.com/show_bug.cgi?id=1509866#c11

Comment 12 yalzhang@redhat.com 2018-01-14 07:09:16 UTC
Test on libvirt-3.9.0-7.el7.x86_64, the bug is fixed. Set it as verified.

1. 
# virsh dumpxml rhel | grep /interface -B9

# systemctl restart libvirtd

# virsh attach-interface rhel network default --model virtio --mac 52:54:00:8f:c2:f1
Interface attached successfully

# virsh dumpxml rhel | grep /interface -B7
    <interface type='network'>
      <mac address='52:54:00:8f:c2:f1'/>
      <source network='default' bridge='virbr0'/>
      <target dev='vnet0'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

2. restart libvirtd, then attach device with alias name
# systemctl restart libvirtd
# cat inter.xml
<interface type='network'>
      <source network='default' bridge='virbr0'/>
      <model type='virtio'/>
<alias name='ua-myinterface'/>    
</interface>

# virsh attach-device rhel inter.xml 
Device attached successfully

# virsh dumpxml rhel | grep /interface -B7
    <interface type='network'>
      <mac address='52:54:00:8f:c2:f1'/>
      <source network='default' bridge='virbr0'/>
      <target dev='vnet0'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <interface type='network'>
      <mac address='52:54:00:2b:bb:d4'/>
      <source network='default' bridge='virbr0'/>
      <target dev='vnet1'/>
      <model type='virtio'/>
      <alias name='ua-myinterface'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
    </interface>

Comment 16 errata-xmlrpc 2018-04-10 11:00:58 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-2018:0704


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