USB passthrough not working: failed to find host usb device 1:2

Bug #1708013 reported by Gannet
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libvirt (Ubuntu)
Incomplete
Undecided
Unassigned

Bug Description

Trying to passthrough USB Flash drive I'm getting the following error massage:

Virsh

virsh -d 4 start Kubuntu-17.04-x86_64-14GiB
error: Failed to start domain Kubuntu-17.04-x86_64-14GiB
error: internal error: qemu неочікувано завершив роботу монітора: 2017-08-01T20:47:12.796661Z qemu-system-x86_64: -device usb-host,hostbus=1,hostaddr=3,id=hostdev0,bus=usb.0,port=4: failed to find host usb device 1:2

Virt-manager

Помилка під час запуску домену: internal error: процес завершив роботу під час спроби встановлення з’єднання з монітором: .0,addr=0x4 -device ioh3420,port=0x28,chassis=4,id=pci.4,bus=pcie.0,addr=0x5 -device ioh3420,port=0x30,chassis=5,id=pci.5,bus=pcie.0,addr=0x6 -device ich9-usb-ehci1,id=usb,bus=pcie.0,addr=0x1d.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pcie.0,multifunction=on,addr=0x1d -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pcie.0,addr=0x1d.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pcie.0,addr=0x1d.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x0 -drive file=/var/lib/libvirt/images/Kubuntu-17.04-x86_64-14GiB.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,cache=unsafe -device virtio-blk-pci,scsi=off,bus=pci.3,addr=0x0,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,media=cdrom,id=drive-sata0-0-0,readonly=on -device ide-cd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0 -netdev tap,fd=26,id=hostnet0 -devic

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 88, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 124, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1467, in startup
    self._backend.create()
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 1035, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error: процес завершив роботу під час спроби встановлення з’єднання з монітором: .0,addr=0x4 -device ioh3420,port=0x28,chassis=4,id=pci.4,bus=pcie.0,addr=0x5 -device ioh3420,port=0x30,chassis=5,id=pci.5,bus=pcie.0,addr=0x6 -device ich9-usb-ehci1,id=usb,bus=pcie.0,addr=0x1d.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pcie.0,multifunction=on,addr=0x1d -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pcie.0,addr=0x1d.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pcie.0,addr=0x1d.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x0 -drive file=/var/lib/libvirt/images/Kubuntu-17.04-x86_64-14GiB.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,cache=unsafe -device virtio-blk-pci,scsi=off,bus=pci.3,addr=0x0,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,media=cdrom,id=drive-sata0-0-0,readonly=on -device ide-cd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0 -netdev tap,fd=26,id=hostnet0 -devic

Kubuntu 17.04
qemu 2.8+dfsg-3ubuntu2.3
virt-manager/virtinst 1.4.0

ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: libvirt-bin 2.5.0-3ubuntu5.3
Uname: Linux 4.12.3-041203-generic x86_64
ApportVersion: 2.20.4-0ubuntu4.5
Architecture: amd64
CurrentDesktop: KDE
Date: Tue Aug 1 23:18:22 2017
InstallationDate: Installed on 2014-06-08 (1150 days ago)
InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1)
SourcePackage: libvirt
UpgradeStatus: Upgraded to zesty on 2017-03-04 (150 days ago)

Revision history for this message
Gannet (ken20001) wrote :
description: updated
Gannet (ken20001)
description: updated
description: updated
Revision history for this message
Joshua Powers (powersj) wrote :

Thank you for taking the time to file a bug report.

Can you verify by running `lsusb` that the device is actually there? Has
this worked in the past and suddenly stopped working?

Since there is not enough information in your report to begin triage or to
differentiate between a local configuration problem and a bug in Ubuntu, I
am marking this bug as "Incomplete". We would be grateful if you would:
provide a more complete description of the problem, explain why you
believe this is a bug in Ubuntu rather than a problem specific to your
system, and then change the bug status back to "New".

For local configuration issues, you can find assistance here:
http://www.ubuntu.com/support/community

Changed in libvirt (Ubuntu):
status: New → Incomplete
Revision history for this message
Gannet (ken20001) wrote :

Hello, Joshua. Not a problem since I'm all the time using KVM.

>Can you verify by running `lsusb` that the device is actually there?

$ lsusb
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 003: ID 055f:021f Mustek Systems, Inc. SNAPSCAN e22
Bus 008 Device 002: ID 04b4:0033 Cypress Semiconductor Corp. Mouse
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 002: ID 045e:00f7 Microsoft Corp. LifeCam VX-1000
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 0951:1666 Kingston Technology DataTraveler G4 <-- Here it is
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

>Has this worked in the past and suddenly stopped working?
In a past VM booted well at list. Most of the time I've had a problem with passthrough USB-devices. Only sometimes after passthrough they was appeared in guest system. But anyway all the time guest system has been booted. But now it is even not able to boot.

Please, ask for any additional info if needed.

Thanks.

Changed in libvirt (Ubuntu):
status: Incomplete → New
Revision history for this message
Gannet (ken20001) wrote :

Also, please, look at video: https://youtu.be/PK-YmSBtJIc

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

I wonder if that is a dup of bug 1686324 - the message your case reports is slightly different, but those could change with versions.

