Jump to: navigation, search

Difference between revisions of "Nova/USB device&USB controller"

(Technical verification)
(Proposed solution)
Line 54: Line 54:
 
     Case 1:
 
     Case 1:
 
     (1)Admin/User request to create a flavor with usb controllers(key arguments: type, count).
 
     (1)Admin/User request to create a flavor with usb controllers(key arguments: type, count).
     (2)System creates a flavor.
+
     (2)System creates a flavor containing usb controller information.
 
     (3)Admin/User request to create a vm with flavor created above.  
 
     (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.  
 
     (4)System first validates usb arguments specified in flavor, if valid then create a vm with usb controllers.  
Line 60: Line 60:
 
     Case 2:
 
     Case 2:
 
     (1)Admin/User request to create a flavor with usb devices(key arguments: unique identifiers of devices).
 
     (1)Admin/User request to create a flavor with usb devices(key arguments: unique identifiers of devices).
     (2)System creates a flavor.
+
     (2)System creates a flavor containing usb device information.
 
     (3)Admin/User request to create a vm with flavor created above.  
 
     (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 .  
 
     (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 .  
Line 66: Line 66:
 
     Case 3:     
 
     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).
 
     (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.
+
     (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.  
 
     (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, free port and so on), if valid then create a vm with usb devices and usb controllers in the host. The usb devices will be attached to the controllers by type.
+
     (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):
 
2. System requirements and things should be considered for usb controller(An optional Implementation):
 
     (1)System supports creating a flavor with usb controller.
 
     (1)System supports creating a flavor with usb controller.
         Add a property about usb controller to extra_specs field of flavor. The scheme may like {"usb_controllers":[{"type":"ehci", "count": 1}]}  
+
         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 create all type's controller but pii3-uhci.   
+
         '''Note:''' Because libvirt/qemu will create a default pii3-uhi controller, so system will only create usb controllers except pii3-uhci.   
  
     (2)System supports constructing usb controller xml in libvirt driver and config.
+
     (2)System supports creating vm with usb controller.
 +
        Driver(ibvirt) layper need to support constructing usb controller xml configuration.
  
     (3)System supports managing usb controller index/port<--->usb device's relationship so that we can attach usb device to unique usb controller and port.  
+
     (3)System supports managing relationship between usb controllers and usb devices and storing them in instance_system_metadata table, so that  
         The usb controller schema may like
+
      <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":
 
           "usb_controller_requests":
Line 101: Line 103:
 
           ]
 
           ]
 
         }
 
         }
 
    (4)System supports saving usb controller information in instance_system_metadata table so that the next starting of vm will create usb controllers.
 
  
 
3. System requirements and things should be considered for usb device(An optional Implementation):
 
3. System requirements and things should be considered for usb device(An optional Implementation):
     (1)System supports discovering of usb devices and saving them to DB.
+
     (1)System supports discovering usb devices and saving them to DB.
         The main process can refer to pci-passthrough:
+
         The main process can refer to pci-passthrough implements:
         <1>Using white-list and lsusb function to retrieve available usb devices of a host.
+
         <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 save usb devices information.
+
         <2>Adding a table usb_devices in DB to store usb device information.
         <3>Adding auto-update process to synchronize information between compute node and DB.  
+
         <3>Adding auto-update function to synchronize information between host(compute node) and DB.  
  
     (2)System supports creating vm with usb devices.
+
     (2)System supports creating a flavor with usb device.
         <1>Adding a property about usb device to extra_specs field of flavor. The scheme may like {"usb_devices":[{"node_id":"1", "dev_id": "usb_2_1"}]}
+
         Adding a property for usb device to extra_specs field of flavor. The scheme may like {"usb_devices":[{"node_id":"1", "dev_address": "usb_2_1"}]}
              '''Note:''' Because most user scenarios should be admin/user specify which usb device to which vm, so it's necessary to exposure physical information to admin/user. The mechanism of automatically finding compute node to provide pci devices is not comfortable here.
+
        '''Note:'''  
        <2>System schedulers request to appropriate compute node.
+
        It is necessary to exposure usb device physical information to admin/user because the most common scenarios are attaching specified usb device to vm.
              Add a UsbDeviceFilter.py filter for filtering compute node.
