Back in March of 2017, I needed to go back to using my SuperServer Workstation as my daily driver Windows 10 workstation, in large part because of excessive video render times for 4K video production workflow. This mean it was time to revisit how well this VM worked with the latest ESXi 6.5.0d, determining whether all features and functions behaved as they did back in the ESXi 6.0 days, when I first wrote this article:
Backstory on the new USB issues noticed in 6.5.x
It would seem that VMware ESXi doesn't officially support ISOC (isochronous) for passthrough, used for video and audio devices, see:
- Supported USB device models for passthrough from an ESX or ESXi host to a virtual machine (1021345)
kb.vmware.com/kb/1021345These USB devices are not available for passthrough:
USB devices such as mice and keyboards that have a bootable HID interface.
USB devices such as real time video cameras and audio devices that use isochronous data transfers.
4 ways to downgrade the VM hardware version. As is often the case, a fix of sorts, supported or not, is thankfully lurking around the corner. This method is actually supported by VMware. A slight inconvenience, in my case, is that the VM in question is running VCSA and sports no less than a dozen disks. Adding each and every one.
I had been using my SHINA MUSE Z5 HIFI USB to S/PDIF Converter USB DAC PCM2704 Sound Card Optical Coaxial for many months with ESXi 6.0, so it was surprising that I just couldn't get sound working at all once I moved to ESXi 6.5, and it didn't matter if I had a USB 2.0 or USB 3.0 controller added to the Hardware Version 13 Windows 10 VM.
![Supported Supported](https://www.virtualization.net/wp-content/uploads/2013/07/CloneVM_sysprep-error.jpg)
If you find that you have one or both of these issues,
![Vmware No Supported Hardware Versions Among Fix Vmware No Supported Hardware Versions Among Fix](https://appuals.com/wp-content/uploads/2019/04/error-message.jpg)
- attaching the USB 2.0 or the USB 3.0 controller or both controllers to your ESXi 6.5.x VM doesn't allow proper function of attached USB devices, using vSphere Client to attach the controller then the host's USB sound device to the VM, on Windows Device Manager, the display continually shows sound devices appearing and reappearing
- your Anywhere USB/2 device doesn't maintain connection to your keyboard and mouse properly, requiring you to RDP in remotely to get to Windows Device Manager, System devices, then right click on
Network Attached USB Enumerator
to disable then re-enable it
good news, the workaround is easy to implement! It has kept things working smoothly for me for two months now. Flawless, skip-free sound in Spotify from my VM for example, even when the physical server is under heavy loads from other VMs. Just follow along with the one-line esxcli command to disable the vmkusb driver, as is also documented by VMware here:
The sound workaround
- Open an SSH session (eg. PuTTY) to your ESXi 6.5.x
server (if you forgot to enable SSH, here's how) - Turn on maintenance mode, or ensure you've
set your ESXi host to automatically gracefully shutdown all VMs upon host reboot, or shutdown all the
VMs gracefully that you care about, including VCSA. - Disable the vmkusb driver - Paste the one line below into your SSH session, then press enter:
esxcli system module set -m=vmkusb -e=FALSE
- Check that it worked - Paste the one line below into your
SSH session, then press enter:esxcli system module list | grep vmkusb
It should indicate 'false false', as pictured at right. - Reboot your ESXi
host - Paste the one line below into into your SSH session, then press enter:reboot
Keep in mind you may need to redo this fix after any future upgrades to later ESXi versions.
Jun 20 2017 Update
Excellent comments left by Vic T below:
Nice write-up, as always. Your site has always given me inspiration and keeping me up-to-date with what's possible in my home lab - a small-chassis x10sri-f on xeon e5 L v4, and a sys-e200-8d 'frankensteined' with a 60mm fan to reduce the stock fan noise.
Just wanted to share what I have with regard to GPU and USB3 isochronous, FWIW.
On GPU, I managed to find an older Grid K2 card which has 2 GPUs on board - I passed through one of the GPUs to a VM for demanding tasks, and the other GPU can still accelerate other VMs vSGA (via VMware tools' 3d acceleration via Xorg on host) for lower requirements with the added advantage of being vMotion-able. The Grid K2 requires good cooling, so I ended up having to add a few more fans and so far the noise has been bearable. As opposed to the newer Grid, the K2 doesn't require the newer Nvidia software licensing which can get very expensive.
On the USB, I've tried 3 USB-to-IP devices (yeah, part of work eval to passthrough USB-to-serial console and Rainbow tokenkeys): Digi's AnywhereUSB, SEH's UTN2500 and the Silex DS600. The AnywhereUSB is USB2.0 only and doesn't support isochronous and had driver issues. So far I've been having good results with SEH and Silex, both support isochronous and managed to run a USB-based DVD drive successfully.
Jun 24 2017 Update
Testing and using the Silex DS-600 Gigabit USB 3.0 High Throughput Device Server is going well so far, stay tuned for a separate article about it.
The DS-600 is available on Amazon, with a funny typo in the product name, 'Gigbie USB 3.0 Device Server.'
Jul 29 2017 Update
VMware vSphere 6.5 Update 1 has arrived, and it turns out it has a new driver that doesn't exhibit the same issues with the that the earlier 6.5.x releases did. In other words, it just works, just like the 6.0 version did, this is good! This article is now obsolete, this is a good thing, less hassle for the few of us that tinker with USB sounds in VMs.
Oct 01 2018 Update
In ESXi 6.7, it seems that by default, these are how the vmkusb driver status appears.
See also at TinkerTry
- Digi AnywhereUSB/2 reliably attaches my keyboard and mouse to Windows 10 VM on a VMware ESXi SuperServer that is also my primary workstation
Oct 02 2015
See also
Suddenly, the 12 core Supermicro SuperServer isn't looking very pricey, even when fully loaded with 128GB of RAM!
- Apple unleashes 18-core iMac Pro with 128GB RAM, bumps other Macs to Kaby Lake
The biggest surprise was that Apple announced a new 'space gray' iMac Pro that can be configured with up to an 18-core Intel Xeon CPU, 128GB of RAM, and a 4TB SSD drive. Keep in mind that the base model of this beast will feature an 8-core Xeon, 32GB of RAM, and a 1TB SSD and it will cost $4999. So, the price of the fully configured version is going to be astronomical, likely in the $8K-$10K range, when it arrives at 'the end of the year.'
This excellent article details a different approach that leverages ESXi 6.0 and USB 2.0 passthrough:
- Running a virtual gaming rig using a Xeon D server, a GFX 750Ti, PCI passthrough and a Windows 10 VM
Nov 19 2016 by Joep Piscaer at Virtual Lifestyle
At the beginning of the year we performed an upgrade of our vSphere environment from vSphere 5.0 to vSphere 5.1 U1 Build 1063329 compromised of about a dozen ESXi hosts and a vCenter instance hosted on Windows Server 2008 R2 SP1. One of the outstanding issues from this project is the upgrade of Virtual Hardware for Virtual Machines.
I'm having trouble understanding why I should go to work and downtime to upgrade the Virtual Hardware version on all of our VMs. Our newly created Virtual Machines are using Virtual Hardware v. 9, the most recent supported version in vSphere 5.1 U1 which resolves issues we were having with Windows Server 2012 R2 and WinPE 4.0 on our older vSphere 5.0 instance. All of our older Virtual Machines are compatible Virtual Hardware versions (KB2007240) so we are not forced to upgrade their hardware version.
Am I missing some technical reason for upgrading all our Virtual Machine's Virtual Hardware to the 'newest' Version 9 since guest operating system and ESXi compatibility are not issues? Upgrading the Virtual Hardware is not necessarily trivial since I have to shutdown the VM, take a snapshot or backup of it and then upgrade it for a few hundred VMs. Other than avoiding having to do this in the future and getting warm fuzzies that all our VMs are running on the most recent Virtual Hardware version why should I bother doing a straight cutover instead of a rolling upgrade as we replace our Virtual Machines?
1 Answer
In general, virtual hardware versions introduce new functionality, extend limits and may have performance implications. See the VMware hardware version matrix.
Don't worry about this for the revision of vSphere you're on now. You can run all day on old versions, based on the setup you have. VM hardware version 8 sounds like the best choice for your specific situation.
The only real consideration with regard to virtual hardware versions is the move from version 8 or vmx-09 to the vmx-10 introduced in vSphere 5.5. There are manageability implications of this move. But on the positive, that process is streamlined through the vSphere Web Client, which allows you schedule the VM version upgrade during guest reboot.