USB Controller Passthrough with VMWare ESXi 5.1

Earlier last year I built myself a VMWare ESXi whitebox computer.  VMWare ESXi is a light operating system which allows multiple virtual computers (referred to as virtual machines or VM) to be run inside of one computer (called the host) at the same time.  For example, I usually have three VMs running on my box including a FreeNAS file server, Ubuntu, and Windows 8.

One of the features of ESXi (and other hypervisors) is that you can pass through physical devices such as a video card and USB devices into the VMs.  That way, you could interact with one of the VMs running inside the host, with a monitor and physical devices much like a real computer.  This is great because you can use the host like a real computer, while running other operating systems on it at the same time.

Simplified virtualized computer diagrams
A simplified diagram showing how hardware can be passed through to virtual machines through the hypervisor.

This setup worked well with ESXi 5.0, as long as you had chosen the hardware that supports device passthrough — see my original post for the hardware I am using.  As far as I know, any update and patches in the ESXi 5.0 series have working device passthrough.

However, with ESXi 5.1, USB controller passthrough has been broken.  On the majority of builds, when you select a USB controller for passthrough, the selection will vanish once you reboot.  Or even worse, it will randomly crash the hypervisor.

The only patch of ESXi 5.1 that seems to allow some sort of USB controller passthrough is build 1021289, corresponding to ESXi510-201303001. You can find this patch on the VMWare patch portal, and I have some notes in my previous blog post about updating ESXi.  The catch is that the USB controllers will schedule to disable passthrough for themselves upon the next reboot.

When you enable passthrough devices in the configuration, they will work after you reboot. However, they will be configured to disable themselves after the subsequent reboot.

This wasn’t really a problem for me because I rarely reboot the host machine.  Just remember before you shutdown or reboot the host, re-enable the passthrough devices in the DirectPath I/O Configuration screen, and they will work the next time ESXi boots up.

So in short, for reliable device passthrough in VMWare ESXi, stick with the 5.0 series.  If you have to upgrade to ESXi 5.1, install the ESXi510-201303001 patch, and remember to re-enable the passthrough devices before rebooting the host.  Keep track of this thread on the VMWare Community, as it has been a long running thread documenting issues with device passthrough on ESXi 5.1.

Updating VMware ESXi

Back in January I built a VMware ESXi 5 whitebox as my home server.  I updated the hypervisor today and I thought I’d record the process so that I can refer back to it later.  The blog post I found most useful was from VMware Front Experience.  If you’re looking for the detailed procedures, I’d suggest you look at that post.

Upgrading from 5.0 to 5.1

  1. The upgrade file can be found here on the VMware download site. For an upgrade from 5.0 to 5.1, the file to download is:
  2. After downloading the file, scp it to the ESXi host, onto one of the data stores.
  3. SSH into the ESXi host, and run the command:
    esxcli software profile install -d /vmfs/volumes/datastore1/ -p ESXi-5.1.0-799733-standard
    You can also run esxcli software profile update .... The difference is described in the blog post I referenced above.
  4. When the update completes, reboot the server. When you bring up the VMs again the first time, vSphere Client might ask you whether you moved or copied the VMs since the UUID changed. Select “I moved the VMs”.

Rolling back to ESXi 5.0

ESXi 5.1 wasn’t working too well for me. I was having problems passing through my USB controllers to the VMs. I decided to roll back to 5.0, and luckily VMware makes rolling back easy.

  1. When you reboot the host, press SHIFT+R when the hypervisor first boots up (you’ll see the cue at the bottom right of the screen
  2. Type ‘y’ to confirm rolling back the hypervisor
  3. The hypervisor will boot up with the old version.

Patching 5.0

So what I ended up doing was just patching the hypervisor to the latest build.

  1. The latest patches can be found on the VMware patch download portal.
  2. After downloading the file, scp it to the ESXi host, onto one of the data stores.
  3. SSH into the ESXi host, and run the command:
  4. esxcli software vib install -d "/vmfs/volumes/datastore1/patches/"
  5. When the update completes, reboot the host if required.

I apologize if this blog post is a little terse, it is mainly a reference for myself. If you want further information, please check out the pages below:

MyBB Security

These are just my thoughts about MyBB security updates.  I’m not a security expert of any sort, but I just offer my opinion based on the knowledge I have.
Over the last few weeks there have been two releases to MyBB to patch potential security vulnerabilities that have been discovered by various parties. I have seen some people who have found these seemingly miniscule updates too trivial to apply to their own boards, despite the fact that I and various other members of the MyBB staff have recommended these updates.

These people seem to believe that just because no harm has been done by people attempting to exploit the vulnerability, or just because no harm has been done when they try the exploit script by themselves, that the upgrade is not required. Personally I find this absurd.

First of all, I’d like to point out that not all proof-of-concept scripts are harmful; as their name suggests, these scripts prove the concept, but may not actually compromise the system. Wikipedia says: “In both computer security and encryption, proof of concept refers to a demonstration that in principle shows how a system may be protected or compromized, without the necessity of building a complete working vehicle for that purpose.”

Just because a board administrator cannot find a way to exploit the vulnerability, doesn’t mean that another malacious user won’t find a way. Just because nothing has been “done” to the board when an attempt has been made, doesn’t mean that eventually someone else won’t find a way to compromise the board. For example, the 1.1.3 release patched a serious security vulnerability where a malacious user could execute arbitrary PHP code at their own heart’s content (with a malaciously-formed username). As an administrator, you may not even detect any problems on the surface if you tried the proof-of-concept script, or seen usernames that have registered on your board, but nothing harmful has happened. In fact, much more serious and critical information may have been available to the hands of malacious users, if they indeed have compromised the board in this manner, and the patch released was not applied.

As well, once the security vulnerability has been patched, anyone with a malacious intent would be able to figure out how to exploit it, and may be able to compromise boards which have not patched the vulnerability.

Okay, so I may not be a security expert, however, I do use my common sense (and I do hope that you use yours). When a security vulnerability has been found, and has been identified to affect the particular version of MyBB (or any other software), we do not just release these patches to annoy our users with little upgrades every few weeks. No, we actually do want to improve our software by patching these holes and keeping our users safe. If a vulnerability has been reported, it is most likely that something harmful can be done to your board, and if a board administrator wishes to take that risk and not upgrade, it is his or her decision, and I cannot force anyone to apply the patch.
Obviously it is possible that sometimes the malacious users will compromise boards before we can find the vulnerability and release the patch, but I assure you that security is at the highest priority with the MyBB Group, and we strive to keep our customers safe from these exploits in as a timely manner as possible.

However, once we have released a patch, it is up to each and every individual board administrator to update their board to keep them and their board safe from the exploit. Each security patch, no matter how small, should be considered as significant. I hope that you all take this into mind the next time you ponder whether or not to update your board.

After writing all this about security, I hope I won’t get hit on my behind by something that I have just fervently preached. 🙂