Bug 1016511 - hotplugging USB device by vendor/product fails: Path '/dev/bus/usb/000/000' is not accessible
hotplugging USB device by vendor/product fails: Path '/dev/bus/usb/000/000' i...
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Libvirt Maintainers
Fedora Extras Quality Assurance
: 1036473 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2013-10-08 06:00 EDT by Miroslav Rezanina
Modified: 2013-12-30 20:55 EST (History)
17 users (show)

See Also:
Fixed In Version: libvirt-
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-12-30 20:55:48 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
workaround.patch (500 bytes, patch)
2013-12-02 00:23 EST, Eric Shattow
no flags Details | Diff

  None (edit)
Description Miroslav Rezanina 2013-10-08 06:00:10 EDT
Description of problem:

When trying to hotplug usb device to guest, got following error:

error: Failed to attach device from /tmp/hd
error: Path '/dev/bus/usb/000/000' is not accessible: No such file or directory

Content of /tmp/hd:

<hostdev mode="subsystem" type="usb">
    <vendor id="0x090c"/>
    <product id="0x1000"/>

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Start guest
2. use virsh attach-device guestname configfile

Actual results:
Got error mentioned above

Expected results:
USB device attached to guest and visible inside

Additional info:
Same procedure works on F19 (same setting and usb device)
Comment 1 Tadej Janež 2013-10-09 06:50:35 EDT
I was following the Hotplug USB device to guest test case of the F20 Virtualization test day and got a silimar error:

Path '/dev/bus/usb/000/000' is not accessible: No such file or directory

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/addhardware.py", line 1261, in add_device
  File "/usr/share/virt-manager/virtManager/domain.py", line 851, in attach_device
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 429, in attachDevice
    if ret == -1: raise libvirtError ('virDomainAttachDevice() failed', dom=self)
libvirtError: Path '/dev/bus/usb/000/000' is not accessible: No such file or directory

Steps to Reproduce:
In my case, I peformed everything through virt-manager:
1. Start the VM
2. Add Hardware->USB Host Device
3. Choose the device you want to assign from the list, like: 009:002 SanDisk Extreme
4. Click Finish
Comment 2 Zbigniew Jędrzejewski-Szmek 2013-10-18 14:20:27 EDT
I get the same error.

% ls -R /dev/bus/usb/
001/  002/

001  002  003  004  005  006  007

001  002  003  004  005  006  007  008  009  010  011
Comment 3 Sam Azer 2013-10-18 21:53:49 EDT
Everthing was working fine for me just yesterday under K/Ubuntu 13.04. Apparently the upgrade to 13.10 uses more recent software. Now I am getting the same error as described above. In addition my Windows 7 VM does not connect to my mobile device any longer (ie: if I setup the USB device before booting the VM.)

At first I thought the problem was AppArmor so I set security_driver = "none" in /etc/libvirt/qemu.conf.

Now when I setup the USB device then boot my Windows 7 VM I see the name of my mobile device in the properties for the USB Device.

If I remove the device and try to add it again I get the error documented above. Using lsusb I can find the bus and device numbers. I can then:

mkdir /dev/bus/usb/000
ln -s /dev/bus/usb/002/003 /dev/bus/000/000

and finally I add the USB device hardware to the running VM and no error is reported. In addition I once again see the device name in the properties of the USB device.

Once again, though, the Mobile Device Manager running in the Windows 7 VM does not connect with the mobile device.

Unfortunately this is a serious problem for me just now. I might be forced to backup my system and re-install K/Ubuntu 13.04 over this one small bug. If anybody can suggest a workaround I'd be happy to try it.

Comment 4 Sam Azer 2013-10-19 11:57:00 EDT
FYI installed some new updates this morning (including a udev & libudev update) and now have my USB passthrough working again. The remaining error seems to be only the reference to /dev/bus/usb/000/000 where the 000/000 are not updated to the correct bus and device numbers. Thanks again, --Sam.
Comment 5 Eric Shattow 2013-12-02 00:23:32 EST
Created attachment 831432 [details]
Comment 6 Eric Shattow 2013-12-02 00:25:09 EST
*** Bug 1036473 has been marked as a duplicate of this bug. ***
Comment 7 Cole Robinson 2013-12-05 13:11:12 EST
(In reply to Eric Shattow from comment #5)
> Created attachment 831432 [details]
> workaround.patch

Indeed that works around it by forcing virt-manager to always specify a bus/addr, but that's not ideal for a variety of reasons, and doesn't fix the underlying issue.

I've identified the problem in libvirt and will post patches shortly
Comment 8 Jiri Denemark 2013-12-05 13:18:12 EST
I fixed one part of it by v1.1.4-90-g05e149f:

commit 05e149f94cbd34e4c3d4e9c7f6871e13cfe03d8c
Author: Jiri Denemark <jdenemar@redhat.com>
Date:   Thu Nov 14 12:02:40 2013 +0100

    qemu: Call qemuSetupHostdevCGroup later during hotplug
    So far qemuSetupHostdevCGroup was called very early during hotplug, even
    before we knew the device we were about to hotplug was actually
    available. By calling the function later, we make sure QEMU won't be
    allowed to access devices used by other domains.
    Another important effect of this change is that hopluging USB devices
    specified by vendor and product (but not by their USB address) works
    again. This was broken since v1.0.5-171-g7d763ac, when the call to
    qemuFindHostdevUSBDevice was moved after the call to
    qemuSetupHostdevCGroup, which then used an uninitialized USB address.

But security labeling is affected in a way similar to how qemuSetupHostdevCGroup was affected. See bug 1025108.
Comment 9 Cole Robinson 2013-12-05 13:21:58 EST
This fixes it for me:

Comment 10 Cole Robinson 2013-12-09 17:30:25 EST
All patches pushed to upstream maint branch now
Comment 11 Fedora Update System 2013-12-14 16:34:24 EST
libvirt- has been submitted as an update for Fedora 20.
Comment 12 Fedora Update System 2013-12-16 02:07:45 EST
Package libvirt-
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libvirt-'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 13 Fedora Update System 2013-12-30 20:55:48 EST
libvirt- has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

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