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 is 
not a matter of will, but time to develop those.

** Changed in: libvirt (Ubuntu)
       Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1708013

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1708013/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to