Hi,
I have a zero client device that uses PCoIP to connect to a virtual machine (VM1) and also forwards a USB device (a joystick) to it. From that virtual machine, I then use horizon view client to make another PCoIP connection to a second virtual machine (VM2). I want to forward the joystick from VM1 to VM2, but the client does not allow this.
These are the USB devices connected to the virtual machine:
The device that I want to forward is highlighted. It is connected to the 'VMware View Virtual USB Host Controller' USB controller.
Digging through the USB arbitration logs, I found these lines:
usbArb| I120: VMware USB Arbitration Service Version 12.2.8
vthread-3| I120: VTHREAD initialize thread 3 "vthread-3" host id 2056
vthread-3| I120: USBArb: Starting VMUSBArbService args:'VMUSBArbService'
vthread-3| I120: USBGW: Host controller #0 hc= "\\?\HCD0"
vthread-3| I120: USBGW: Host controller #0 rootHubName="USB#ROOT_HUB#5&3bb57b&0#{f18a0e88-c30c-11d0-8815-00a0c906bed8}"
vthread-3| I120: USBGW: Host controller #0 rootHubDevInst="USB\ROOT_HUB\5&3bb57b&0"
vthread-3| I120: USBGW: Host controller #1 hc= "\\?\HCD1"
vthread-3| I120: USBGW: Host controller #1 rootHubName="USB#ROOT_HUB20#5&299e1c9f&0#{f18a0e88-c30c-11d0-8815-00a0c906bed8}"
vthread-3| I120: USBGW: Host controller #1 rootHubDevInst="USB\ROOT_HUB20\5&299e1c9f&0"
vthread-3| I120: USBGW: Host controller #2 hc= "\\?\HCD2"
vthread-3| I120: USBGW: Host controller #2 rootHubName="USB#vmwvhub#0000#{f18a0e88-c30c-11d0-8815-00a0c906bed8}"
vthread-3| I120: USBGW: Host controller #2 rootHubDevInst="USB\vmwvhub\0000"
vthread-3| I120: USBArbW: Connected to HCMON version 3.12
vthread-3| W110: USBArbW: Failed to send HC Name:\??\HCD2 to HCMON: A device attached to the system is not functioning (31)
vthread-4| I120: VTHREAD initialize thread 4 "vthread-4" host id 2096
vthread-4| I120: HOSTINFO 827538701 @ 10000000Hz -> 0 @ 1000000000Hz
vthread-4| I120: HOSTINFO ((x * 3355443200) >> 25) + -82753870100
vthread-3| I120: VTHREAD initialize thread 3 "vthread-3" host id 2252
vthread-3| I120: USBArb-BT: Beginning inquiry thread
vthread-4| I120: USBArb: VMUSBArbService Started.
vthread-4| W110: USBArbEnumerate: CM busy.
vthread-4| W110: USBArbEnumerate exit: CM busy.
vthread-4| I120: USBArb: Num instances:2, user:SYSTEM client:vmware-view-usbd.exe
vthread-4| I120: USBArb: Client 2528 connected (version: 6)
vthread-4| W110: USBArb: Getting descriptor for device 0x10e0f0003 for client 2528, type 1, index 0, languageID 0x0
vthread-4| W110: USBArb: Getting descriptor for device 0x10e0f0003 for client 2528, type 2, index 0, languageID 0x0
The line about 'Failed to send HC Name' looked promising, so I read into this and found a related thread on this site that proposed a solution. I performed the registry tweak suggested there (setting 'DisableDriverCheck' to true for HCMON) and got the following log results:
usbArb| I120: VMware USB Arbitration Service Version 12.2.8
vthread-3| I120: VTHREAD initialize thread 3 "vthread-3" host id 2084
vthread-3| I120: USBArb: Starting VMUSBArbService args:'VMUSBArbService'
vthread-3| I120: USBGW: Host controller #0 hc= "\\?\HCD0"
vthread-3| I120: USBGW: Host controller #0 rootHubName="USB#ROOT_HUB#5&3bb57b&0#{f18a0e88-c30c-11d0-8815-00a0c906bed8}"
vthread-3| I120: USBGW: Host controller #0 rootHubDevInst="USB\ROOT_HUB\5&3bb57b&0"
vthread-3| I120: USBGW: Host controller #1 hc= "\\?\HCD1"
vthread-3| I120: USBGW: Host controller #1 rootHubName="USB#ROOT_HUB20#5&299e1c9f&0#{f18a0e88-c30c-11d0-8815-00a0c906bed8}"
vthread-3| I120: USBGW: Host controller #1 rootHubDevInst="USB\ROOT_HUB20\5&299e1c9f&0"
vthread-3| I120: USBGW: Host controller #2 hc= "\\?\HCD2"
vthread-3| I120: USBGW: Host controller #2 rootHubName="USB#vmwvhub#0000#{f18a0e88-c30c-11d0-8815-00a0c906bed8}"
vthread-3| I120: USBGW: Host controller #2 rootHubDevInst="USB\vmwvhub\0000"
vthread-3| I120: USBArbW: Connected to HCMON version 3.12
vthread-4| I120: VTHREAD initialize thread 4 "vthread-4" host id 2096
vthread-4| I120: HOSTINFO 1071053609 @ 10000000Hz -> 0 @ 1000000000Hz
vthread-4| I120: HOSTINFO ((x * 3355443200) >> 25) + -107105360900
vthread-3| I120: VTHREAD initialize thread 3 "vthread-3" host id 2164
vthread-3| I120: USBArb-BT: Beginning inquiry thread
vthread-4| I120: USBArb: VMUSBArbService Started.
vthread-4| I120: USBArb: Num instances:2, user:SYSTEM client:vmware-view-usbd.exe
vthread-4| I120: USBArb: Client 2240 connected (version: 6)
vthread-4| W110: USBArbEnumerate: CM busy.
vthread-4| W110: USBArbEnumerate exit: CM busy.
vthread-4| W110: USBArb: Getting descriptor for device 0x10e0f0003 for client 2240, type 1, index 0, languageID 0x0
vthread-4| W110: USBArb: Getting descriptor for device 0x10e0f0003 for client 2240, type 2, index 0, languageID 0x0
vthread-4| I120: USBGW_ENUM: Couldn't get instanceId from topology:0x2000000 port:1. Leaving out of enum
vthread-4| I120: USBGW_ENUM: Couldn't get instanceId from topology:0x2000000 port:1. Leaving out of enum
vthread-4| I120: USBGW_ENUM: Couldn't get instanceId from topology:0x2000000 port:1. Leaving out of enum
[many more similar entries omitted]
It seems that the 'DriverCheck' function of HCMON is important after all! I can still not forward USB devices after making this registry tweak. Another thread on this site suggests that the underlying cause is a 'faulty device driver', though in this case I think it is a problem with VMWare's implementation of virtual USB devices. I can reproduce this issue using any forwarded USB device, not just the joystick.
I am a bit stuck at this point. Does anyone have any ideas as to what I can try to resolve this issue? What exactly is the problem with the USB device that stops it from being reported on by HCMON? Is there any configuration change I can make that would get the device working? Alternatively, do you think it would be possible to implement a custom filter driver (or similar) to patch the device so that it can operate with HCMON?
Many thanks,
Oliver.
You're asking to do nested USB redirection which will not work.
Hi Jack,
Could you clarify what you mean when you say it will not work? Are we talking a fundamental limitation of the implementation as it exists right now, or is it just not supported at the moment?
It would be handy for me to have something concrete so that I can get my project to consider a different solution here. Our working assumption right now is that we can somehow hack around with the drivers for the forwarded device on the first VM to get working as we need.
Thanks,
Oliver.
I don't believe it's supported. There's a level of obfuscation with many USB devices, so for example an audio device is usually presented as a generic usb audio device. Depending on the device, I could see the nested session having trouble identifying the device.
I'd have to double check with our USB gurus, but I don't believe USB redirection was ever designed for nesting.
Hi Jack,
It would be handy if you could check that for me with your USB guys.
Our project works on a fairly long time scale so if there is a chance of this being supported in a version released in a few years time it would be useful for us to know.
Thanks,
Oliver.
Hi Jack,
Any update on this one? We're also having a similar situation.
Thanks