Dear Scott,
Thanks for redirecting my message to the right place.
Hereby some additional information:
- Hardware: HP ProLiant DL380 Gen10
- Hypervisor: ESXi 6.5.0 Update 2 version 650.U2.9.6.8
- Operating System: RHEL 7.5 (64 bits)
- Dongle: Gemalto Sentinel HL (computer ID key) with Gemalto RMS 9.4 (x3)
We are using USB dongles to protect our software and problems of licenses are reported after a "certain time" using our tools (that are protected with the Gemalto RMS solution).
Our tools are simulation modules that are run in a batch especially during the night or the week-end.
The tools are dispatched accross 3 Virtual Machines, each of one is protected by a dongle.
3 dongles are therefore connected directly to the physical ports of the server and assigned invidually to each Virtual Machine.
The problem happens after between 1 and 4 hours of usage.
During this time approx. between 40 and 160 simulations could be executed, i.e. between 200 and 800 license checks are performed (the license is checked at each simulation module start, and each simulation imples 4-6 different modules).
After further investigations it appears that when license issues appear, the dongle protecting the complaining software seems no more detected, as suggested by the dmesg command:
[ 2.570684] usb 2-2.1: new full-speed USB device number 4 using uhci_hcd
[ 3.370152] usb 2-2.1: New USB device found, idVendor=04b9, idProduct=0300
[ 3.370156] usb 2-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3.370159] usb 2-2.1: Product: Sentinel HL
[ 3.370161] usb 2-2.1: Manufacturer: SafeNet Inc.
[...]
[237454.982944] usb 2-2-port1: Cannot enable. Maybe the USB cable is bad?
[237455.984024] usb 2-2-port1: cannot disable (err = -110)
[237456.985746] usb 2-2-port1: cannot reset (err = -110)
[237457.987996] usb 2-2-port1: cannot reset (err = -110)
[237458.989341] usb 2-2-port1: cannot reset (err = -110)
[237459.992320] usb 2-2-port1: cannot reset (err = -110)
[237460.993986] usb 2-2-port1: cannot reset (err = -110)
[237460.993991] usb 2-2-port1: Cannot enable. Maybe the USB cable is bad?
[237461.996211] usb 2-2-port1: cannot disable (err = -110)
[237462.998937] usb 2-2-port1: cannot reset (err = -110)
[237464.001481] usb 2-2-port1: cannot reset (err = -110)
[237465.003698] usb 2-2-port1: cannot reset (err = -110)
[237466.006488] usb 2-2-port1: cannot reset (err = -110)
[237467.009472] usb 2-2-port1: cannot reset (err = -110)
[237467.009476] usb 2-2-port1: Cannot enable. Maybe the USB cable is bad?
[237468.011406] usb 2-2-port1: cannot disable (err = -110)
[237469.013497] usb 2-2-port1: cannot disable (err = -110)
[237474.024640] hub 2-2:1.0: hub_ext_port_status failed (err = -110)
These traces are repeated continuously once the problem of license appears.
It is then no more possible to use our tools due to this issue, and the only possibility to recover are:
- to reboot the machine
- to disconnect and reconnect physically the dongle
- to disconnect and reconnect virtually the dongle via commands sent to the server via its SSH interface e.g.
vim-cmd vmsvc/device.disconnusbdev 13 "path:0/1/3"
vim-cmd vmsvc/device.connusbdev 13 "path:0/1/3"
We already tried a lot of things:
- disabling USB autosuspend feature (was already disabled by default)
- using other USB ports (to excluse problems with the ports)
- using other dongles (to exclude problems with the dongles themselves)
- using a powered USB hub instead of connecting directly on the server (to exclude power stability of USB ports)
and the results are identical.
I must add that we are also using the same tools with the same protection solutions on the same Operating System on physical environments (e.g. HP Z4 workstations) and we never had such problems.
We therefore suspect the virtualised environment playing a role in this.
Please feel free to ask if you need additional information.
Many thanks in advance.
Best regards,
Sébastien