Adding USB host device, USB drive to guest VM fails, mounts drive in Nautilus instead

[Eero Aaltonen]

Oh, boy; this involves several systems.

Experienced in QEMU UI (Virtual Machine Manager). Guest OS (Windows) was running, tried to add "Add hardware"→"USB Host Device"→USB drive.

Expected result:
Guest OS (Windows) sees new USB device.

Actual result:
Some window flickering (apparently several things happening) and after that a Nautilus window opens and the drive is mounted in Ubuntu instead.

On the second attempt, results otherwise similar expect three (3) Nautilus windows open.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: qemu 1:2.5+dfsg-5ubuntu10.34
ProcVersionSignature: Ubuntu 4.15.0-43.46~16.04.1-generic 4.15.18
Uname: Linux 4.15.0-43-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.18
Architecture: amd64
CurrentDesktop: Unity
Date: Thu Jan 31 11:30:56 2019
InstallationDate: Installed on 2018-01-10 (385 days ago)
InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release amd64 (20170801)
MachineType: LENOVO 20J7S02N00
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-43-generic root=/dev/mapper/vgcrypt-lvcryptoroot ro quiet splash
SourcePackage: qemu
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 09/28/2017
dmi.bios.vendor: LENOVO
dmi.bios.version: R0FET37W (1.17 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20J7S02N00
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40697 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: dmi:bvnLENOVO:bvrR0FET37W(1.17):bd09/28/2017:svnLENOVO:pn20J7S02N00:pvrThinkPadT470p:rvnLENOVO:rn20J7S02N00:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad T470p
dmi.product.name: 20J7S02N00
dmi.product.version: ThinkPad T470p
dmi.sys.vendor: LENOVO
---
ApportVersion: 2.20.1-0ubuntu2.18
Architecture: amd64
CurrentDesktop: Unity
DistroRelease: Ubuntu 16.04
InstallationDate: Installed on 2018-01-10 (393 days ago)
InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release amd64 (20170801)
MachineType: LENOVO 20J7S02N00
Package: qemu 1:2.5+dfsg-5ubuntu10.34
PackageArchitecture: amd64
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-45-generic root=/dev/mapper/vgcrypt-lvcryptoroot ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 4.15.0-45.48~16.04.1-generic 4.15.18
Tags: xenial
Uname: Linux 4.15.0-45-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip libvirtd lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 09/28/2017
dmi.bios.vendor: LENOVO
dmi.bios.version: R0FET37W (1.17 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20J7S02N00
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40697 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: dmi:bvnLENOVO:bvrR0FET37W(1.17):bd09/28/2017:svnLENOVO:pn20J7S02N00:pvrThinkPadT470p:rvnLENOVO:rn20J7S02N00:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad T470p
dmi.product.name: 20J7S02N00
dmi.product.version: ThinkPad T470p
dmi.sys.vendor: LENOVO

[Christian Ehrhardt  (paelzer)]

Hi Eero,
when a device is passed to the guest then it is detached from the host before.
Once the passthrough is done it will be re-attached to the host.
If the device is - like in your case a USB drive - something that triggers actions in the host those will happen.

I assume what happens is:
- detaches from host
- tries to passthrough to the guest
- fails to passthrough
- re-attaches to the host
- nautilus popup triggered as if you'd plug in the USB drive

You can configure the host to not trigger such popups if that really is an issue.
But I have no idea why on a retry it would open multiple such windows thou.

The actual problem we need to solve IMHO is why the passthrough didn't work in the first place.
... reading your logs ...

[Christian Ehrhardt  (paelzer)]

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
   # ...

[Eero Aaltonen (ejn)]

I tried adding the five lines you posted on the bottom of /etc/apparmor.d/abstractions/libvirt-qemu

There are no more 'apparmor="DENIED"' entries. But the disk still bounced back. I see entries:

[ 673.188482] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 673.435419] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK

I also noticed that `sudo apparmor_parser -r /etc/apparmor.d/abstractions/libvirt-qemu` complains that

AppArmor parser error for /etc/apparmor.d/abstractions/libvirt-qemu in /etc/apparmor.d/abstractions/base at line 23: syntax error, unexpected TOK_MODE, expecting TOK_OPEN

, but it seems the rules took effect anyway.

[Christian Ehrhardt  (paelzer)]

Abstractions are not meant to be loaded directly - the "syntax error, unexpected TOK_MODE, expecting TOK_OPEN" is ok.

I don't know what the remaining issue that you see is thou - any further logs on that?

[Eero Aaltonen (ejn)]

apport information

[Eero Aaltonen (ejn)]

apport information

[Eero Aaltonen (ejn)]

apport information

[Eero Aaltonen (ejn)]

apport information

[Eero Aaltonen (ejn)]

apport information

[Eero Aaltonen (ejn)]

apport information

[Eero Aaltonen (ejn)]

apport information

[Eero Aaltonen (ejn)]

apport information

[Eero Aaltonen (ejn)]

apport information

[Eero Aaltonen (ejn)]

apport information

[Eero Aaltonen (ejn)]

apport information

[Eero Aaltonen (ejn)]

apport information

[Eero Aaltonen (ejn)]

Hooray! I discovered `apport-collect <bug_no>`, and it works!

[Christian Ehrhardt  (paelzer)]

Gz on apport-collect :-)