+
        The mechanism of automatically selecting compute node to provide pci devices is not appropriate in here.
        <3>System allocates usb controllers for usb devices.
 
              If not specifying usb controllers in request, libvirt/qemu will create a default uhci controller for using.
 
              If specifying usb controllers(type and count) in request, system will choose a matched controller and port for every usb device. If controllers are not matched or ports are not enough then system throws an error. If some controllers and ports are used then the structure usb_controller_requests described above will be updated.
 
  
     (3)System supports saving usb devices information in instance_system_metadata table so that the next starting of vm will automatically attach usb devices.
+
     (3)System supports creating vm with usb devices.
        The usb device schema may like
+
        <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.
          "usb_devices_requests":
+
        <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.
                "dev_address": "usb_2_1"
+
        <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":
 
+
                [
    (4)System supports attaching usb devices when starting a vm with usb devices.
+
                  {
        System will use usb_controller_requests to find relationship between usb devices and usb controller/ports and construct xml configuration.
+
                    "dev_address": "usb_2_1"
 +
                  }
 +
                ]
 +
              }
  
     (5)System supports detaching usb devices when suspending a vm with usb devices, and re-attaching usb devices when resuming the vm.
+
     (4)System supports detaching usb devices when suspending a vm with usb devices, and re-attaching usb devices when resuming the vm.
  
     (6)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.
+
     (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.
  
     (7)System supports reporting error when migrating vm with usb device.
+
     (6)System supports reporting error when migrating vm with usb device.
 
         If a vm has usb devices attached, it is not allowed to migrate.
 
         If a vm has usb devices attached, it is not allowed to migrate.

Revision as of 12:00, 4 March 2014

USB device and USB controller features

Related Content

https://wiki.openstack.org/wiki/Nova/USB_controller_hot_cold_plug

https://wiki.openstack.org/wiki/Nova/USB_device_hot_cold_plug

Background

Currently, nova has supported function of pci-passthrough, but hasn't supported usb-passthrough. I think usb-passthrough is also a important and necessary function especially in private cloud.

User scenarios

1. When a administrator wants to deploy a vm for running erp software which need usb-key for authentication, him may need to insert usb-key to a host(compute node) first and then run vm with usb-key in this host.

2. When a user wants to copy data from vm to a removable media for business trip him may need a usb data disk.

   ps:  The usb redirection technology over spice or vnc connection maybe more appropriate in thest scenarios.

Technical verification

1. Test case

    Creating vm with different type and number usb controller and usb device.

2. Xml definition

  (1)Sample of usb controller:
   <controller type='usb' index='2' model='piix3-uhci'/>
   <controller type='usb' index='1' model='ehci'/>
  (2)Sample of pass-through usb devices
   <hostdev mode='subsystem' type='usb'>
    < source>
     <vendor id='0x136b'/>
     <product id='0x0003'/>
     <address bus='2' device='2'/>
    </source>
    <address type='usb' bus='1' port='1'/>
   </hostdev>
  (3)Sample of emulated usb disks
     <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      < source file='/home/vms/usb/sdb.qcow2'/>
      <target dev='sdb' bus='usb'/>
      <address type='usb' bus='1' port='1'/>
    </disk>

3. The test results

  (1)Usb controllers have a maximum port restriction. Uhci controller supports a maxmum of 2 ports while ehci controller supports 6.
  (2)If creating vm without usb controller, qemu will default create a piix3-usb-uhci controller but not creating the other type's.
  (3)If creating vm with usb device but no usb controller, the usb device will default be attached to the default uhci controller, but speed may mismatch.
  (4)There are two ways to support more usb devices. 1. Adding cascaded hubs and attaching usb devices to them. 2.Creating more controllers and connect usb devices to different ones.
  (5)When creating vm with a pair of usb hub and ehci controller, the vm crashed. Qemu thrown a error(why?)

Proposed solution

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": "dev_address"
                     }
                   ]
                 } 
               ]
            }
          ]
        }

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":[{"node_id":"1", "dev_address": "usb_2_1"}]}
        Note: 
        It is necessary to exposure usb device physical 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":
                [
                  {
                    "dev_address": "usb_2_1"
                  }
               ]
             }
   (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.