October 2010

Many legacy programs still use USB license dongles to lock an application to a specific host. This kind of locking makes it difficult to virtualize the server hosting the locked application.

With vSphere 4.1, it is now fully supported to pass through USB to the ESX host, enabling you to plug the license dongle into your ESX host, and attached that to a virtual machine. The USB pass through even works when you vMotion the VM to another ESX host. The vSphere guide has a list of supported USB license key style dongles that have been validated.

However, there is one large caveat with this solution, and that is that if you need to take the ESX host down that is hosting the USB key, for example to do routine maintenance, or during an unplanned HA event, the VM will no longer be able to access the USB key.

This often means customer prefer to stick with the pre-vSphere 4.1 “tried and true” method of using a USB over IP adapter. This method while costing a couple hundred bucks has the advantage the VM still has access to the USB device at all times, assuming the network stays up.

USB over IP

Recently a customer needed to do some maintenance on the filer backing their centralized VMware swap datastore without taking downtime, this post will help other folks who face a similar issue.

As a refresher, the VMware .vswp file is used by ESX/ESXi to allow for memory overcommit, each running virtual machine (VM) has a .vswp file whose size is the virtual machine memory MINUS the memory reservation for the VM. The .vswp file is typically deleted when the VM is powered off, and re-created when the VM is powered on. The .vswp files can be configured to be in a centralized datastore, or to be stored alongside the associated VM (the default).

With that background, the issue for this customer was that with a centralized swap datastore, it wasn’t clear to them how to take the filer backing the swap datastore down without incurring downtime of a virtual machine to re-create the .vswp in the new location via a power VM power off/power on operation.

Luckily, the vswp file is also re-created when you do a VMotion to another host, or a Storage vMotion to another LUN. The simple solution was after changing the swap data store location from the current centralized location, to VMotion all VMs off of host A to other hosts, then back. Repeate for each host in the cluster. A quick PowerCLI script took care of the whole process.

When you are done, all .vswp files for running VMs will have been re-created at the new location. You can validate no VMs are using the old swap datastore, then remove it.