USB passthrough test reports in 7.5RC1


  • First off, thanks to @Aimdev and @fjen for providing a good write up of the steps taken to get USB passthrough to work.

    I followed them all pretty much with out any difficulty and with no errors on anything for a Broadcom Bluetooth USB card (Broadcom Corp._BCM2045B) that's built into my laptop I'd like to pass through to a Linux VM.

    And I get all the way up to where the USB device is correctly presented in the XCP-ng Centre application, but the device doesn't [seem to] appear at the OS level in dmesg | grep usbcore or lusb outputs in my guest OS VM.

    However, since I didn't any failure to start the vm or other errors, I had not executed the final command: xe vm-param-set uuid=<VM UUID> platform:device-model=qemu-upstream-compat

    But since the Broadcom chip still didn't appear in the guest Linux VM, I shutdown the VM and then executed the above command with the VM UUID.

    But after a restart, the VM still doesn't see the Broadcom USB device.

    Any idea what could be up or suggestions where I need to dig?


  • @fjen I also got the same error...

    INTERNAL_ERROR(xenopsd internal error: Call to usb reset failed: Forkhelpers.Spawn_internal_error("usage: usb_reset.py attach [-h] -d DOMID -p PID [-r RESET_ONLY] device\nusb_reset.py attach: error: argument -r: expected one argument\n", "", _))


  • @xiaolou86 Did you find a resolution for this issue?

  • XCP-ng Team

    For future reference, github issue related to USB passthrough: https://github.com/xcp-ng/xcp/issues/108


  • No luck with passing through a zwave usb dongle. Have tried two different types:
    Aeon Labs Z-Stick Gen 5 (https://aeotec.com/z-wave-usb-stick)
    Nortek GoControl HUSBZ-1 (http://www.gocontrol.com/detail.php?productId=5)

    Tried both adding through XCP-NG Center and following the procedure above. I can see it added to the vm, but nothing shows in the guest (CentOS7 and Ubuntu Server 1604 and 1804).

    This stick contains both an 02 device type and 0a, both CDC device types it appears.


  • working! i was able to pass through my AEOTEC zwave usb device.

    @fjen had a good write up i had to change it a little bit for me. follow step 1-4

    @fjen said in USB passthrough test reports in 7.5RC1:

    @olivierlambert Sure thing!

    Because I was passing through a USB Bluetooth dongle, I had to specifically create an "allow" entry in /etc/xensource/usb-policy.conf.

    1. Run lsusb and identify the device to be passed through.
    Bus 001 Device 002: ID 1b70:100f
    Bus 001 Device 003: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS
    Bus 001 Device 004: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
    Bus 001 Device 005: ID 0557:7000 ATEN International Co., Ltd Hub
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 001 Device 006: ID 0557:2419 ATEN International Co., Ltd
    

    ......

    what i did different

    [root@xcp-ng ~]# nano /etc/xensource/usb-policy.conf

    change DENY: class=02 # Communications and CDC-Control to ALLOW: class=02 # Communications and CDC-Control
    also don't add the class to to your new line ALLOW:vid=0658 pid=0200

    my usb-policy.conf

    # 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
    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
    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
    
    

    now run /opt/xensource/libexec/usb_scan.py -d

    [root@xcp-ng ~]# /opt/xensource/libexec/usb_scan.py -d
    [{"product-desc": "", "product-id": "0200", "description": "Sigma Designs, Inc.", "vendor-desc": "Sigma Designs, Inc.", "version": "2.00", "vendor-id": "0658", "path": "5-1", "serial": ""}]
    [root@xcp-ng ~]#
    
    

    reboot the server and you can now passthrough the usb using xcp-ng center


  • This post is deleted!

  • @redalert11 Nice! I'll give that a shot when I get a chance. I had resorted to using usb over ip until it worked.

  • XCP-ng Team

    Great news!

    Feel free to update the wiki to add this info 🙂


  • @redalert11 Thank you, I can now add my AEOTEC Z-wave key to my jeedom VM.

    But this key doesn't appear in my debian 9 VM.

    On my server :

    lsusb
    Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
    Bus 003 Device 003: ID 0658:0200 Sigma Designs, Inc.
    Bus 005 Device 002: ID 10d5:5a08 Uni Class Technology Co., Ltd
    Bus 005 Device 003: ID 0624:0248 Avocent Corp. Virtual Hub
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    

    Sigma Designs is my USB key I want in my VM.
    Thanks to @redalert11, I enable the passthroud in XC-ng center.
    I attach the Sigma Designs key to my Jeedom VM (under Debian 9)

    I start the VM.

    lsusb
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 002 Device 002: ID 0627:0001 Adomax Technology Co., Ltd
    Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    
    

    Sigma Designs is missing.
    Any Idea ? (tried with Debian 8, and Ubuntu 18.04 LTS, Windows 10 same problem).

    But no problem when I passthrough the same aeotec key on a Debian9 vm under vmware 😞


  • First, I want to say thanks to @fjen, @redalert11, and @FrCo for providing this information. It has certainly gotten me closer to USB pass through with a Linux VM.

    @FrCo or @redalert11: were either of you able to get your AEOTEC Z-wave 5 gen USB to show as a device in your guest VM?

    I followed the instructions above and was able to configure USB Pass through in XCP-ng Center, however in my CentOS 7.6 guest VM I only ever see the following devices:

    [root@centos7.6 ~]$ lsusb
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 002 Device 002: ID 0627:0001 Adomax Technology Co., Ltd 
    Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    

    I also checked dmesg and didn't find a single trace that it attempted to load the usb device.


  • Hello,
    I am Georg, and I am also new to XCP, kind of...at work, we have XEN, but sadly, thats not my business.

    Long story short, I got nearly everything sorted out, but not USB passthrough.
    I got all devices showing up in XCP-center, and attached them to the VM.

    When I start the VM, all USB devices are attached. But as soon as the VM is booting, the status "Attached" changes to "No".
    [VM -> Properties -> USB]

    However, what I found out: for example, I attach my keyboard and pass it to my Windows vm: then why I can control the local XEN console with this keyboard I passed through?

    And this error:
    "Failed","Starting VM 'Windows 10 (64-bit) (1)'
    Internal error: xenopsd internal error: Call to usb reset failed: Forkhelpers.Spawn_internal_error("usage: usb_reset.py attach [-h] -d DOMID -p PID [-r RESET_ONLY] device\nusb_reset.py attach: error: argument -r: expected one argument\n", "", _)
    Time: 00:00:23","xcp-ng","Jun 29, 2019 12:05 AM"


  • @kcah427 did you ever resolved this? I have the same result trying to pass a Conbee2 stick into an Ubuntu VM.


  • @axiom00

    I did a bit more research and determined that XCP-ng was passing the USB device through to the guest OS, although either didn't have the right drivers for my z-wave USB stick, or otherwise didn't know what to do with it; so it always just passed it to the guest as a root hub.

    I wasn't particularly interested in spending too much more time on it so I purchased the following PCI-E card and passed the whole controller through to the guest. That solved my problem and it has been working ever since.

    https://www.amazon.com/gp/product/B00JFR2H64/ref=ppx_yo_dt_b_asin_title_o05_s00

  • XCP-ng Team

    That's a solution 😛


  • @kcah427 Thanks for sharing your solution. I end up using a Raspberry Pi as a Socat host and passing the USB Zigbee stick over ethernet to the VM. Not ideal but it works.


  • @kcah427 did you do anything special to pass through the USB card?

    I'm trying with a ASM1142 but can not boot the VM once it is assigned.

    Is there a particular reason why you chose the card that you used?

    Thanks.


  • Hi,

    I have XCP-NG 8.0 loaded onto an Intel NUC and I'm trying to pass a USB device through to a guest V.M. Although the setup using the CLI seems to go OK, the guest never sees the device. I've tried 2 different guests with no success

    Digging into the logs a bit more I found this:

    Feb 15 14:20:49 xcp-ng-bywirlgr qemu-dm-17[18527]: qemu-dm-17: Warning: speed mismatch trying to attach usb device "ConBee II" (full speed) to bus "ehci.0", port "1" (high speed)
    

    This seems to come from qemu-dp/hw/usb/bus.c:usb_check_attach() which sets the warning if the speed of the probed USB device is different to the speed of the emulated USB controller in the guest (at least that's what I think it does)

    Despite the fact that it is classed as a warning, it appears to abort the attachment of the device to the guest in qemu-dp/hw/usb/bus.c:usb_device_attach() if the warning has been generated.

    • is it possible to use one of the "xe vusb-param-*" commands to set the emulated USB bus to USB 1.x instead of 2.x (ehci)? I haven't been able to trace back where the bus is created yet

    • if not, is it possible to comment out that check and see what happens? To be honest, the check puzzles me. It is perfectly valid to plug a FULL speed (USB1.x) device into a HIGH speed (USB2.x) or SUPER speed (USB3.x) bus and have it work normally. There might be some magic have to happen at the port level to make it work, but it works just fine as the USB 1.x device I'm trying to use is plugged into a USB 2.x port on my NUC

    Any ideas?

    Thanks,

    Gary

  • XCP-ng Team

    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.


  • 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

XCP-ng Pro Support

XCP-ng Pro Support