One of the chief features of virtualization is abstraction of hardware. CPU, disk, memory, and networking are the focal resources because they are the only ones that all operating systems and applications require. Even on non-virtualized systems, these resources are shared. Many other hardware components are more challenging because they are not normally shared, even among separate applications. USB devices are among that latter group. USB storage device access is brokered by the operating system’s file system drivers, just like all storage devices, but most other USB devices expect that they’ll only communicate with one application at a time. That presents a special challenge in the world of virtualization.
Hyper-V Passthrough Support for USB Drives
Hyper-V can set up most USB disk drives in passthrough mode, but it does so via Windows’ storage subsystem, not by accessing the USB bus. For this reason, Windows must identify your USB drive as a “Mass Storage Device” in order for it to connect in passthrough mode. Other USB storage devices, such as “thumb drives”, will not work.
I would like to reiterate that I am fundamentally opposed to permanently mounting any disk in passthrough mode. However, this is a how-to article, so I will show you how to. If you have problems, expect all responses from me to be, “I told you so”. I do not have any USB drives to test this with, so my screenshots will not line up well, unfortunately.
Ensure that the disk is visible in Disk Management. Take it Offline. If the Offline option is not available, the disk cannot be used as passthrough.
In the target virtual machine’s properties dialog, click the virtual controller where you want to add your passthrough disk. Make sure that Hard Drive is selected on the right and click Add. Remember that you cannot add any drive to a virtual IDE controller while the virtual machine is turned on, but you can add a drive to a virtual SCSI controller if the VM is off or on.
Change the selection dot to Physical Hard Disk and then select the drive to attach from the drop-down. Click OK.
Hyper-V Cannot Passthrough Non-Disk USB
The most common question/complaint that I see regarding Hyper-V is that it cannot perform passthrough operations for USB devices. It is commonly (and negatively) compared to applications such as VMware Workstation and Oracle VirtualBox, which can perform USB passthrough with ease. The very sharp distinction to be made here is that Hyper-V is a type 1 hypervisor whereas all of the products that provide simple USB passthrough are type 2 hypervisors. In a type 2 hypervisor, the management operating system is installed directly to the hardware and the hypervisor is just another application that runs within it. Applications have the ability to exclusively capture a USB port to prevent other applications from using it if they like; this is why it’s so easily done in a type 2 hypervisor. If you’ve ever used a type 2 hypervisor in this way, you’ll notice that they explicitly tell you that the USB device can be attached to the parent� or a guest — there’s no sharing or divvying up resource access or anything of the sort.
Type 1 hypervisors are not applications. They are kernels, distinct from the kernels in the guest operating systems. A type 2 hypervisor is essentially an application shim that is pretending to provide a root hardware device, which is fine because it doesn’t require the same degree of isolation as a type 1 hypervisor. Hyper-V can’t do this because one operating system instance locking a USB port from all other operating system instances is just not how type 1 virtualization works. Could there be a way for a type 1 hypervisor to assign a USB port to a specific guest by doing the same thing that a type 2 does? I don’t know. In theory, it sounds like something that could be done, although it also seems like a dirty hack and a risk to partition isolation. But, technological feasibility is beside the point. Hyper-V doesn’t do it, at least as far as 2012 R2. If you want more information, Microsoft has published a thorough article regarding passing through hardware on the 2016 platform that describes some of the challenges and possibilities.
If true USB passthrough is a requirement for whatever you’ve got in mind, Hyper-V, even Client Hyper-V, is a poor solution. Personally, I don’t see the value in a type 1 hypervisor on the desktop so I only use Client Hyper-V enough to write about it. If you’re using the emulators in Visual Studio, you’re sort of forced into it. For most everyone else, I’d say to turn your eye to a type 2 hypervisor. I personally like VirtualBox. It’s not perfect by any stretch, but the licensing terms are favorable for most and it gets the job done.
All of that said, it is entirely possible to use USB devices inside a Hyper-V guest, even Client Hyper-V.
Method 1: Network-Based USB Solutions
First and foremost, Hyper-V is a server-based solution. Beyond that, Microsoft is wholeheartedly embracing cloud concepts, even (in my opinion) to the detriment of a great many other technologies. If you envision a cloud based on virtualization, even an on-premises cloud, you can see fairly quickly that host-based USB is a terrible idea. You never have any guarantee of any kind where a virtual machine will be running from moment to moment. With Shared Nothing Live Migration, even the lack of a cluster no longer locks a virtual machine to a specific host. Host-based USB just doesn’t make a lot of sense in a cloud.
If you need a USB device to be available in your virtualized environment, my very first recommendation is to find a network-based solution. Years ago, I used a product sold by Digi. This is not an endorsement per se because I only ever used the one device and have not used any of their current technology, but they’re still around so they must be doing something right. Remember that USB hubs match up with operating systems at a one-to-one ratio, so don’t go buying a device with a lot of ports and expect to be able to connect it to lots of virtual machines unless the manufacturer specifically says that the device allows for that.
Pros of network-based USB hubs:
Can remain connected to their assigned virtual machine no matter where it moves and whether or not anyone is logged in, provided network connectivity remains constant
Allows for concentration and management of networked USB devices in administrator-defined locations. For instance, you might purchase a rack shelf and use it to hold all of your network USB hubs, all connected to a switch provisioned just for connecting those devices.
Perfect solution for nuisance devices such as licensing dongles.
Widest range of host and guest operating system support.
Cons of network-based USB hubs:
1-to-1 ratio of hubs to virtual machines often means purchasing many empty USB slots
Gigabit Ethernet is much slower than USB 3+
Unless your wiring, addressing, routing, and firewall infrastructure allow for it, you may not be able to provide physical device access to end users
Drivers for the network-connected USB hub must be available for your guest operating system, as well as for the USB devices plugged into it
The guest must be connected to the network (could be a limiting factor for VMs that you wish to be isolated)
What I want to make most clear with this technique is that the virtual machine connects to the USB hub via TCP/IP. Hyper-V has no part in it beyond providing fundamental network connectivity via the virtual switch.
Method 2: Remote Desktop Protocol
Once a virtual machine has an operating system installed, it behaves very much like a physical machine. So, you can enable remote desktop connections in the System properties window:
Once that’s done, you can connect to it remotely just as you would any other Windows system.
To allow USB devices in an RDP session:
Run mstsc.exe at a Run/command prompt.
Click Show Options:
The dialog box will expand, exposing a number of tabs. Switch to the Local Resources tab and click the More button:
Another dialog will appear. Other devices that it detects will appear here, as will a checkbox for Other supported Plug and Play (PnP) devices. Check items as necessary.
Once you click OK and connect to an RDP session on any host, these options will be retained until you change them. There’s also a nifty tool called “Remote Desktop Connection Manager“. It’s kind of buggy and unstable, but its ability to retain many unique connection settings for remote hosts in a hierarchical tree makes it well worth the minor difficulties.
Pros of RDP-based USB connectivity:
Completely hypervisor independent.
Automatically works when RDP connectivity is enabled
Can be controlled and limited by group policy
Any user with a USB device attached to his or her desktop with RDP access to the virtual machine can use that device within the virtual machine
Cons of RDP-based USB Connectivity:
The device is only connected as long as the RDP session is connected
Drivers may need to be installed in the target virtual machine
This feature was originally designed with printers in mind; may not work with all devices
Connection speeds are commonly very slow
Because RDP is a requirement, only Windows operating systems are supported
You must have network connectivity between the system that is physically hosting the USB device and the guest operating system; TCP port 3389 must be opened on any firewalls
The best purpose for USB over RDP is for connecting devices from end-user computers. It’s not functionally different from the way that we’ve been connecting devices in remote sessions (usually Terminal Services) sessions for a very long time.
Method 3: Enhanced Session Mode USB Connectivity
The last method is the most reliable, but also has the most restrictions. Enhanced Session Mode was introduced with the 2012 version of Hyper-V and was included with Windows 8’s Client Hyper-V. This technology merges many of the session technologies of RDP into the VMConnect.exe application. If that application name isn’t ringing any bells, its a separate application invoked by Hyper-V Manager and Failover Cluster Manager when you use the Connect menu item.
You can also invoke it directly just by executing vmconnect.exe at a prompt (elevation is typically required).
How to Enable Enhanced Session Mode
Enhanced Session Mode is turned on by default for Client Hyper-V installations. For the server SKUs, you’ll need to manually enable it. Afterward, you’ll need to restart the Hyper-V Virtual Machine Management service (vmms). The quickest way is with PowerShell:
This cmdlet includes the -ComputerName parameter if you’re running it remotely.
If you’d rather use Hyper-V Manager:
Right-click on the host in the left pane. Click Hyper-V Settings.
In the left-side tabs, click Enhanced Session Mode Policy.
Check the box for Allow enhanced session mode and click OK.
It is not necessary to enable the Guest services integration service just to enable USB redirection.
How to set USB Options for Enhanced Session Mode
Because Enhanced Session Mode is based on RDP technology, you’ll see familiar settings. Follow these steps to setup USB redirection for a guest:
Upon connecting to a virtual machine that can support Enhanced Session Mode with vmconnect.exe, you’ll be shown the following dialog, where you’ll click Show Options:
Just as it does with mstsc.exe, this will cause the dialog to expand. Choose the Local Resources tab:
Click More. You’ll be presented with the following dialog:
Any USB devices that you have will appear under the Other supported Plug and Play (PnP) devices branch. You can check those, as well as the Devices that I plug in later box to cover any additional USB devices.
I didn’t show it, but there is a checkbox on the first screen after clicking Show Options that allows you to save these settings for the current virtual machine.
Enhanced Session Mode Notes
Enhanced Session Mode is the most reliable of the three options that I’ve presented, but it comes with a list of caveats
Pros of Enhanced Session Mode
Works across the VMBus, so it can be extremely fast. Still limited by network speed when vmconnect.exe is used against a remote host.
Works with Client Hyper-V
Does not require network connectivity directly to the guest, only to the host
Cons of Enhanced Session Mode
Same cons as the RDP option, listed above, with the exception of the item about network connectivity to the guest operating system
Requires Windows 8/Windows Server 2012 or later as the host and guest operating system (or Hyper-V Server 2012 or later as the host)
Windows/Hyper-V Server hosts must each be configured to allow Enhanced Session Mode against guests
Each guest must be configured per connecting user
If drivers are necessary, they’ll need to be loaded into the guest
VMConnect requires sufficient privileges against the host, not just the guest. With AzMan being deprecated in 2012 and removed in all later versions, that means at least Hyper-V Administrators membership unless you have access to System Center Virtual Machine Manager
Network connectivity between the system that is physically hosting the USB device and the Hyper-V host running the target guest; TCP port 2179 must be opened. If you’ve opted to leave your Hyper-V host out of the domain for whatever reason, there might be additional necessary steps.
Enhanced Session Mode is best used with Client Hyper-V, and is the closest that you’ll get to the capabilities found in type 2 hypervisors. Remember that it is based on RDP technology, therefore it is not truly “passing through” the USB device. You may find that some devices don’t work as well as they do with type 2 hypervisors; others may not work at all.