But I haven't found a good lead in the logs added.

Maybe if you enable libvirt debugging [1] we might get something to start thinking about?

[1]: https://wiki.libvirt.org/page/DebugLogs

[Eero Aaltonen (ejn)]

More details of the test I've been performing.

1) Start Windows guest
2) Plug USB-drive, nautilus mounts it.
3) Unmount partitions in Nautilus
4) Add USB Host device to running Windows guest

I don't have guest-tools or such installed yet. Are they required?

[Christian Ehrhardt  (paelzer)]

No guest tools required.

[Eero Aaltonen (ejn)]

More details of the test I've been performing.

1) Start Windows guest
2) Plug USB-drive, nautilus mounts it.
3) Unmount partitions in Nautilus
4) Add USB Host device to running Windows guest

I don't have guest-tools or such installed yet. Are they required?

[Eero Aaltonen (ejn)]

Here's debug logs for libvirtd.

The USB drive has two partitions (made by the manufacturer). The first one contains some Windows Setup.exe.

[Christian Ehrhardt  (paelzer)]

I see this error:
13644 2019-02-08 14:05:33.970+0000: 2993: error : virUSBDeviceFindByVendor:242 : internal error: Did not find USB device 59f:106e

But we know that the ids are ok from your lspci:
Bus 002 Device 002: ID 059f:106e LaCie, Ltd Porsche Design Desktop Drive

But I don't see apparmor denies anymore, so we seem to have fixed those.
Sorry you fulfill all that is usually needed to get the USB to be passed through and I don't see a good lead where to debug next :-/

What might be worth a try would be to upgrade libvirt/qemu.
If you want to stick to 16.04 as the base OS but try a newer virtualization stack you might consider the Ubuntu Cloud Archive packages from [1].

That would be:
  $ sudo add-apt-repository cloud-archive:queens
And then updating the packages.

[1]: https://wiki.ubuntu.com/OpenStack/CloudArchive#A16.04

[Eero Aaltonen (ejn)]

I upgraded to 18.04.02. Speed issue remains #1815588

[Christian Ehrhardt  (paelzer)]

Thanks for the extra bug, taking a look this afternoon

[Launchpad Janitor (janitor)]

[Expired for qemu (Ubuntu) because there has been no activity for 60 days.]

[Christian Ehrhardt  (paelzer)]

Seeing the expiring update now, needless to say I haven't found anything to debug/fix in my setups that I tried (as seen on our discussions on bug 1815588) :-/