Bug 508645 - RFE: qemu: Support a managed autoconnect mode for host USB devices
RFE: qemu: Support a managed autoconnect mode for host USB devices
Status: NEW
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Libvirt Maintainers
:
Depends On:
Blocks: libvirtTodoHV
  Show dependency treegraph
 
Reported: 2009-06-29 06:10 EDT by Mark McLoughlin
Modified: 2016-04-13 19:09 EDT (History)
21 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Mark McLoughlin 2009-06-29 06:10:17 EDT
Right now with USB passthrough, the device has to be plugged in before you start the guest and if you unplug the device while the guest is running, you need to re-start the guest if you plug the device back in. Clearly that sucks for USB.

However, qemu has had an autoconnect mode since 0.11, syntax is:

 * Autoconnect filter                                                           
 * Format:                                                                      
 *    auto:bus:dev[:vid:pid]                                                    
 *    auto:bus.dev[:vid:pid]                                                    
 *                                                                              
 *    bus  - bus number    (dec, * means any)                                   
 *    dev  - device number (dec, * means any)                                   
 *    vid  - vendor id     (hex, * means any)                                   
 *    pid  - product id    (hex, * means any)                    

so, e.g. running -usbdevice host:auto:*:*:0dda:0001 means that qemu will poll for the existence of a device with the supplied vendor/product ID and add it when it is plugged in.

Works great for me here, it probably make sense to use this mode by default.

One thing to check out is whether there is a race condition between qemu grabbing the device and e.g. nautilus auto-mounting it. In my testing, nautilus never sees the device.
Comment 1 Daniel Berrange 2009-06-29 06:26:30 EDT
We should deal with this in a similar way to PCI devices. eg, by toggling off the attribute  managed="yes|no". If 'yes' meaning that we let QEMU auto-connect/disconnect at will, and 'no' meaning its totally manual / static.
Comment 2 Paul Lambert 2009-07-15 19:24:23 EDT
Using Fedora 11 on an HP Pavilion dv7-1230us the Natilus auto-mounts and sees the USB drive.  I unmount USB the device and boot the Windows vm and it now sees the USB disk.  In running VMWare on Windows with a VM guest both systems detect a USB drive and notify the user there is new hardware.  Typically, the user has time to cancel one of the popup dialogs and check to not retry.  I have not experienced any race conditions.  But should be tested.

Is the virt-manager startup command something that resides in a text file where it can be manually edited?  I would like to manually edit this command to include the USB auto mount.
Comment 3 Daniel Berrange 2009-07-16 09:32:19 EDT
> so, e.g. running -usbdevice host:auto:*:*:0dda:0001 means that qemu will poll
> for the existence of a device with the supplied vendor/product ID and add it
> when it is plugged in.
>
> Works great for me here, it probably make sense to use this mode by default.

Unfortunately this isn't going to work for libvirt. This relies on QEMU being able to read/write to the USB device files. libvirt is about to switch to running QEMU VMs as a non-root user/group, so while QEMU will be able to see the new device arrive, it won't have any way to access it. Only libvirtd can give it permission to the device

