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.
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.
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.
> 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.
This is probably a candidate for moving to F13 target, since there's non-trivial code work required in libvirt still.
(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.
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.
So the aim is to chown/chmod/relabel the device just before vm launch?
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.
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.
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
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.
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.
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.
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.
Still relevant. Maybe if we get nodedev event APIs soon we can use them internally to implement this.
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.