VMWare USB Passthrough from Host to VM

As part of a recent push from work, we have been trying to virtualise systems that belong to other departments, primarily to increase redundancy and all the great things that visualisation brings.

But what happens when you are told that something “Can’t be virtualised”. I recently encountered this twice with two popular Building Automation System (BAS) Vendors.

One was a simple-ish case of “it needs local serial connection to the controller” whereby a simple but high quality MOXA P5150A would solve the issue, not only does it do a range of configuration types, but its also powered by PoE, which inturn is UPS backed from our Cisco 3750’s.

The other one used a USB key into a Dell Workstation, which was used to hold the identity and license for the site. This was a little more challenging as it was not made clear that this was the case until i had already run the P2V using VMWare Converter Standalone. It was when i was removing the old physical hardware from where it was that i noticed the key sitting in the back.

Upon doing some googling and digging i found that a USB key could be passed from a workstation running VI Client to a VM, but this would not provide a permanent connection, nor a suitable outcome for the customer. What i did find is that if the USB is inserted into the host ESXi server (Ours are running 5.5 Update 2 with Critical Patches) and reboot the host which the USB is connected to and the guest will be running on, you could “add hardware” and directly map the USB from the host hardware through to the VM.

It worked a treat, upon doing this and a subsequent reboot of the VM to clear the error with the BAS Software, it worked like it was on Physical.

Some docs that i found really useful stem from the below link,
VMWware Pubs – USB Passthrough

It was really important to us that we manage to virtualise these systems, and thankfully VMWare and the broad range of tools available were able to complete it and deliver a faster outcome than the Windows-on-Hardware approach. More to come on this topic in a future blog about when is a VM faster than Local Hardware.

Too many time sources – Isilon

So as many Aussies know, we have 2 time shifts each year for daylight savings, being the first Sunday in April (clocks back 1 hour), and first Sunday in October (clocks forward 1 hour)

Sunday evening I received an alert from my Isilon cluster saying that the time had drifted by more than 4 minutes from the AD time and Auth would be affected. 

Sure enough, it had, any CIFS/SMB access was problematic, but NFS was unphased.  

After a discussion with EMC support it was determined that there were too many time sources on the cluster. Being that both NTP and SMBTime. SMBTime is a service that pulls time from an Active-Directory, and NTP being Network Time Protocol.

In our setup both eventually point to the same time source. But it became apparent the two services don’t have a precedence order between themselves, and just end up in a race condition. 

EMC support were excellent in assisting me to diagnose the issue and provide recommendations to remediate the system.

On EMC recommendation we disabled the SMBTime service and forced a re-sync so NTP would reset the clock. Once done it was all back to normal for data access and the alerts were cleared as a result. 

It has left me with questions as the system was setup by an Integrator/Partner, and left in a “unrecommended” setup

More to follow….