|
|
| Line 44: |
Line 44: |
| | (2)There are restrictions for number of suported usb devices(Maybe it is not a problem because normal business scenes don' t need many usb devices) | | (2)There are restrictions for number of suported usb devices(Maybe it is not a problem because normal business scenes don' t need many usb devices) |
| | | | |
| − | === Proposed solution === | + | === Consideration about usb-passthrough and hot-plug === |
| − | 1. Use cases
| |
| − | Case 1:
| |
| − | (1)Admin/User request to create a flavor with usb controllers(key arguments: type, count).
| |
| − | (2)System creates a flavor containing usb controller information.
| |
| − | (3)Admin/User request to create a vm with flavor created above.
| |
| − | (4)System first validates usb arguments specified in flavor, if valid then create a vm with usb controllers.
| |
| − | | |
| − | Case 2:
| |
| − | (1)Admin/User request to create a flavor with usb devices(key arguments: unique identifiers of devices).
| |
| − | (2)System creates a flavor containing usb device information.
| |
| − | (3)Admin/User request to create a vm with flavor created above.
| |
| − | (4)System first validates if usb devices are exist, available, and in the same host, if valid then create a vm with usb devices in the host. The usb devices will be attached to the default uhci controller created by qemu .
| |
| − | | |
| − | Case 3:
| |
| − | (1)Admin/User request to create a flavor with usb controllers(key argument: type, count) and usb devices(key arguments: identifiers and usb controller type).
| |
| − | (2)System creates a flavor containing usb device information and usb controller information.
| |
| − | (3)Admin/User request to create a vm with flavor created above.
| |
| − | (4)Admin/User first validate if usb devices are exist, available,in the same host, and matching with controllers(type, have available port and so on), if valid then create a vm with usb devices and usb controllers in the host.
| |
| − | | |
| − | 2. System requirements and things should be considered for usb controller(An optional Implementation):
| |
| − | (1)System supports creating a flavor with usb controller.
| |
| − | Adding a property for usb controller to extra_specs field of flavor. The scheme may like {"usb_controllers":[{"type":"ehci", "count": 1}]}
| |
| − | '''Note:''' Because libvirt/qemu will create a default pii3-uhi controller, so system will only create usb controllers except pii3-uhci.
| |
| − | | |
| − | (2)System supports creating vm with usb controller.
| |
| − | Driver(ibvirt) layper need to support constructing usb controller xml configuration.
| |
| − | | |
| − | (3)System supports managing relationship between usb controllers and usb devices and storing them in instance_system_metadata table, so that
| |
| − | <1>every usb device will have unique port, <2>vm can create usb controller and attach usb devices correctly the next starting.
| |
| − | The usb controller schema may like:
| |
| − | {
| |
| − | "usb_controller_requests":
| |
| − | [
| |
| − | {
| |
| − | "type": "ehci",
| |
| − | "count": 2,
| |
| − | "usb_controllers":
| |
| − | [
| |
| − | {
| |
| − | "index": 1,
| |
| − | "ports":
| |
| − | [
| |
| − | {
| |
| − | "port": 1,
| |
| − | "usb_device_id": 5
| |
| − | }
| |
| − | ]
| |
| − | }
| |
| − | ]
| |
| − | }
| |
| − | ]
| |
| − | }
| |
| − | | |
| − | 3. System requirements and things should be considered for usb device(An optional Implementation):
| |
| − | (1)System supports discovering usb devices and saving them to DB.
| |
| − | The main process can refer to pci-passthrough implements:
| |
| − | <1>Using white-list function and lsusb like commands to retrieve available usb devices of a host.
| |
| − | <2>Adding a table usb_devices in DB to store usb device information.
| |
| − | <3>Adding auto-update function to synchronize information between host(compute node) and DB.
| |
| − | | |
| − | (2)System supports creating a flavor with usb device.
| |
| − | Adding a property for usb device to extra_specs field of flavor. The scheme may like {"usb_devices":[{"usb_device_id": 5}]}
| |
| − | '''Note:'''
| |
| − | It is necessary to exposure usb device id(maybe some other information also are necessary) information to admin/user because the most common scenarios are attaching specified usb device to vm.
| |
| − | The mechanism of automatically selecting compute node to provide pci devices is not appropriate in here.
| |
| − | | |
| − | (3)System supports creating vm with usb devices.
| |
| − | <1>Scheduler layer needs to scheduler request to the appropriate compute node, so a UsbDeviceFilter.py filter may be needed.
| |
| − | <2>Driver(ibvirt) layper supports constructing usb device xml configuration.
| |
| − | <3>Compute layer supports allocating usb controller for usb device.
| |
| − | If not specifying usb controllers in request, compute layer not specify usb controller for usb device, then libvirt/qemu will attach usb device to the default pii3-uhci controller.
| |
| − | If specifying usb controllers in request, system will first create usb controller which processes have been described above. It then choose available controller(type and port) for usb device.
| |
| − | <4>DB layper supports storing usb devices. The instance_system_metadata table is a good choice.
| |
| − | The usb device schema may like
| |
| − | {
| |
| − | "usb_devices_requests":
| |
| − | [
| |
| − | {
| |
| − | "usb_device_id": 5
| |
| − | }
| |
| − | ]
| |
| − | }
| |
| − | | |
| − | (4)System supports detaching usb devices when suspending a vm with usb devices, and re-attaching usb devices when resuming the vm.
| |
| − | | |
| − | (5)System supports detaching usb devices before making snapshot of a vm and re-attaching usb devices after making snapshot. System also support the protection of usb device when using snapshot to resume a vm.
| |
| − | | |
| − | (6)System supports reporting error when migrating vm with usb device.
| |
| − | If a vm has usb devices attached, it is not allowed to migrate.
| |
As I know, some telecom and enterprise customers have desired for usb-passthrough especially in private cloud.
So I think maybe it's a good choice to provide this function in openstack.
1. There are some erp softwares deployed in virtual machines that need usb-key for authentication. Customers will first insert usb-key to host, then use the cloud management software to attach usb-key to vm, the last guest os will discovery usb-key and we can use it.
2. Popular usb device are supporting usb 2.0 or usb 3.0 standard, so our cloud management software should guarantee the transfer speed of usb device.
I have three alternatives about how to provide this function:
Option 1:
Nova supports function and related API to admin/user for creating specified type and number usb controller.
When admin/user attach a usb device to virtual machine, him should specify the type of usb controller, then nova will select a matched usb controller/port for this device.
Advantage:
(1)Admin/user can controll what they want. If usb controllers are not enough then admin/user can create new.
(2)Maybe it is more in line with the principle of system expansion.
Shortcoming:
(1)The user operations are complex.
(2)System should manage complex relationship between usb controller and usb device, and making decisions about which usb controller/port to which usb device.
Option 2:
Nova not exposure usb controller operating to admin/user.
When admin/user attach a usb device to virtual machine, him can specify the type of usb controller optionaly, then nova will automatically create appropriate usb controller/port for this device.
Advantage:
(1)The user operations are more simple.
Shortcoming:
(1)System should manage complex relationship between usb controller and usb device, and making decisions about which usb controller/port to which usb device.
Option 3:
Nova creates some default usb controller like ehci, nec-xhci when creating virtual machine.
When admin/user attach a usb device to virtual machine, him can specify the type of usb controller optionaly, then nova will select a matched usb controller/port for this device.
Advantage:
(1)The user operations are more simple.
Shortcoming:
(1)Not all type of usb controller can be supported
(2)There are restrictions for number of suported usb devices(Maybe it is not a problem because normal business scenes don' t need many usb devices)
