Support passthrough of USB devices of host

Registered by Sam Stoelinga on 2013-04-23

Add support for usb passthrough http://wiki.libvirt.org/page/QEMUSwitchToLibvirt#-usbdevice_2

This feature may be specific for some private cloud use cases only. So an option to disable or disable it by default may be appropriate?

Example workflow in horizon:
1. User clicks on the action Attach USB device
     a. Nova executes lsusb and retuns list of available pci devices with names on the host of the instance
     b. Horizon shows the names of the usb devices such as Sandisk Cruzer
2. The user chooses to attach the Sandisk Cruzer to instance-x
     a. Nova get the bus and device number and use libvirt to attach the device using the libvirt api

I think there should be a new table called host_usb_devices which stores the name, bus, device, instance_uuid, state

Where state would also track the progress, possible states: attaching, attached, available, failed

Things that should be considered:
- What if the usb device gets unplugged rebooting the instance wont be possible because it cant find the attached device. So when rebooting we need to also check if there are any usb devices attached and if they still exist. Happened to me once was unable to boot the instance if the usb was removed but still attached to the instance.
- Live-migration or move to another host
- If the instance is powered off and / or suspended we need to use the following command: virsh detach-device instance-000000ca usb-device.xml --config because you can't detach from an inactive domain, maybe the python libvirt api has a flag for it
- Device can only be used by single instance
- What about other hypervisor support?

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
Sam Stoelinga
Definition:
Obsolete
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
Sam Stoelinga on 2014-04-02

Related branches

Sprints

Whiteboard

There is already patch about pci-passthrough https://review.openstack.org/#/c/27130/
And there is also more common bp https://blueprints.launchpad.net/nova/+spec/epa-for-pcie-devices -- boris-42

I tried using pci passthrough for usb devices although it was really unstable, I think it should be seperated from pci passthrough. When using usb passthrough you are able to depend on lsusb whereas with pci passthrough with lspci you can only see controllers but not the actual usb devices plugged into the host. So it's really hard to know which controller corresponds to which port on the physical host. -- Sam

Didn't try to use it for USB =), but however I think that it will be good to handle both situation with one approach (For example different actions at hypervisor level for different device classes) What do you think?
By the way I will publish today description of my approach, so I think that it will be great do discuss about what we should change to provide different devices.. -- boris-42

Yea I also think it's better to use one approach, I think the libvirt people also thought it would be better to use one approach, but they still provided it separated as usb passtrough (Probably because usb devices have a bus number and device number and everything you plug it in and out the device number changes). The main problem is that the result of the two approaches(pci passthrough, usb passthrough) is different. So I still think it should be separated for stability and usability of using host usb devices in guests. Happy to discuss this further though, good to know that there is already progress in it. (This is based on my limited experience with pci passthrough with usb and vga cards)

We could also handle both situations with a single approach just if it's a usb device we use usb passthrough in libvirt. And we kind of mix the results of lspci and lsusb for the user to choose from -- Sam

If you are still working on this, please re-submit via nova-specs. If not, please mark as obsolete, and add a quick comment to describe why. --johnthetubaguy (20th April 2014)

I'm not working on this anymore. --Sam

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.