Description of problem: USB device is not accessible when added via virt-manager Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Click on Info 2. Add New Hardware 3. Select USB 4. Select device from list 5. Start VM 6. can't access usb device Actual results: XML file has vendor id and product id. This doesn't appear to work. Expected results: If you get the Bus and Device from lsusb and change the XML file, it works. Additional info: virt-manager should add BUS/DEVICE id instead of Vendor/Product ID to XML file.
To be fair, virt-manager is really doing the right thing here, since device/address is not stable across device plug/unplug. The real issue is that libvirt is not able to handle vendor/product permissioning.
Is there a bug for libvirt and permissioning? This worked under Fedora 11, although since I upgraded the system, I don't know if it was using device/address or vendor/product. I did turn off SELInux in case that was the issue. Is there a work around (setting perms)? Is this something that will be fixed?
*** Bug 549500 has been marked as a duplicate of this bug. ***
*** Bug 543839 has been marked as a duplicate of this bug. ***
I am the one that reported bug 543839 that has been marked as duplicated of this one and, just in case, I wanted to point out that I had selinux disabled in /etc/selinux/config. I tried the tip above to add the usb dongle by hand in the xml file indicating bus and device and it worked beautifully.
Disabling selinux likely won't help, this is actually an issue with libvirt auto changing path permissions/labels as mentioned in comment #2. I've changed the bug title to reflect reality.
*** Bug 553068 has been marked as a duplicate of this bug. ***
The libvirt fixes are upstream, so moving this to post. I'll look into backporting the changes.
There is a libvirt update in updates-testing, heading to stable, that should fix this issue. Closing as a dup of the libvirt bug tracking this: https://bugzilla.redhat.com/show_bug.cgi?id=537227 *** This bug has been marked as a duplicate of bug 537227 ***