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.
libvirt-0.9.4-18.el6.x86_64
virt-manager-0.9.0-7.el6.x86_64
To reproduce the bug, you need a scenario where hostdev hotplug will fail; one possibility is by using hardware that lacks secure VT-d, such as with:
$ echo 0 > /sys/module/kvm/parameters/allow_unsafe_assigned_interrupts
From there, choose a device to test; in my case:
$ readlink /sys/bus/pci/devices/0000:0a:0a.0/driver
../../../../bus/pci/drivers/firewire_ohci
$ virsh start dom
$ virt-manager
view the details of dom
click Add hardware
select PCI Host Device
scroll to the device probed above (in my case, 00:0a:0a)
hit finish
The hotplug fails (expected)
operation failed: adding pci-assign,host=0a:0a.0,id=hostdev0,configfd=fd-hostdev0,bus=pci.0,addr=0xa device failed: Device 'pci-assign' could not be initialized
hit no to adding the device
Check the device again:
$ readlink /sys/bus/pci/devices/0000:0a:0a.0/driver
../../../../bus/pci/drivers/pci-stub
Oops. The problem is that virt-manager manually called virNodeDeviceDettach prior to trying the hot-plug operation, but did not follow up with a virNodeDeviceReAttach on failure. Had it merely relied on managed=yes during the hotplug operation, then the virNodeDeviceDettach would not be necessary (but this would not be portable to pre-0.6.1 servers). So I think the proper fix is a combination - try managed=yes first; it will fail with older servers in which case you fall back to the old method, but when falling back, hotplug has to make sure that any manual detach is reattached on failure.
Likewise, on detach, I think that if the xml has managed=yes, you know you are talking to a new server, but if the xml lacks that (and also lacks managed=no), then you should ask the user whether to re-attach the hostdev when they use the gui to remove the passthrough device from a guest.
Worse, virt-manager is explicitly calling virNodeDeviceDettach even when attaching a PCI device to an offline guest. This prevents the host from using that device, even if there are no plans to start the guest right away. Really, virt-manager should only be calling virNodeDeviceDettach at the same points that libvirt would be emulating it for managed devices (that is, when starting a guest), since it is perfectly valid to have multiple persistent guests all claiming the same <hostdev>, so long as only one of the guests is running at a time (see bug 733587 for more details on a just-fixed libvirt bug for having multiple offline guests sharing a <hostdev>).
Reproduced with the following package:
python-virtinst-0.600.0-3.el6.noarch
Verified with
kernel-2.6.32-197.el6.x86_64
qemu-kvm-0.12.1.2-2.192.el6.x86_64
libvirt-0.9.4-19.el6.x86_64
python-virtinst-0.600.0-5.el6.noarch
virt-manager-0.9.0-7.el6.x86_64
step:
1.$ echo 0 > /sys/module/kvm/parameters/allow_unsafe_assigned_interrupts
2.# readlink /sys/bus/pci/devices/0000:00:19.0/driver
../../../bus/pci/drivers/e1000e
3.$ virsh start dom
4.$ virt-manager
view the details of dom
click Add hardware
select PCI Host Device
scroll to the listed pci device (in my case,00:19:0 interface eth0)
hit finish
The hotplug fails (expected)(Network is disconnected.)
internal error unable to execute QEMU command 'device_add': Device 'pci-assign' could not be initialized.
hit no to adding the device
Then the network is reconnected.
5.# readlink /sys/bus/pci/devices/0000:00:19.0/driver
../../../bus/pci/drivers/e1000e
So move the status of this bug to 'verified'.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
No description necessary
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.
http://rhn.redhat.com/errata/RHBA-2011-1643.html