Bug 1016511 - hotplugging USB device by vendor/product fails: Path '/dev/bus/usb/000/000' is not accessible
Summary: hotplugging USB device by vendor/product fails: Path '/dev/bus/usb/000/000' i...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1036473 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-08 10:00 UTC by Miroslav Rezanina
Modified: 2013-12-31 01:55 UTC (History)
17 users (show)

Fixed In Version: libvirt-1.1.3.2-1.fc20
Clone Of:
Environment:
Last Closed: 2013-12-31 01:55:48 UTC
Type: Bug
Embargoed:


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

Description Miroslav Rezanina 2013-10-08 10:00:10 UTC
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">
   <source>
    <vendor id="0x090c"/>
    <product id="0x1000"/>
  </source>
</hostdev>


Version-Release number of selected component (if applicable):
libvirt-client-1.1.3-2.fc20

How reproducible:
Always

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

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 10:50:35 UTC
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
    self.vm.attach_device(self._dev)
  File "/usr/share/virt-manager/virtManager/domain.py", line 851, in attach_device
    self._backend.attachDevice(devxml)
  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 18:20:27 UTC
I get the same error.

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

/dev/bus/usb/001:
001  002  003  004  005  006  007

/dev/bus/usb/002:
001  002  003  004  005  006  007  008  009  010  011

Comment 3 Sam Azer 2013-10-19 01:53:49 UTC
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.

Thanks!

Comment 4 Sam Azer 2013-10-19 15:57:00 UTC
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 05:23:32 UTC
Created attachment 831432 [details]
workaround.patch

Comment 6 Eric Shattow 2013-12-02 05:25:09 UTC
*** Bug 1036473 has been marked as a duplicate of this bug. ***

Comment 7 Cole Robinson 2013-12-05 18:11:12 UTC
(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 18:18:12 UTC
I fixed one part of it by v1.1.4-90-g05e149f:

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

    qemu: Call qemuSetupHostdevCGroup later during hotplug
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1025108
    
    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 18:21:58 UTC
This fixes it for me:

http://www.redhat.com/archives/libvir-list/2013-December/msg00338.html

Comment 10 Cole Robinson 2013-12-09 22:30:25 UTC
All patches pushed to upstream maint branch now

Comment 11 Fedora Update System 2013-12-14 21:34:24 UTC
libvirt-1.1.3.2-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/libvirt-1.1.3.2-1.fc20

Comment 12 Fedora Update System 2013-12-16 07:07:45 UTC
Package libvirt-1.1.3.2-1.fc20:
* 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-1.1.3.2-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-23446/libvirt-1.1.3.2-1.fc20
then log in and leave karma (feedback).

Comment 13 Fedora Update System 2013-12-31 01:55:48 UTC
libvirt-1.1.3.2-1.fc20 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.