XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    USB passthrough test reports in 7.5RC1

    Scheduled Pinned Locked Moved Development
    58 Posts 21 Posters 39.6k Views 10 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • stormiS Offline
      stormi Vates 🪐 XCP-ng Team
      last edited by

      Thanks for the feedback and interesting findings. I have really little knowledge about all this, so I can't answer your questions. Maybe @r1 will have partial answers. Else this is an area where, at short term, I hope that the community, step by step, gets closer to a solution that we could implement.

      1 Reply Last reply Reply Quote 0
      • S Offline
        ScottyXCPNG
        last edited by

        Hi,

        Thanks for the reply @stormi

        I've kind of hit a roadblock in my own probing so far. I was trying to figure out how the VUSB parameters got passed into qemu. The daemon.log shows it's run by forkexecd, but comparing the command of the same vm run with and without VUSB shows no real differences, so there must be a configuration file or other metadata being passed in with the VUSB passthrough configuration. I tried poking at the xenapi and quickly got lost in the ocaml code which I can't really read.

        I've also found that a VM with a VUSB attached cannot be snapshotted and backed up, which is really unfortunate. I'm not entirely sure why that restriction exists. Surely if the VM is rolled back to the snapshot then the system can treat it the same as if the USB device vanishes? It seems that the system removes the VUSB attachment if the device vanishes so I would have thought the same could be done from snapshots or backups?

        Thanks,

        Gary

        1 Reply Last reply Reply Quote 0
        • S Offline
          ScottyXCPNG
          last edited by

          Update: I haven't been able to figure out how to tell qemu to use a USB1.x interface instead of USB2.x (EHCI) which would let me pass the device through, but I've found a different work around. The device I'm trying to pass through appears as a USB serial device. After I stumbled upon a page mentioning that you could tie an emulated serial port to a TCP socket I dug further and found that you can do

          xe vm-param-add uuid=<uuid> param-name=platform hvm_serial=/dev/ttyACM0
          

          and hey presto your /dev/ttyS0 in the guest is now tied to the device on the hypervisor

          I may still poke around and try and find a better solution but for now my needs appear to be satisfied.

          A 1 Reply Last reply Reply Quote 2
          • S Offline
            ScottyXCPNG
            last edited by

            Bonus: I just tried and snapshot/backup still works with the serial port tied in that way

            1 Reply Last reply Reply Quote 0
            • olivierlambertO Offline
              olivierlambert Vates 🪐 Co-Founder CEO
              last edited by olivierlambert

              Nice workaround indeed!! Well done and thanks a lot for reporting your progress, that's essential for the whole community 🙂

              edit: start a chat with me, I'd like to send you some goodies 😉

              1 Reply Last reply Reply Quote 0
              • A Offline
                axiom00 @ScottyXCPNG
                last edited by

                @ScottyXCPNG Do you mind sharing details on how you attached your Conbee 2 stick? My setup is a vm Ubuntu running deconz in docker. deconz "see" the stick as a raspbee gateway and the channel is set to 0. Hence I cannot pair anything. Clicking on the channel set button doesn't do anything. deconz log show invalid current channel 0 (todo) repeatedly.

                S 1 Reply Last reply Reply Quote 0
                • S Offline
                  ScottyXCPNG @axiom00
                  last edited by

                  @axiom00 yes, once I dug further I had the same issues. I don't have anything to pair with my stick yet, I was trying to get it working before splashing out on zigbee devices. I'm not sure why it's having issues. If you look at the Conbee serial protocol it's all done via binary commands sent over 38400 baud serial, so it should work OK. I also had an issue where my stick disconnected/reconnected after about an hour and came up with a different path in /dev so it didn't attach any more. I suspect this was because qemu was holding the original device open.

                  To remove the device from the vm again do

                  xe vm-param-remove vm-param-add uuid=<uuid> param-name=platform param-key=hvm_serial
                  

                  else it won't start if the serial device isn't present.

                  1 Reply Last reply Reply Quote 0
                  • S Offline
                    ScottyXCPNG
                    last edited by

                    Further update: I've found the USB device is added to qemu after the vm has started through hot plugging. It seems this is done in xenopsd. It even has explicit code to support USB v1 devices in there

                    According to xenopsd sources from 0.101.0 from the XCP-NG 8.0 SRPM, the code is

                    let vusb_plug ~xs ~privileged ~domid ~id ~hostbus ~hostport ~version =
                      debug "vusb_plug: plug VUSB device %s" id;
                      let get_bus v =
                        if String.startswith "1" v then
                          "usb-bus.0"
                        else begin
                          (* Here plug usb controller according to the usb version*)
                          let usb_controller_driver = "usb-ehci" in
                          let driver_id = "ehci" in
                          vusb_controller_plug ~xs ~domid ~driver:usb_controller_driver ~driver_id;
                          Printf.sprintf "%s.0" driver_id;
                        end
                      in
                      if Qemu.is_running ~xs domid then
                        begin
                          (* Need to reset USB device before passthrough to vm according to CP-24616.
                             Also need to do deprivileged work in usb_reset script if QEMU is deprivileged.
                          *)
                          begin match Qemu.pid ~xs domid with
                            | Some pid -> usb_reset_attach ~hostbus ~hostport ~domid ~pid ~privileged
                            | _ -> raise (Xenopsd_error (Internal_error (Printf.sprintf "qemu pid does not exist for vm %d" domid)))
                          end;
                          let cmd = Qmp.(Device_add Device.(
                                         { driver = "usb-host";
                                           device = USB {
                                             USB.id = id;
                                             params = Some USB.({bus = get_bus version; hostbus; hostport})
                                           }
                                         }
                                      ))
                          in qmp_send_cmd domid cmd |> ignore
                        end
                    

                    unfortunately I cannot find where the mysterious "version" parameter is that needs to be set to "1" to enable the use of USB bus 0 in the guest, which is USB 1. I'm wondering if it's stupidly reading the version string of the USB device itself rather than something else

                    I note that the latest code in the upstream xapi-project/xenopsd device.ml line 1818 is radically different and now has a "speed" parameter. This was added in commit ab15e6c3b1b06b2eac4f2a8be724eac50c9d4b22 in Oct 2019 for CA-328130 (whatever that is). It looks like code was also added to the upstream xapi-project/xenapi to add the "speed" parameter to the data model there. So there may be a fix in a future version of XCP-NG if they pull in these fixes. I haven't looked at 8.1-beta but I suspect it's too late to go making wholesale changes there if the code hasn't already been merged.

                    ok, just downloaded the SRPM from 8.1 xenopsd and it still has the old code for vusb plug, so I'm guessing 8.1 doesn't have this fixed (yet)

                    1 Reply Last reply Reply Quote 0
                    • olivierlambertO Offline
                      olivierlambert Vates 🪐 Co-Founder CEO
                      last edited by

                      Can you create an issue asking for this detailed change to be made? We can create a test package with this change, so it won't impact other users 🙂

                      S 1 Reply Last reply Reply Quote 0
                      • S Offline
                        ScottyXCPNG @olivierlambert
                        last edited by

                        @olivierlambert created https://github.com/xcp-ng/xcp/issues/342 under xcp project. Thanks!

                        ScottyGuy created this issue in xcp-ng/xcp

                        closed Please create test packages to help with USB support (related to CA-328130 ) #342

                        1 Reply Last reply Reply Quote 1
                        • olivierlambertO Offline
                          olivierlambert Vates 🪐 Co-Founder CEO
                          last edited by

                          Thank you, perfect 🙂

                          1 Reply Last reply Reply Quote 0
                          • S Offline
                            ScottyXCPNG
                            last edited by ScottyXCPNG

                            OK, this is rather amusing. I've got USB passthrough working for my USB 1.0 device.

                            [15:28 xcp-ng-bywirlgr log]# diff -u /opt/xensource/libexec/usb_scan.py.orig /opt/xensource/libexec/usb_scan.py
                            --- /opt/xensource/libexec/usb_scan.py.orig     2019-11-04 10:03:02.000000000 +0000
                            +++ /opt/xensource/libexec/usb_scan.py  2020-03-01 15:20:53.323512746 +0000
                            @@ -590,7 +590,8 @@
                             
                                 pusb["path"] = device.get_node()
                                 # strip the leading space of "version"
                            -    pusb["version"] = device[UsbDevice._VERSION].strip()
                            +    #pusb["version"] = device[UsbDevice._VERSION].strip()
                            +    pusb["version"] = "1.00"
                                 pusb["vendor-id"] = device[UsbDevice._ID_VENDOR]
                                 pusb["product-id"] = device[UsbDevice._ID_PRODUCT]
                                 pusb["vendor-desc"] = device[UsbDevice._DESC_VENDOR]
                            

                            I do NOT recommend this AT ALL. It is a gross hack. Apparently the xenopsd relies on the version number returned by the device to dictate the USB bus type of the controller it attaches to. I have no idea in what universe that makes sense.

                            The above only works for me as that is the only USB device attached to the HV. I guess I could make the code a little smarter by looking for a particular device ID and only over-riding the version then

                            S 1 Reply Last reply Reply Quote 0
                            • S Offline
                              ScottyXCPNG @ScottyXCPNG
                              last edited by ScottyXCPNG

                              A slightly less hacky work around for USB v1 passthrough based on the issue I created:

                              --- /opt/xensource/libexec/usb_scan.py     2019-11-04 10:03:02.000000000 +0000
                              +++ /tmp/usb_scan.py    2020-03-01 17:32:29.266317478 +0000
                              @@ -152,10 +152,11 @@
                                   _CLASS = "bDeviceClass"
                                   _CONF_VALUE = "bConfigurationValue"
                                   _NUM_INTERFACES = "bNumInterfaces"
                              +    _USB_SPEED = "speed"
                               
                                   _PRODUCT_DESC = [_DESC_VENDOR, _DESC_PRODUCT]
                                   _PRODUCT_DETAILS = [_VERSION, _ID_VENDOR, _ID_PRODUCT, _BCD_DEVICE, _SERIAL,
                              -                        _CLASS, _CONF_VALUE, _NUM_INTERFACES]
                              +                        _CLASS, _CONF_VALUE, _NUM_INTERFACES, _USB_SPEED]
                                   _PROPS = _PRODUCT_DESC + _PRODUCT_DETAILS
                                   _PROPS_NONABLE = _PRODUCT_DESC + [_SERIAL]
                               
                              @@ -590,7 +591,10 @@
                               
                                   pusb["path"] = device.get_node()
                                   # strip the leading space of "version"
                              -    pusb["version"] = device[UsbDevice._VERSION].strip()
                              +    if int(device[UsbDevice._USB_SPEED]) <= 12:
                              +        pusb["version"] = "1.00"
                              +    else:
                              +        pusb["version"] = device[UsbDevice._VERSION].strip()
                                   pusb["vendor-id"] = device[UsbDevice._ID_VENDOR]
                                   pusb["product-id"] = device[UsbDevice._ID_PRODUCT]
                                   pusb["vendor-desc"] = device[UsbDevice._DESC_VENDOR]
                              

                              in theory any deice which is "low" or "full" speed (i.e. USB1) will have it's version number changed to 1.00 which forces xenopsd to use a USB1 bus. It may have side effects if the driver in the guest relies on the version number so caveat emptor.

                              1 Reply Last reply Reply Quote 1
                              • A Offline
                                andreborges
                                last edited by

                                Good Morning!
                                I'm new to xcp-ng, we have two Hyper-V hosts but we needed to add a usb token to a vm, so we decided to migrate a host to xcp-ng for testing, but my host is not giving me the option passthrough usb, my server is a dell T110 II, I have already checked the bios settings and apparently everything is fine.
                                I don't know what I could be doing wrong.
                                I'm using version 8.1 of xcp-ng and xcp-ng center 20.04.
                                I'm sorry if I posted the wrong call!

                                XenCenterMain_Tp1dcckyVk.png

                                1 Reply Last reply Reply Quote 0
                                • stormiS Offline
                                  stormi Vates 🪐 XCP-ng Team
                                  last edited by

                                  Hi. Does https://xcp-ng.org/docs/compute.html#usb-passthrough help in your situation?

                                  A A 2 Replies Last reply Reply Quote 0
                                  • A Offline
                                    andreborges @stormi
                                    last edited by andreborges

                                    @stormi
                                    Good Morning!
                                    When executing the command xe pusb-list I have no return.

                                    totermw_rhkrRFJh3F.png

                                    1 Reply Last reply Reply Quote 0
                                    • A Offline
                                      anthr76 @stormi
                                      last edited by

                                      @stormi Not at all sadly. The Device never passes though..

                                      1 Reply Last reply Reply Quote 0
                                      • G Offline
                                        groentjuh
                                        last edited by groentjuh

                                        Let's give it another try to give my host its USB controller back and pass-through just the USB devices. In this case we're going for a virtual machine hosting common USB devices for home domotica.

                                        The devices we want to pass-through:

                                        • Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
                                          Which apparently is technical speak for a RFXtrx433XL USB 433.92MHz Transceiver
                                        • Prolific Technology, Inc. PL2303 Serial Port
                                          Which apparently is technical speak for a ZiGate USB-TTL
                                        • Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB

                                        I'm using XCP-ng Center 20.04.00 to help me out and XCP-NG 8.1 on the host.

                                        Let's start with a good old:

                                        [12:56 vmhost ~]# xe pusb-list host-uuid=*****
                                        uuid ( RO)            : 2ba8de5b-8fe1-0262-f741-35b4ed350ae0
                                                    path ( RO): 1-2
                                               vendor-id ( RO): 067b
                                             vendor-desc ( RO): Prolific Technology, Inc.
                                              product-id ( RO): 2303
                                            product-desc ( RO): PL2303 Serial Port
                                                  serial ( RO):
                                                 version ( RO): 1.10
                                             description ( RO): Prolific Technology, Inc._PL2303 Serial Port
                                        
                                        
                                        uuid ( RO)            : 08b23122-e01b-9ab2-e72d-185648ae19d7
                                                    path ( RO): 1-7
                                               vendor-id ( RO): 0403
                                             vendor-desc ( RO): Future Technology Devices International, Ltd
                                              product-id ( RO): 6015
                                            product-desc ( RO): Bridge(I2C/SPI/UART/FIFO)
                                                  serial ( RO): *******
                                                 version ( RO): 2.00
                                             description ( RO): Future Technology Devices International, Ltd_Bridge(I2C/SPI/UART/FIFO)_DO2VQGDG
                                        

                                        Ok, we have 2 devices already ready to be passthrough. Let's try to make the third one show up!
                                        Using the follow commands and some reading I could identify the DENY rules in "/etc/xensource/usb-policy.conf", which prevent my Aeotec Z-Stick from showing.

                                        [13:06 vmhost ~]# /opt/xensource/libexec/usb_scan.py -d
                                        [13:06 vmhost ~]# cat /var/log/user.log | less
                                        

                                        I've adjusted my "/etc/xensource/usb-policy.conf" to the following:

                                        # When you change this file, run 'xe pusb-scan' to confirm
                                        # the file can be parsed correctly.
                                        #
                                        # Syntax is an ordered list of case insensitive rules where # is line comment
                                        #  and each rule is (ALLOW | DENY) : ( match )*
                                        #  and each match is (class|subclass|prot|vid|pid|rel) = hex-number
                                        # Maximum hex value for class/subclass/prot is FF, and for vid/pid/rel is FFFF
                                        #
                                        # USB Hubs (class 09) are always denied, independently of the rules in this file
                                        DENY: vid=17e9 # All DisplayLink USB displays
                                        ALLOW:vid=0658 pid=0200 class=02 # Aeotec Z-Stick Gen5 (ZW090) - UZB
                                        DENY: class=02 # Communications and CDC-Control
                                        ALLOW:vid=056a pid=0315 class=03 # Wacom Intuos tablet
                                        ALLOW:vid=056a pid=0314 class=03 # Wacom Intuos tablet
                                        ALLOW:vid=056a pid=00fb class=03 # Wacom DTU tablet
                                        DENY: class=03 subclass=01 prot=01 # HID Boot keyboards
                                        DENY: class=03 subclass=01 prot=02 # HID Boot mice
                                        ALLOW:vid=0658 pid=0200 class=0a # Aeotec Z-Stick Gen5 (ZW090) - UZB
                                        DENY: class=0a # CDC-Data
                                        DENY: class=0b # Smartcard
                                        DENY: class=e0 # Wireless controller
                                        DENY: class=ef subclass=04 # Miscellaneous network devices
                                        ALLOW: # Otherwise allow everything else
                                        

                                        but also tried:

                                        # When you change this file, run 'xe pusb-scan' to confirm
                                        # the file can be parsed correctly.
                                        #
                                        # Syntax is an ordered list of case insensitive rules where # is line comment
                                        #  and each rule is (ALLOW | DENY) : ( match )*
                                        #  and each match is (class|subclass|prot|vid|pid|rel) = hex-number
                                        # Maximum hex value for class/subclass/prot is FF, and for vid/pid/rel is FFFF
                                        #
                                        # USB Hubs (class 09) are always denied, independently of the rules in this file
                                        DENY: vid=17e9 # All DisplayLink USB displays
                                        ALLOW:vid=0658 pid=0200 # Aeotec Z-Stick Gen5 (ZW090) - UZB
                                        ALLOW: class=02 # Communications and CDC-Control
                                        ALLOW:vid=056a pid=0315 class=03 # Wacom Intuos tablet
                                        ALLOW:vid=056a pid=0314 class=03 # Wacom Intuos tablet
                                        ALLOW:vid=056a pid=00fb class=03 # Wacom DTU tablet
                                        DENY: class=03 subclass=01 prot=01 # HID Boot keyboards
                                        DENY: class=03 subclass=01 prot=02 # HID Boot mice
                                        ALLOW: class=0a # CDC-Data
                                        DENY: class=0b # Smartcard
                                        DENY: class=e0 # Wireless controller
                                        DENY: class=ef subclass=04 # Miscellaneous network devices
                                        ALLOW: # Otherwise allow everything else
                                        

                                        After some playing around we got:

                                        [13:14 vmhost ~]# xe pusb-scan host-uuid=*****
                                        [13:15 vmhost ~]# xe pusb-list host-uuid=*****
                                        uuid ( RO)            : 0f7d6f12-6c4e-4f71-0c81-f7a7503a75f1
                                                    path ( RO): 1-8
                                               vendor-id ( RO): 0658
                                             vendor-desc ( RO): Sigma Designs, Inc.
                                              product-id ( RO): 0200
                                            product-desc ( RO): Aeotec Z-Stick Gen5 (ZW090) - UZB
                                                  serial ( RO):
                                                 version ( RO): 2.00
                                             description ( RO): Sigma Designs, Inc._Aeotec Z-Stick Gen5 (ZW090) - UZB
                                        
                                        
                                        uuid ( RO)            : 2ba8de5b-8fe1-0262-f741-35b4ed350ae0
                                                    path ( RO): 1-2
                                               vendor-id ( RO): 067b
                                             vendor-desc ( RO): Prolific Technology, Inc.
                                              product-id ( RO): 2303
                                            product-desc ( RO): PL2303 Serial Port
                                                  serial ( RO):
                                                 version ( RO): 1.10
                                             description ( RO): Prolific Technology, Inc._PL2303 Serial Port
                                        
                                        
                                        uuid ( RO)            : 08b23122-e01b-9ab2-e72d-185648ae19d7
                                                    path ( RO): 1-7
                                               vendor-id ( RO): 0403
                                             vendor-desc ( RO): Future Technology Devices International, Ltd
                                              product-id ( RO): 6015
                                            product-desc ( RO): Bridge(I2C/SPI/UART/FIFO)
                                                  serial ( RO): *****
                                                 version ( RO): 2.00
                                             description ( RO): Future Technology Devices International, Ltd_Bridge(I2C/SPI/UART/FIFO)_DO2VQGDG
                                        

                                        Well we're ready for some pass-through, right?

                                        Using XCP-ng Center we can see these 3 devices and "Enable pass-through" for all of these 3 devices. After shutting down the VM, using properties we can attach all 3 USB-devices and start the VM again, but not before running the following command as was recommended:

                                        xe vm-param-set uuid=**** platform:device-model=qemu-upstream-compat
                                        

                                        Let's start and monitor dmesg:

                                        [  742.309309] block tda: sector-size: 512/512 capacity: 20971520
                                        [  742.727012] device vif6.0 entered promiscuous mode
                                        [  742.961272] device tap6.0 entered promiscuous mode
                                        [  743.068536] usb 1-8: reset full-speed USB device number 4 using xhci_hcd
                                        [  743.217985] cdc_acm 1-8:1.0: ttyACM0: USB ACM device
                                        [  743.376482] usb 1-8: reset full-speed USB device number 4 using xhci_hcd
                                        [  743.525903] cdc_acm 1-8:1.0: ttyACM0: USB ACM device
                                        [  743.571126] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
                                        [  743.571136] ftdi_sio 1-7:1.0: device disconnected
                                        [  743.700284] usb 1-7: reset full-speed USB device number 3 using xhci_hcd
                                        [  743.851993] ftdi_sio 1-7:1.0: FTDI USB Serial Device converter detected
                                        [  743.852018] usb 1-7: Detected FT-X
                                        [  743.852171] usb 1-7: FTDI USB Serial Device converter now attached to ttyUSB0
                                        [  743.984286] usb 1-8: reset full-speed USB device number 4 using xhci_hcd
                                        [  744.137611] cdc_acm 1-8:1.0: ttyACM0: USB ACM device
                                        [  744.138491] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
                                        [  744.138500] ftdi_sio 1-7:1.0: device disconnected
                                        [  744.268258] usb 1-7: reset full-speed USB device number 3 using xhci_hcd
                                        [  744.420007] ftdi_sio 1-7:1.0: FTDI USB Serial Device converter detected
                                        [  744.420029] usb 1-7: Detected FT-X
                                        [  744.420464] usb 1-7: FTDI USB Serial Device converter now attached to ttyUSB0
                                        [  744.465529] pl2303 ttyUSB1: pl2303 converter now disconnected from ttyUSB1
                                        [  744.465539] pl2303 1-2:1.0: device disconnected
                                        [  744.592213] usb 1-2: reset full-speed USB device number 2 using xhci_hcd
                                        [  744.741634] pl2303 1-2:1.0: pl2303 converter detected
                                        [  744.742254] usb 1-2: pl2303 converter now attached to ttyUSB1
                                        [  744.876149] usb 1-8: reset full-speed USB device number 4 using xhci_hcd
                                        [  745.025388] cdc_acm 1-8:1.0: ttyACM0: USB ACM device
                                        [  745.025629] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
                                        [  745.025636] ftdi_sio 1-7:1.0: device disconnected
                                        [  745.156079] usb 1-7: reset full-speed USB device number 3 using xhci_hcd
                                        [  745.307475] ftdi_sio 1-7:1.0: FTDI USB Serial Device converter detected
                                        [  745.307495] usb 1-7: Detected FT-X
                                        [  745.307652] usb 1-7: FTDI USB Serial Device converter now attached to ttyUSB0
                                        [  745.308046] pl2303 ttyUSB1: pl2303 converter now disconnected from ttyUSB1
                                        [  745.308054] pl2303 1-2:1.0: device disconnected
                                        [  747.307309] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
                                        [  747.307318] ftdi_sio 1-7:1.0: device disconnected
                                        [  747.435543] usb 1-7: reset full-speed USB device number 3 using xhci_hcd
                                        [  747.586967] ftdi_sio 1-7:1.0: FTDI USB Serial Device converter detected
                                        [  747.586987] usb 1-7: Detected FT-X
                                        [  747.587202] usb 1-7: FTDI USB Serial Device converter now attached to ttyUSB0
                                        [  756.026324] device tap6.0 left promiscuous mode
                                        [  756.744069] vif vif-6-0 vif6.0: Guest Rx ready
                                        [  757.925017] usb 1-2: reset full-speed USB device number 2 using xhci_hcd
                                        [  758.321147] usb 1-2: reset full-speed USB device number 2 using xhci_hcd
                                        [  768.745084] pl2303 1-2:1.0: pl2303 converter detected
                                        [  768.746207] usb 1-2: pl2303 converter now attached to ttyUSB1
                                        [  769.803089] device vif6.0 left promiscuous mode
                                        

                                        And xensource.log as txt file while the VM started and got shutdown.

                                        Oh and so far everything looked good, right? Everything got attached, the VM booted and the properties of the VM shows that all 3 devices are "Attached".

                                        On the VM running ubuntu I get the following:

                                        vm@vm:~$ lsusb -t
                                        /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
                                            |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 12M
                                                |__ Port 1: Dev 4, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M
                                            |__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
                                        /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
                                        

                                        My USB 1.1 device (ZiGate) is present! The other 2 devices are USB2.0 and those are magically missing?! Why? How? What did I do wrong!? What can I try to make this work?

                                        Ah well, time to pci-pass-through my USB controller into that device again, although I would have prefered USB-passthrough! I did also apply scottyXCPNG's workaround, but not allow my USB 2.0 devices to be passed into the VM with those applied.

                                        1 Reply Last reply Reply Quote 0
                                        • C Offline
                                          cg
                                          last edited by

                                          I have good experience with WiBu Key dongles and a "Matrix USB-Key" (also license dongle) but couldn't get an Aladdin HASP working.
                                          I can pass it through (it's visible and attached) but the VM doesn't show it in device manger (Windows 10 1909). I gave up for now and will probably use a network USB thingie from SEH - already have 2 of their devices running in different environments and they work flawlessly.

                                          1 Reply Last reply Reply Quote 0
                                          • First post
                                            Last post