I think I see and know the issue: I see USB device: [253327.057677] usb 2-2: Product: Porsche Desktop [253327.057678] usb 2-2: Manufacturer: LaCie being popped in and out On the host that becomes a sda block device: [253327.063052] scsi 0:0:0:0: Direct-Access LaCie P9230 1053 PQ: 0 ANSI: 6 [253327.063549] sd 0:0:0:0: Attached scsi generic sg0 type 0 [253327.063862] sd 0:0:0:0: [sda] 976754646 4096-byte logical blocks: (4.00 TB/3.64 TiB) And as expected I see it trying to get it to the guest, but then failing and taking it back to the host. The failure you get when trying to get it to the guest is that qemu is using libusb but fails to parse some paths due to apparmor protection. [253174.255525] audit: type=1400 audit(1548926822.872:80): apparmor="DENIED" operation="open" profile="libvirt-ceefdf25-15b3-4f3b-8d64-9a9d287daa23" name="/run/udev/data/+usb:1-9:1.0" pid=14844 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=0 [253174.255565] audit: type=1400 audit(1548926822.872:81): apparmor="DENIED" operation="open" profile="libvirt-ceefdf25-15b3-4f3b-8d64-9a9d287daa23" name="/run/udev/data/c189:5" pid=14844 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=0 [253174.255671] audit: type=1400 audit(1548926822.872:82): apparmor="DENIED" operation="open" profile="libvirt-ceefdf25-15b3-4f3b-8d64-9a9d287daa23" name="/run/udev/data/c189:0" pid=14844 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=0 [253174.255695] audit: type=1400 audit(1548926822.872:83): apparmor="DENIED" operation="open" profile="libvirt-ceefdf25-15b3-4f3b-8d64-9a9d287daa23" name="/run/udev/data/+usb:1-8:1.1" pid=14844 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=0 [253174.255798] audit: type=1400 audit(1548926822.872:84): apparmor="DENIED" operation="open" profile="libvirt-ceefdf25-15b3-4f3b-8d64-9a9d287daa23" name="/run/udev/data/+usb:1-6:1.0" pid=14844 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=0 [253174.255839] audit: type=1400 audit(1548926822.872:85): apparmor="DENIED" operation="open" profile="libvirt-ceefdf25-15b3-4f3b-8d64-9a9d287daa23" name="/run/udev/data/+usb:2-2:1.0" pid=14844 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=0 I upstreamed fixes for that a while ago: https://libvirt.org/git/?p=libvirt.git;a=commit;h=d4d50bcc799cd3790004ed70c7fe63ec584a2456 https://libvirt.org/git/?p=libvirt.git;a=commit;h=bf3a4140877299cf351821518d269bcd4888f2f1 That made it into libvirt 4.0 in Bionic (18.04) via bug 1727311 As there is a minimal security risk opening these up for the guests we didn't want to SRU that back to Xenial. Especially since the few users who need it there can add it manually. You could upgrade to 18.04, or if you want to stick to 16.04 for now you can fix the config manually by opting in to the new rules. In 16.04 you already have these rules: # For hostdev access. The actual devices will be added dynamically /sys/bus/usb/devices/ r, /sys/devices/**/usb[0-9]*/** r, please add the following lines as well in file /etc/apparmor.d/abstractions/libvirt-qemu # libusb needs udev data about usb devices (~equal to content of lsusb -v) /run/udev/data/c16[6,7]* r, /run/udev/data/c18[0,8,9]* r, /run/udev/data/+usb* r, Then shut down and start your guest again (to pick up the new profile). That would eliminate at least this issue and your usb passthrough should work. Note: There was something else with usb passthrough on 16.04, but I can't remember exactly. I checked my logs and found bug 1552241 For that please also add these lines in the same file: /sys/devices/*/*/usb[0-9]*/** r, /run/udev/data/** r, There would also be another issue if you'd not hot-add the device but assign it statically to the guest config (also in bug 1552241), but for that you'd need to upgrade to 18.04 - fortunately you want to hot add the device so that doesn't matter for now. If it doesn't work after the fix above please report back with new logs so I can try helping again.