==== First of all:
1) I understand this
is the official list of supported USB devices; however I hope you'll have a suggestion even if my hardware is not on that list.
2) I understand there are alternatives to connecting an UPS directly to a VM (ie: network agent). But right now we don't have one of those UPSes and I'd
like to convert a physical machine to virtual with as few changes as possible.
ESXi-4.1 on Dell PE-T310.
VM (virtual hw v7): RHEL5.x (CentOS), latest kernel (2.6.18-194.17.4.el5)
USB device: APC Back-UPS CS 650 (051d:0002)
If used on the real hardware, the UPS is detected w/o any issue, I can start apcupsd and check its status.
If used attached to the VM (ESXi: add USB controller, then ADD USB device) the device is "partially" detected:
See lines marked with "<==== PROBLEM":
hub 2-0:1.0: USB hub found
usb 2-1: new full speed USB device using uhci_hcd and address 2
usb 2-1: configuration #1 chosen from 1 choice
drivers/usb/input/hid-core.c: usb_submit_urb(ctrl) failed <===== PROBLEM
drivers/usb/input/hid-core.c: timeout initializing reports <===== PROBLEM
hiddev96: USB HID v1.10 Device [American Power Conversion Back-UPS CS 650
FW:817.v4.I USB FW:v4] on usb-0000:02:02.0-1
Those 2 lines are not present when installing Linux on the PE-T310 directly.
When used in the VM I can start apcupsd but then either I get no output from apcaccess or I get empty values, like:
CABLE : USB Cable
MODEL : Back-UPS CS 650
UPSMODE : Stand Alone
STARTTIME: Tue Oct 26 20:20:05 CEST 2010
STATUS : ONLINE
LINEV : 000.0 Volts <==== PROBLEM
LOADPCT : 0.0 Percent Load Capacity <==== PROBLEM
BCHARGE : 100.0 Percent
TIMELEFT : 27.2 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME : 0 Seconds
OUTPUTV : 000.0 Volts <==== PROBLEM
BATTDATE : 1980-00-00 <==== PROBLEM
==== THINGS I TRIED:
- adding the device to the kernel "quirks/HID_QUIRK_NOGET" list, w/o success.
- testing it on the same VM running on VMware Workstation 7.x: it works perfectly
BTW, this is the log
grep -Ei "(usb|uhci)" vmware.log |grep -v "disk backing" > usb.log
Oct 29 20:40:51.353: vmx| DICT usb.present = TRUE
Oct 29 20:40:51.354: vmx| DICT usb.pciSlotNumber = 32
Oct 29 20:40:51.354: vmx| DICT usb:1.present = TRUE
Oct 29 20:40:51.354: vmx| DICT usb:1.deviceType = hub
Oct 29 20:40:51.354: vmx| DICT usb.analyzer.enable = true
Oct 29 20:40:51.354: vmx| DICT usb:0.present = FALSE
Oct 29 20:40:51.354: vmx| DICT usb.autoConnect.device0 = path:2/0/0
Oct 29 20:40:51.431: vmx| USB: Initializing 'Generic' backend
Oct 29 20:40:51.431: vmx| USBGL: Connected to arbitrator socket: 39
Oct 29 20:40:51.431: vmx| USB: Initializing 'Virtual Hub' backend
Oct 29 20:40:51.431: vmx| USB: Initializing 'Virtual HID' backend
Oct 29 20:40:51.431: vmx| USB: Initializing 'Remote Device' backend
Oct 29 20:40:51.432: vmx| RemoteUSBVMX: Protocol version 15
Oct 29 20:40:51.432: vmx| RemoteUSBVMX: no delay setting is TRUE.
Oct 29 20:40:51.432: vmx| USB: Initializing 'Virtual Mass Storage' backend
Oct 29 20:40:51.432: vmx| USB: Initializing 'Virtual CCID' backend
Oct 29 20:40:51.432: vmx| USB-CCID: failed to GetModulePath.
Oct 29 20:40:51.432: vmx| USB: Unable to initialize 'Virtual CCID' backend
Oct 29 20:40:51.464: vmx| USB: Initializing 'UHCI' host controller
Oct 29 20:40:51.465: vmx| USB: Initializing 'EHCI' host controller
Oct 29 20:40:51.487: vmx| USB: Connecting device 0x20003051d0002
Oct 29 20:40:51.487: vmx| VMXVmdbLoadUsbDevices: New set of 1 USB devices
Oct 29 20:40:51.489: vmx| USBGA: device 20003051d0002 arrived
Oct 29 20:40:51.557: vmx| VMXVmdbLoadUsbDevices: New set of 1 USB devices
Oct 29 20:41:15.837: vcpu-0| UHCI: HCReset
Oct 29 20:41:19.375: vcpu-0| UHCI: HCReset
Oct 29 20:41:21.215: vmx| USBGL: SETCONFIGURATION=1 failed -1:16:Device or resource busy, work around triggered
Oct 29 20:41:22.034: vmx| UHCI: unexpected in/out 1 pid 69
Oct 29 20:41:22.551: vmx| UHCI: unexpected in/out 1 pid 69
Oct 29 20:41:23.054: vmx| UHCI: unexpected in/out 1 pid 69
Oct 29 20:41:23.559: vmx| UHCI: unexpected in/out 1 pid 69
Oct 29 20:41:24.064: vmx| UHCI: unexpected in/out 1 pid 69
Oct 29 20:41:24.565: vmx| UHCI: unexpected in/out 1 pid 69
Oct 29 20:41:25.071: vmx| UHCI: unexpected in/out 1 pid 69
Oct 29 20:41:25.574: vmx| UHCI: unexpected in/out 1 pid 69
Oct 29 20:41:26.080: vmx| UHCI: unexpected in/out 1 pid 69
Oct 29 20:41:26.581: vmx| UHCI: unexpected in/out 1 pid 69
Oct 29 20:41:27.086: vmx| UHCI: unexpected in/out 1 pid 69
Oct 29 20:41:27.591: vmx| UHCI: unexpected in/out 1 pid 69
Oct 29 20:41:28.093: vmx| UHCI: unexpected in/out 1 pid 69
Oct 29 20:41:28.601: vmx| UHCI: unexpected in/out 1 pid 69
Oct 29 20:41:29.103: vmx| UHCI: unexpected in/out 1 pid 69
Oct 29 20:41:29.610: vmx| UHCI: unexpected in/out 1 pid 69
Oct 29 20:41:30.113: vmx| UHCI: unexpected in/out 1 pid 69
Oct 29 20:41:30.617: vmx| UHCI: unexpected in/out 1 pid 69
Oct 29 20:41:31.121: vmx| UHCI: unexpected in/out 1 pid 69
Oct 29 20:41:31.627: vmx| UHCI: unexpected in/out 1 pid 69
I then tried "uhci.syncWriteback = true" and "usb.generic.skipsetconfi=true" w/o success.
I verified that it will work if I take the VMDirectPath route instead of USB passthrough.
Unfortunately VMDirectPath has its own issues (all configured memory is reserved, no snapshots while running, all USB devices connected to the same PCI device linked to the same VM,...).
I've been having this exact same problem with an APC XS 1500. Interestingly, while the linux driver seems to have a problem, other guest operating systems seem to be able to interact with the APC just fine. I tried installing apcupsd from pkgsrc in a NetBSD 5.0.2 guest and everything worked just as it was supposed to.
It's not clear to me yet if this is a bug in the linux HID or something idiosyncratic with the virtual usb controller, but I'm inclined to suspect the former.
I've tested in Fedora 10, 13, and 14, with both 32 and 64-bit kernels/libraries; and in NetBSD 5.0.2, 32-bit- only.
Not exactly. What I did was to get a Smart-UPS with a network card, and use that to monitor the status of the UPS. The network interface provides quite a bit more information anyway.
I know that the topic is ancient but this time I face exactly the same problem with ESXi 5 and a Ubuntu Linux 12.04 64bit server installation together with a BackUps CPS 500.
Did anyone find a solution? I cannot use the vMA as my ESXi server has a free licence.
Thank you in advance.
I have a similar problem with USB passthrough.
The host server is a Fujitsu Primergy TX 150 S7 with ESXi 4.1 installed.
I connect i.e. a USB keyboard to the host server. I add the USB controller to a Win 7 VM with HW 7 and latest VM tools (no problem here).
When I try to add the USB device, it isn't possible because that option is greyed out.
I've tried this with a USB mouse and an APC UPS, always the same problem: greyed out option.
I even tried all the USB ports on the server.
Anyone got a solution for this?
I had the exact same problem using the following bits and pieces:
The idea is to have the Ubuntu VM run an apcupsd master service that other VMs can connect to so they get a chance to do something useful in the event of a power failure. And to power off the VM host too of course.
Without thinking too much, my initial attempt at making this work had me adding a UHCI/EHCI controller to the Ubuntu VM and then passing through the APC device to that controller. It worked - almost. I also got erratic behaviour and the errors below:
drivers/usb/input/hid-core.c: usb_submit_urb(ctrl) failed
drivers/usb/input/hid-core.c: timeout initializing reports
I tried a whole bunch of things, including adding quirks options to the usbhid driver, but to no avail. Finally, while taking the VM host apart for other reasons, I discovered that the actual physical USB controller I was using was a xHCI (USB 3.0) controller. I then proceeded to change the virtual controller in the Ubuntu VM to a virtual xHCI controller too - and everything worked! No delays, no errors - just apcupsd goodness.
Realizing this is sort of an anachronism in relation to the original post, I don't know if this really helps, but I see others having the same issue elsewhere - so I am hoping this helps someone 🙂
Thank you SO MUCH for digging this thread up to report your findings. I want to use apcupsd with my APC Back-UPS 500 with USB passthrough.
I can also confirm, changing the controller to xHCI works with an ESXi 5.1 server on a mordern Dual Xeon supermicro motherboard with usb 2.0 ports as well!!! Ubuntu 10.04 with vicli installed.
I tried the same trick on vma 5 (vsphere management assistant), running opensuse, after upgrading the hardware version to 9 to add xHCI support. Unfortunately, the kernel does not support it, and you get more USB errors. Looks like I have to use my Ubuntu VM.
I just want to add that I too am thankful to have found this post. I would also add that I DID NOT have to actually connect the APC UPS through an xHCI USB 3 port in order to see the issue fixed. Just adding the virtual xHCI controller to the VM while the APC Back-UPS was still connected through the USB 2.0 controller was sufficient. And what a difference! Prior to adding the xHCI controller syslog (on the CentOS 6 VM the APC was mapped to) was logging a boatload of these errors whenever I issued "apcaccess status":
kernel: drivers/hid/usbhid/hid-core.c: usb_submit_urb(ctrl) failed
kernel: generic-usb 0003:051D:0002.0003: timeout initializing reports
And it sometimes took five to eight seconds to get a result (often with timeouts).
After adding the xHCI controller to the VM "apcaccess status" immediately returns a result -- every time. And no more USB errors in syslog. Absolutely Night-and-Day!
I can also have the CentOS VM shutdown ESXi (which is configured to suspend all VM's as the shutdown action) and the apcupsd daemon works correctly when the VM resumes (i.e. if utility power is still out, apccontrol will issue another doshutdown or if power has returned, apccontrol will issue a mainsback). Absolutely perfect!
To have a Linux VM actually shutdown ESXi (and suspend all guests -- provided that's the shutdown action), all you need is a shell script in /etc/apcupsd named doshutdown that looks similar to this:
/usr/bin/sshpass -p myrootpassword /usr/bin/ssh -x -l root 172.16.x.x "/sbin/shutdown.sh && /sbin/poweroff"
exit 99 #keep apccontrol from doing it's own shutdown
(Change "myrootpassword" appropriately, change "172.16.x.x" to the IP of ESXi, install sshpass, make sure ESXi has ssh enabled (maintenance mode), and ssh at least once to ESXi from the VM in order to accept the ssh signature.) Of course you also have to configure /etc/apcupsd/apcupsd.conf as needed/desired.
David G. Frailey, MCSE