VirtualHere Server does not release USB?

Submitted by eraymond on #1

I have a program on the VirtualHere server that (also) sends commands to a USB device. Note: Only only application will ever connect to a USB device at a time. I'm not trying to have simultaneous access to the device from more than one client.

This works until a VH client ever connects to a USB device via vhusbarm. Killing and starting vhusbarm does not seem to work. My only workaround is to restart the entire server.

This blocks not only access to device that was opened, but to any USB device on the server. This uses the hidapi (https://github.com/libusb/hidapi) and hd_init() fails before it ever accesses the device. Perhaps there a better library to use or someway to reset vhusbarm?

Perhaps there is some workaround I can do before and after the call to my application (e.g., stop vhusbarm with some special option (disconnecting any vh clients), run the app, and then start vhusbarm).

Thanks!

Submitted by Michael on Thu, 2020/06/25 - 18:54

#2

Try this:

1. Stop and exit the vhusbdarm process
2. Edit the config.ini file and add the line

AutoAttachToKernel=1

3. Start the vhusbdarm process again

Now when you stop using the device, it will reattach itself to the host machine and be usable there

Submitted by eraymond on Fri, 2020/06/26 - 06:10

#3

That works, thanks! I now see the other articles in support on this (now that I know what to look for).

Is there any way for the server to bump a client off a device?

Worst case I can stop the server process and then start it up again when the sever is done with the device, but that is a bit crude.

Submitted by Michael on Fri, 2020/06/26 - 11:45

#4

Yes you can bump a client of a device (via another client) by starting one of the clients with the -a argument (for administrator)

e.g

vhui64.exe -a

then right click on an "In-Use" device and select "Disconnect from User"

Submitted by eraymond on Fri, 2020/06/26 - 17:50

#5

I'm hoping to do that programmatically.

Could I use vhui64.exe -a -t "STOP USING,id"?

Submitted by Michael on Fri, 2020/06/26 - 19:01

#6

Yes you can do that, no -a required

Submitted by eraymond on Fri, 2020/06/26 - 20:05

#7

I tried all of the following and got back FAILED when the remote mac client had server.113 in use (and verified via list)
- STOP USING,server.113
- STOP USING,113
- STOP USING ALL

This failed on the local when the device was free
- USE,113
- USE,server.113

Surprisingly, these worked:
- DEVICE INFO,113
- DEVICE INFO,server.113

Server is a raspberry pi that runs vhusbdarm (and now vhclientarmhf)

I also tried the use and stop using commands on the Mac and they failed as well.

Submitted by Michael on Fri, 2020/06/26 - 21:26

#8

Is the mac client, auto-using the device? If so it will recapture it again even if it is kicked.

Submitted by Michael on Sat, 2020/06/27 - 10:11

#10

OK when you use STOP USING you need to pass the correct address of the device to stop using it. Im thinking SERVER.113 might not be the correct address

Could you post the output of LIST when the mac client is using the device so i can see the address (the value in the brackets)

Submitted by eraymond on Mon, 2020/06/29 - 09:27

#12

Here you go.

Note that STOP USING ALL says OK, but fails to release it.

I get similar results running these commands on the client that is using the device.

$ sudo ./vhclientarmhf -a -t list
VirtualHere Client IPC, below are the available devices:
(Value in brackets = address, * = Auto-Use)

Raspberry Hub (quadusb:7575)
--> AmpliFire (quadusb.113) (In-use by:XXX (xxx) at 10.0.0.233)

Auto-Find currently on
Auto-Use All currently off
Reverse Lookup currently off
Reverse SSL Lookup currently off
VirtualHere Client is running as a service

$ sudo ./vhclientarmhf -a -t "STOP USING,113"
FAILED
$ sudo ./vhclientarmhf -a -t "STOP USING,quadusb.113"
FAILED
$ sudo ./vhclientarmhf -a -t "STOP USING ALL"
OK

$ sudo ./vhclientarmhf -a -t list
VirtualHere Client IPC, below are the available devices:
(Value in brackets = address, * = Auto-Use)

Raspberry Hub (quadusb:7575)
--> AmpliFire (quadusb.113) (In-use by:XXX (xxx) at 10.0.0.233)

Submitted by Michael on Mon, 2020/06/29 - 09:49

#13

Works fine for me. Have you purchased virtualhere? You cant use the console client without purchasing the server.

(Also note you dont need to use the -a argument on the command line to kick a user.)

See this log from my test setup, kicking a mac off an iLok on readynas.11: 

michael@ubuntu:~$ ./vhclientx86_64 -t "LIST"
VirtualHere Client IPC, below are the available devices:
(Value in brackets = address, * = Auto-Use)

Synology Hub (DiskStation:17570) 
   --> STORE N GO (DiskStation.21) 
ReadyNAS Hub (readynas:7575) 
   --> iLok (readynas.11) (In-use by:Michael Broadfoot (michael) at 192.168.1.211)
CloudHub_00298f (CloudHub_00298f:7575) 
QNAP Hub (QNAP:7575) 
   --> iLok (QNAP.11) 
ASUSTOR Hub (ASUS:7575) 
   --> STORE N GO (ASUS.44) 
CloudHub_GLMT300NV2 (CloudHub_00c662:7575) 
   --> STORE N GO (CloudHub_00c662.11) 
Main Server (SERVER:7575) 
   --> Token JC (SERVER.72) (In-use by: (michael) at 192.168.1.233)
MyCloud PR4100 (MyCloudPR4100:7575) 
   --> WIBU-BOX/U (MyCloudPR4100.13) 
MyCloud EX2Ultra (MyCloudEX2Ultra:7575) 
   --> RTL2838UHIDIR (MyCloudEX2Ultra.11) 

Auto-Find currently on
Auto-Use All currently off
Reverse Lookup currently off
Reverse SSL Lookup currently off
VirtualHere Client is running as a service
michael@ubuntu:~$ ./vhclientx86_64 -t "STOP USING,readynas.11"
OK
michael@ubuntu:~$ ./vhclientx86_64 -t "LIST"
VirtualHere Client IPC, below are the available devices:
(Value in brackets = address, * = Auto-Use)

Synology Hub (DiskStation:17570) 
   --> STORE N GO (DiskStation.21) 
ReadyNAS Hub (readynas:7575) 
   --> iLok (readynas.11) 
CloudHub_00298f (CloudHub_00298f:7575) 
QNAP Hub (QNAP:7575) 
   --> iLok (QNAP.11) 
ASUSTOR Hub (ASUS:7575) 
   --> STORE N GO (ASUS.44) 
CloudHub_GLMT300NV2 (CloudHub_00c662:7575) 
   --> STORE N GO (CloudHub_00c662.11) 
Main Server (SERVER:7575) 
   --> Token JC (SERVER.72) (In-use by: (michael) at 192.168.1.233)
MyCloud PR4100 (MyCloudPR4100:7575) 
   --> WIBU-BOX/U (MyCloudPR4100.13) 
MyCloud EX2Ultra (MyCloudEX2Ultra:7575) 
   --> RTL2838UHIDIR (MyCloudEX2Ultra.11) 

Auto-Find currently on
Auto-Use All currently off
Reverse Lookup currently off
Reverse SSL Lookup currently off
VirtualHere Client is running as a service
michael@ubuntu:~$

Submitted by Wol on Sat, 2024/11/09 - 13:19

#14

Appears related :

I use the paid VH server on a QNAP Nas.  I use it primarily to allow one of several VMs to use various USB device.  QNAP’s own Virtualization Station (VS) requires you to allocate the USB devices to machines by editing the VM which can be done with the VM running, but limits you to a maximum of 4 USB devices including any hubs and cannot be done from with the VM.

Thus I use VH.  However it seems that once allocated to a VM by using VH, the USB devices are never released back to VS for reallocation through the VS method.  Even stopping the server, the VMs, and VS, and rebooting the host NAS and not restarting VH they are no longer visible in VS.  

USB storage device are however available to the NAS outside of VS (they are visible in File station etc.).

This also means that until the VM has finished booting to at least the log in screen, no usb devices (mouse and keyboard) are available  during startup to access BIOS etc.


 Can you offer a solution?


Regards

Submitted by Michael on Sat, 2024/11/09 - 15:28

#15

Can you see the USB device listed in the virtualhere client (inside the VM's) after you stop using it on one of the VMs? I.e it doesnt disappear from Virtualhere, only from VS?

If you physically remove the usb device after using via virtualhere and plug it in again does it show ok then in VS?

Submitted by Wol on Sat, 2024/11/09 - 16:38

#16

  1. yes so long as the VH server is running obviously.

  2. No.  Even with VH turned off, plugging and unplugging USB devices makes no difference; they appear in the NAS (if USB storage at least) but not in VS.


    Regards
     

Submitted by Michael on Sat, 2024/11/09 - 17:09

#17

Ok seems like a bug in VS, email QNAP and see if they can help