This auto-connect is a valuable feature though, so I think we'll have to make libvirt monitor for USB devices, change file ownership to QEMU and use QEMU's monitor to then attach the device to the guest.
Comment 4 Daniel Berrange 2009-09-15 07:00:52 EDT
This is probably a candidate for moving to F13 target, since there's non-trivial code work required in libvirt still.
Comment 5 Guido Günther 2010-01-03 16:16:33 EST
(In reply to comment #3)
> This auto-connect is a valuable feature though, so I think we'll have to make
> libvirt monitor for USB devices, change file ownership to QEMU and use QEMU's
> monitor to then attach the device to the guest.  

Can't we handle this without monitoring the USB devices by using udev? We'd either generate

/etc/udev/rules.d/70-libvirt.rules

SUBSYSTEM!="usb|usb_device", GOTO="libvirt_rules_end"
ACTION!="add", GOTO="libvirt_rules_end"

ATTRS{idVendor}=="0553", ATTRS{idProduct}=="0202", MODE="0600", OWNER="qemu"
ATTRS{idVendor}=="0553", ATTRS{idProduct}=="0202", MODE="0600", OWNER="qemu"
...
LABEL="libvirt_rules_end"

from within libvirtd in case of managed=yes.

Alternatively we could use a callout (RUN+=libvirt_perms) for all USB devices which would look at the domain XMLs to check if we need to  set permissions. This would have the advantage that we wouldn't have to modify the rules file all the time it would slow down things for all USB devices. So generating the rules file from libvirtd is probably better.

Having this fixed would also help with 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563502
since the wrapper script could be dropped.
Comment 6 Daniel Berrange 2010-01-04 05:57:05 EST
No, we ned to managed this directly in libvirt, because we can't presume static 'qemu:qemu' ownership for all guests - it is likelt that in the future every guest will get a unique UID/GID pair. In addition we already have to assign unique SELinux labels for all devices.
Comment 7 Guido Günther 2010-01-13 17:14:39 EST
So the aim is to chown/chmod/relabel the device just before vm launch?
Comment 8 Guido Günther 2010-01-13 17:50:08 EST
Forget about comment c7. 

Using something like 

ATTRS{idVendor}=="0553", ATTRS{idProduct}=="0202", MODE="0600", OWNER="qemuXY" RUN+=libvirt_selinux_helper 

woule be race free while with changing in libvirtd we'd race with kvm for the device. We can use different owners for different VMs.
Comment 9 Daniel Berrange 2010-01-14 04:49:42 EST
I really don't want to get into the realm of delegating setup code to udev scripts. This approach was used in XenD and was an unmitigated disaster, because it makes it incredibly hard to keep synchronization between things run in libvirtd/xend and the udev scripts. NB cole has now posted scripts that take care of device labelling / permissions at guest startup. THe only missing piece now is to auto-detect USB devices arriving while the guest is running & hotplug them. IMHO, libvirtd should directly listen for & process the relevant udev events, rather than doing it externally in a script.
Comment 10 Marek Šabo 2011-04-25 06:04:32 EDT
Hi,

I see there has been no activity in this report for over a year, I just want to ask what's the current status regarding usb automounting.

Thanks for both answer and libvirt,

Regards,

Marek
Comment 11 Frederic Grelot 2012-01-22 07:29:46 EST
Hi all, 

I second Marek's question (posted... hmm, 8 months ago...) : I see that there has been no activity on this bug for a pretty long time (2 years + 8 days actually), and I'd like to know if anything happened in any way.
The article here http://david.wragg.org/blog/2009/03/usb-pass-through-with-libvirt-and-kvm.html gives some solution, but it's not straighforward (and I don't want to use a wrapper script...).
In my case, this bug is critical : I use a virtual machine to share some devices (USB printers, scanners...) to several clients, and the devices are very keen on crashing (especially the scanners, due to poor drivers...). Unfortunately, the only solution then is to unplug/replug the devices, but I'm then forced to manually shutdown/restart the vm : this is very annoying (for all the other users especially!).

Thanks for your help.

Frederic.
Comment 12 Brian Martin 2012-11-28 16:39:56 EST
Adding myself to the CC list.  I am also interested in seeing a solution to the need to start VMs without all of their USB devices, and to be able to add and remove USB devices dynamically.
Comment 13 Satadru Pramanik 2013-10-05 11:46:41 EDT
Any updates on this?  Suspending a VM that has had a usb device disconnected also doesn't allow the VM to be restored again, which seems to be dependent on getting this issue resolved.
Comment 14 Cole Robinson 2013-10-05 12:38:26 EDT
Nothing to report yet, I don't think anyone is paying attention to this really.

Another libvirt option would be to add an XML element like 'startupPolicy' like we have for disks, so we could say startupPolicy=optional and the guest will boot fine if the USB device isn't available. If someone wanted to provide a patch, they could look at how that's implemented in libvirt and try to follow the same pattern for USB devices. At least sending some half working patch may encourage a libvirt dev to help out.

There's also spice USB redirection which is much more fault tolerant, but doesn't provide any way to say 'always attach this device to the guest'. Some docs here:

http://hansdegoede.livejournal.com/11084.html

But the UI way with virt-manager is:

- Guest needs spice
- Guest needs spicevmc channel
- Guest needs USB2 controller
- Attach 4 usbredir devices to the VM
- Restart the VM and attach to it with virt-viewer
- There's a USB redirection menu option

upstream virt-manager has usb redirection support but it hasn't been released yet.
Comment 15 Cole Robinson 2016-04-13 19:09:41 EDT
Still relevant. Maybe if we get nodedev event APIs soon we can use them internally to implement this.

Note You need to log in before you can comment on or make changes to this bug.