To check that I'd ask you to - after starting the failing guest - check your dmesg if you have any apparmor Denials?
If so please report them here so we can check if this is a known issue.
Please also report back if you have no related apparmor Denials so we can discuss about other potential reasons.

Changed in libvirt (Ubuntu):
status: New → Incomplete
Revision history for this message
Gannet (ken20001) wrote :

No, I didn't found any apparmor denials - the same is before and the same is after failing guest:

dmesg | grep -i apparmor
[ 0.012143] AppArmor: AppArmor initialized
[ 0.380003] AppArmor: AppArmor Filesystem Enabled
[ 1.234176] AppArmor: AppArmor sha1 policy hashing enabled
[ 10.461303] systemd[1]: systemd 232 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)

I even switched it off by:

systemctl stop apparmor.service

but nothing is changed. Guest is still fails to start.

Changed in libvirt (Ubuntu):
status: Incomplete → New
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :
Download full text (3.2 KiB)

Thanks for checking apparmor, I wonder as you at least would have some positive messages usually, like:
... apparmor="STATUS" operation="profile_load" ...

On checking the further messages I was confused at first with your initial message being:
...hostbus=1,hostaddr=3 ... failed to find host usb device 1:2

See 1:3 vs 1:2 here?

But you video - while I can't read any words is clearly on 1:2 and missing 1:2.
You could check the xml that virt-manager generated for you on the USB device - maybe there is something odd there.

In the hope to recreate I fetches a USB Flash drive and tested with that here.
lsusb:
Bus 003 Device 003: ID 0781:5580 SanDisk Corp. SDCZ80 Flash Drive
Virt-Manager adds this as:
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x0781'/>
        <product id='0x5580'/>
      </source>
      <address type='usb' bus='0' port='3'/>
    </hostdev>

As I expected I got apparmor messages (there is a known issue, bug 1552241 matches more actually).
So I got your error:
  -device usb-host,hostbus=3,hostaddr=3,id=hostdev0,bus=usb.0,port=3: failed to find host usb device 3:3

But just as I expected due to bug 1552241 by the apparmor Denials:
apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-5c"
apparmor="DENIED" operation="open" profile="libvirt-5c" name="/run/udev/data/c189:1"
apparmor="DENIED" operation="open" profile="libvirt-5c" name="/run/udev/data/c189:138"
apparmor="DENIED" operation="open" profile="libvirt-5c" name="/run/udev/data/c189:130"
apparmor="DENIED" operation="open" profile="libvirt-5c" name="/run/udev/data/c189:132"
apparmor="DENIED" operation="open" profile="libvirt-5c" name="/run/udev/data/c189:134"
apparmor="DENIED" operation="open" profile="libvirt-5c" name="/run/udev/data/c189:136"
apparmor="DENIED" operation="open" profile="libvirt-5c" name="/run/udev/data/c189:258"

I wonder what is different for you not seeing the messages, but it seems so similar.
You are likely affected by both bugs as you are doing a static usb passthrough.
That could explain why you fail even with apparmor disabled

The TL;DR on the apparmor issue is (bug 1552241):
- "real solution" needs to be developed for upstream instead of a global blanket
- otherwise it is considered too insecure
- until then usb passthrough users have to opt-in by opening up the apparmor profile a bit

The TL;DR on the static added usb issue is (bug 1686324):
- "real solution" needs to be developed for upstream instead of a global blanket
- otherwise it is considered too insecure
- until then static usb passthrough users have open up the profile matching their device

You can be more granular or gloabl on the IDs (see the relate dbug), but e.g. adding
  # avoid bug 1552241 by opening up globally for now
  /run/udev/data/* r,
  # free the particular device to work around bad rule generation in bug 1686324
  "/dev/bus/usb/003/003" rw,
to
  /etc/apparmor.d/abstractions/libvirt-qemu

That got me going as documented in the two referred bugs already.
Could you confirm that these workarounds are good for you as well, then I'd close it as a dub and take it as a reminder for the virt-aa bugs - but it ...

Read more...

Changed in libvirt (Ubuntu):
status: New → Incomplete
Revision history for this message
Gannet (ken20001) wrote :

Hello. You've been completely right. I've just added the following line:

/run/udev/data/* r,

into /etc/apparmor.d/abstractions/libvirt-qemu.

And all started to work fine. I've checked Kubuntu 17.04 and Windows as a guests on Kubuntu 17.04 host. It works from start and as hotplug. So, when it will be fixed in upstream? Should we wait for fix on upcoming 17.10 ?

Thanks a lot for workaround.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

HI Gannet,
thanks for confirming.

The workaround is needed for quite a while and actually also documented in the community wiki to guide users. I keep forgetting that but [1] is good about that.

I'll dup the bug onto the one I use to track.
In terms of the timing of an estimated fix I unfortunately can't make any promises. There is a whole chunk of work for virt-aa-helper that needs to be done [2], but done right instead of adding too open rules. So for now I only tackle veri critical and not workaroundable bugs in that regard and hope to increase the need for [2] to a point where I priorities can make it happen. But all that is Opensource - so anybody who wants/can can jump in on that list and help.

[1]: https://help.ubuntu.com/community/KVM/Managing#Adding_USB_Device_Pass-through
[2]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bugs?field.tag=virt-aa-helper

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.