Using USB Pass-through in vSphere 4.1


Finally USB pass-through is possible on ESX hosts with the new vSphere 4.1 release! This feature ha been available in VMware Workstation/Fusion and Player for quite a while. The freshly added feature in vSphere 4.1 even works if you vMotion the guest from one host to another, which is in itself pretty amazing functionality!

In this post, I’ll show how to setup and use the new USB pass-through feature in vSphere 4.1.

Setting up USB pass-through in vSphere 4.1

First off, we need to add an USB controller to the VM we want the USB pass-through working on. This is done by firing up the vSphere Center Client and right-clicking the VM. Then select Edit Settings

Click on Add and find USB Controller from the list then click Next

Click Next and you’ll be presented with a list of the currently host-connected available USB devices. If none show up, make sure it’s actually connected to the host. If your device is indeed connected, but still not listed in the vSphere Center Client it’s not supported.

In my test setup I have a small APC UPS connected to the host, so I’ll add that to the VM. Also note that this is where you enable vMotion support! Find your device, and click on Next

Review your changes and click on Finish

This will return you to the Edit Settings window. Click on Ok to have the USB controller and device(s) added to your VM.

Connect to your VM and install the drivers, if needed, and you should be able to use your USB device directly inside the VM.

Usage Scenarios

What could you possibly use this new feature to accomplish? Well, for one you could use it to connect your UPS to your management software, without having to install any management software on the host itself. In general I would recommend using UPS vendors that offer direct vCenter integration instead, but for a lab environment this should work out nicely.

Another obvious usage pattern would be to connect USB dongles that some software require, either for security or for licensing purposes.

The one thing that springs to my mind, and one that would probably be the most useful in my environment, is to connect USB HDDs to the host and use those as a backup target for Veeam Backup and Recovery. Being able to directly connect some cheap storage to the host and then connecting it directly into the Veeam Backup and Recovery VM makes it easy to backup/replicate your VMs for manual off-site storage. Kendrick Coleman (kendrickcoleman.com) had the same idea, but unlike him I’ll try to make sure my HDDs are located off-site before the fire starts! :-)

I’m sure that there are other usage scenarios as well, like connecting scanners, cameras and whatnot, I’m just not sure I’d like all sorts of devices connected to my hosts.

Scheduling vCenter Backups

If you run your vCenter on SQL Server Express 2005, you are missing the ability to set up scheduled backup jobs with SQL Maintenance Plans, a feature available in the full version of SQL Server.

This might not be a problem if your backup software has SQL Server agents that you use to backup your vCenter databaser, but in smaller environments or even in your lab, you might not have that kind of backup scheme available to you, so what do you do? Thankfully there are ways of setting up the same kind of scheduled backups in SQL Server Express, without being a SQL Server Guru.

Creating a Backup Script

If you don’t have SQL Server Management Studio Express installed already, download and install it now.
Fire it up and log on with a user that has sufficient permissions to access the vCenter database

Find your vCenter database by expanding Databases and select VIM_VCDB

Right click on VIM_VCDB and select Tasks and then Back Up…

This opens the Back Up Database window, where you set your backup options. Set your options in a manner that fits your environment. You can set options like the backup file location, retention policy etc.

So far, this is all fine and dandy. You can create a manual backup this way, without much hassle. How can we turn that into a scheduled job?
The first bit is to turn your backup options into a SQL script that can be scheduled. You do this by finding the Script drop-down menu on the top of the Backup Database window. Select Script Action to New Query Window.

This opens the script window, where you can see the script and test it to make sure it works as intended.

The next step is to save the generated script, you do so my going to File and select Save … As. I’ve created a folder called c:\scripts\ that I use to store my SQL scripts in, so I’ll save the backup script there as FullBackupVCDB.sql.

Scheduling the Backup Script

Now that we have a working backup script, we need to be able to schedule it to run. As we can’t do that within the SQL Server Management Studio Express application, we need to find another way of scheduling it. Windows Server 2008 R2 (and other versions) include a scheduling tool, and that’s what we’ll use to create our schedule.

On my standard vCenter installation, the SQL Server is installed in the default location of C:\Program Files (x86)\Microsoft SQL Server\. This means that the actual command we need to schedule will be (be sure to replace the server-/instance-name and script name if your values differ from mine):

“C:\Program Files (x86)\Microsoft SQL Server\90\Tools\Binn\SQLCMD.EXE” -S [servername]\SQLEXP_VIM -i c:\scripts\FullBackupVCDB.sql

Go to the Control Panel and select Schedule Tasks. Click Create Basic Task, give it a name and set an appropriate schedule.

Select Start a program as the action for the task, and when it asks for Program/Script enter “C:\Program Files (x86)\Microsoft SQL Server\90\Tools\Binn\SQLCMD.EXE” -S [servername]\SQLEXP_VIM -i c:\scripts\FullBackupVCDB.sql.

Click next and check the box that says Open the Properties dialog for this task when I click Finish then click Finish. In the VCDB Backup properties, make sure the Run whether user is logged on or not option is selected, to make sure the schedule runs as planned.

Once you have verified that the schedule works as intended, make sure that you include the location for your vCenter database in your regular backup scheme, and you should we a lot safer than you were.

That’s it! Scheduled vCenter backups on SQL Server Express 2005.

Thanks to Chris Dearden over at J.F.V.I who helped me out with getting my sqlcmd.exe syntax corrected for the scheduled task!

Migrating your vCenter from 32bit to 64bit

As you may or may not know, the new vCenter 4.1 requires that the host it runs on is 64 bit. As 4.0 and previous versions weren’t supported on 64 bit at all, this probably means that when you upgrade you will need to move your existing database to a new host.

There are several ways of doing the migration, but one way is to backup your existing database, and restore it on a new host and point the new vCenter 4.1 installation to the existing database and have it upgrade it for you during install.

I’m sure that you would like to automate that process, just to limit the possibility of manual screw ups, right? Thankfully, VMware had the same idea.

In chapter 5 of the vSphere Upgrade Guide, VMware outlines the different methods you can use when migrating your vCenter database, and on page 39 a data migration tool makes it’s appearance.

This two step process takes a backup of your existing vCenter SQL Server Express database and dumps it to a predefined local folder. You then copy the entire migration tool folder to the new host and run the second part of the tool to install vCenter 4.1 and import the old database.

I used this tool to migrate our setup, from Windows Server 2003 32bit to Windows Server 2008 R2 64bit without problems.

The only thing you need to be aware of is that VMware Update Manager is still a 32bit application and requires that you manually create a 32bit DSN to the database. This is mentioned in the VUM Installation and Administration Guide, but it is not mentioned in the vSphere Upgrade Guide.

All in all, this tool is a great assistant for all of you that need to migrate to a new host for 64bit support in vCenter Server 4.1. While it could be more polished, brand a GUI and let you use network storage for the backups, it does the job at hand very well. After all, who needs a polished GUI based application for a one off job like this?

Related VMware Knowledgebase Articles