Client Hyper-V in Windows 10

Windows 8 introduced the first incarnation of Hyper-V for the desktop. It’s the same core hypervisor as the Hyper-V that ships with the server SKUs, minus a few features. Like its big brother on the server side, Windows 10 brings several new features to the desktop.

What is Client Hyper-V?

Client Hyper-V is an edition of Hyper-V that is geared toward desktop environments that could be thought of as “Hyper-V Lite”. It shares most of Hyper-V’s features and even brings some of its own. Highlights:

• Type 1 hypervisor: A type 1 hypervisor is a complete kernel and performs direct hardware control. This means that when you enable Hyper-V in Windows 10, the physical hardware boots to Client Hyper-V, not your root Windows 10 installation. Client Hyper-V then starts up your pre-existing root Windows 10 environment as the management operating system. A management operating system is known as the “root partition” or “partition 0” or the “parent partition” in other hypervisors’ terminologies. It is a virtual machine, but it also has the special ability to exert control over the hypervisor. Contrast this with type 2 hypervisors, which are applications that run inside a normal host operating system and do not have direct access to hardware nor any control over the management operating system. Almost all other desktop-oriented hypervisors are type 2.
• Guest interaction: Interoperability with guest operating systems is a crucial component for a desktop-oriented hypervisor. Client Hyper-V offers:
  • Sharing and mapping of most host hardware
  • Copy/paste of files from host-to-guest and vice versa (supported guests only)
  • Copy/paste of clipboard content from host-to-guest and vice versa (supported guests only)
• RemoteFX: Windows 10 brings support for some RemoteFX features into Client Hyper-V. Most importantly, the full functionality of your graphics adapter will be made available to guests for both 2D and 3D acceleration.
• Connected Standby: If your management operating system goes to sleep, your guests will be OK. When you resume, they will be exactly where they left off.
• Linux guests: Client Hyper-V directly supports the same guest operating systems that Hyper-V does. This does not necessarily exclude other Linux distributions, but your mileage may vary.
• Fully virtualized environment: That phrase could be taken to mean a great many things, but what I mostly intend to convey is that whether or not a specific operating system is directly supported as a guest does not indicate whether or not it will function. Hyper-V’s virtual machines are complete x86/AMD64 environments. If an operating system would otherwise run in that environment (most importantly, on your physical CPU’s architecture), then it will almost certainly operate under Hyper-V. Without direct support, however, it may run poorly.
• Secure environment: Client Hyper-V provides the same security offerings as Hyper-V:
  • Secure boot: If Client Hyper-V doesn’t recognize the boot signature in the guest operating system, it won’t start it. This provides solid protection against root kits.
  • Shielded VMs: The topic of Shielded VMs is very large and won’t be covered in detail in this article. Essentially, if you are concerned that someone copying the files of your virtual machine to their own local machine is of concern, you have options.
• Storage Live Migration: You can move a virtual machine from one physical storage location to another without taking it offline.
• Run VMs from remote storage: Your virtual machines can be stored locally, which is the most typical configuration. You can also run virtual machines from SMB and iSCSI storage.
• Full-screen support: You can run Client Hyper-V guests within a window, allow them to consume an entire screen, or have them consume all screens on a multi-monitor system. Unfortunately, there is no native way to use only a subset of screens in a multi-monitor setup.
• Nested virtualization: Need to test detailed environments on Client Hyper-V? No problem! As long as you’ve got sufficient hardware, you can run Hyper-V and Client Hyper-V within Hyper-V. The software does not impose any limitations on depth.
• Containers. Hyper-V Containers are also available with Client Hyper-V.
• Network Address Translation in the virtual switch. One place that Microsoft’s desktop hypervisor has consistently lagged behind the competition is its guest networking capabilities. One thing that it has sorely lacked is the ability to perform NAT operations for guests. That meant that you had to have an available IP address on the existing network for each Client Hyper-V guest. Client Hyper-V in Windows 10 will provide network address translation (NAT) services for its guests. This especially comes in handy when you’ve got a wireless adapter that just won’t work with the virtual switch.

What Features does Client Hyper-V Lack in Comparison to Hyper-V?

Most of the features that are “missing” in Client Hyper-V are not especially useful in a desktop-oriented hypervisor environment anyway.

• Live Migration and Shared Nothing Live Migration: Windows 10 can’t be clustered, so it’s only natural that Live Migration wouldn’t be supported. Shared Nothing Live Migration would have its uses, but it’s not available.
• Hyper-V Replica: Windows 10 can’t participate as a member in Hyper-V Replica. This particular feature is intended for server-side disaster recovery, so it makes sense that it’s not available in Client Hyper-V.
• Advanced networking functionality: The only advanced networking available for Client Hyper-V guests is NAT. There is no teaming in the host, not the standard LBFO configuration or switch-embedded teaming (SET).
• Advanced hardware functionality: virtual fiber channel and some SR-IOV features are not available. The hardware that these features apply to are almost never found in desktop-grade equipment.

Licensing and Client Hyper-V

We’ve produced extensive work around licensing and Hyper-V with articles, eBooks, and webinars. None of them have meaningfully touched on Client Hyper-V. Simply put, a Windows 10 license provides for exactly one instance, period. It does not contain any guest instance rights whatsoever. If you want to run a guest instance of Windows 10, then you must purchase another license to cover that instance. If you wish to run any Windows Server guests on Windows 10, you must license the hardware to cover those instances in accordance with the new per-core rules. Linux distributions will follow their distributors’ rules.

Uses for Client Hyper-V

The benefits of server virtualization are quite clear. They generally center around the fact that server hardware is typically underutilized. That’s usually not the case for client hardware. Desktop and laptop computers don’t usually have as many resources as server computers before you consider cutting them up. CPU is usually the only resource with significant capacity to spare, and even that doesn’t have much availability for some users. So, why would you want to split up limited resources on your desktop system? Here are a few reasons:

• Software development: Software developers have many reasons to use virtualization.
  • Sandbox environment: If you’re writing systems-level programs, it’s usually not a good idea to allow a bug to cripple the computer that you’re developing on. Checkpoints and kernel isolation alleviate this concern. I particularly like using virtual machines for developing Windows installer packages. Recent versions of Visual Studio rely on Client Hyper-V for testing mobile device applications.
  • Multi-OS targeting: Whatever version of Windows you’re running, almost no developers can guarantee that their users will have the same. Having virtual machines on your desktop allow you to quickly verify that your application runs the same on different operating systems and different bitnesses (32- vs. 64-bit).
• Systems administration: Systems administrators have many uses for virtualization on the desktop, even though many suffer in silence without realizing that there are solutions to many of their daily headaches.
  • Proper security levels. You know that you are supposed to run in a lowered security environment so that your administrative account isn’t signed in all of the time. You also know that it’s much easier to say than it is to do, especially since even some of Microsoft’s tools don’t work appropriately with Run As. Using virtualization on your desktop allows you to be signed in with multiple accounts simultaneously without the headaches of Run As.
  • User access testing. Another oft-overlooked usage is testing privilege levels for non-administrative accounts. For instance, you can create a test account with the same membership as one of your domain users to test that account’s ability to connect to certain resources. Run As can only take you so far. Logging into a virtual instance with alternative credentials without interrupting anything else that you’re doing is an invaluable capability.
  • Application testing. Software developers may test their software to some degree, but you need to know how it’s going to interact in your environment before pushing it out to your users.
• Security operations: A virtual machine provides a great many opportunities for information security workers:
  • Sandbox environment: If you’re not certain if something is malicious software, build an environment that it’s free to destroy. Virtual machines present a wonderful walled garden. You can place suspect material inside a VHDX, mark it read-only, then attach it to your checkpointed test virtual machine. If it turns out to be malicious, you can revert the checkpoint or just delete the virtual machine outright.
  • Penetration testing: Build a duplicate of your production environment inside Client Hyper-V instances and hack away. Obviously, there are cons as well as pros to testing against a duplicate of your production environment instead of the actual environment, but this is a good place to start.
  • Forensics labs: Most computer forensic tasks need to be performed on the impacted system(s), but sometimes you need a place to tear into a chunk of code or a data file. Virtual machines provide the perfect environment.
• Down-level environments: Windows 7 Pro and Enterprise shipped with “Windows XP Mode”, a pre-built Windows XP environment that ran under the built-in Virtual PC type 2 hypervisor. We lost that free virtualized instance along with Virtual PC in Windows 8, but Client Hyper-V still provides the base capability to run down-level operating systems. Unfortunately, Windows XP isn’t on the supported list for Client Hyper-V in Windows 10, but it does work (slowly). Between the defunct Windows XP and the current Windows 10 are four versions of Microsoft’s desktop operating system. There are any number of reasons that you might need one of those environments, at least on a part-time or temporary basis. Client Hyper-V might be exactly what you need.
• Demonstrations: If you need to demonstrate software or software environments and your simple laptop instance isn’t adequate, you can build very complex structures within Client Hyper-V for use on the road.

Client Hyper-V Requirements

With Windows 10, Client Hyper-V and the server-based Hyper-V have the same hardware requirements. Client Hyper-V is not available in every Windows 10 SKU.

• Windows 10 Professional, Enterprise, or Education editions. Windows 10 Home edition does not contain Hyper-V, nor do any of the various mobile SKUs.
• Hardware-assisted virtualization. Intel calls it “VT-x”, AMD calls it “AMD-V”. Most BIOSs usually just have a simple option to enable virtualization features. This technology has been commonplace for long enough that most functional systems will support it.
• Data execution prevention. An old malware technique involves placing malicious code into a data segment and then directing the CPU to execute it. Data execution prevention forces the system to rigidly respect data segments as not being executable. Intel calls theirs “XD” and AMD calls theirs “NX”. Microsoft unifies them as “DEP”. BIOSs will have various labels that are generally easy to identify. This technology also enough years to be ubiquitous. It’s also typically enabled by default, so you can almost always simply expect it to be present.
• 4GB of memory. I’m not certain if there is a hard check in place for this condition, but your experience would likely be fairly miserable if you’ve got less.
• VM Monitor Mode extensions. Intel names theirs “VT-c”. I don’t believe that AMD has any particular name for it. This is a new requirement over Client Hyper-V in Windows 8.x. Even though the name is somewhat foreign to many people, you usually won’t have difficulty providing it. It’s not quite as common as DEP and hardware-assisted virtualization, though. If Client Hyper-V won’t run on your system, this might be why.
• Second-level Address Translation. Second-level Address Translation (SLAT) has been commonplace on CPUs for several generations. It has always been a requirement for Client Hyper-V. It is an always-on native feature of CPUs and there is no activity to enable or disable it. Check your CPU’s specification sheet to determine if it has SLAT support.
• (For nested virtualization) Intel VT-x and EPT technology. I don’t know the technical (or perhaps political) details, but AMD users are not welcome in Hyper-V’s nested virtualization world. You need an Intel chip with these technologies available and enabled.

You can quickly and easily verify if you can run Hyper-V on your current system by opening an elevated command or PowerShell prompt and running systeminfo . Look toward the end of the output for the following section:

System Info Hyper-V Check

Enabling Client Hyper-V

Client Hyper-V ships as a Windows 10 component, so you don’t “install” it, per se. You enable it.

1. Right-click on the Start button (or press Win+[X]) and select Programs and Features.
   

   WinX Menu

    

2. In the Programs and Features window, click Turn Windows features on or off. If UAC is on, you’ll need to confirm switching to administrative mode.
   

   Programs and Features

    

3. Choose the Hyper-V options that best suit your intent. The only required item is Hyper-V Hypervisor but it will be difficult to do anything with if you don’t enable the other components as well.  This article isn’t going to discuss Containers, but those are enabled here as well, as shown in the screenshot.
   

   Client Hyper-V Features

    

4. After clicking OK, you’ll need to restart the computer.

Fewer steps are required to enable Client Hyper-V in PowerShell. In an elevated prompt:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All

If you’re looking to install a subset of the components from within PowerShell, our earlier article has greater detail.

Using Client Hyper-V

I want to reiterate that, as a type 1 hypervisor, Client Hyper-V is always running. You do not need to start the hypervisor and there is no service that you can go look at or start or stop. There is the Hyper-V Virtual Machine Management service (VMMS.exe), but, as its name explicitly states, it is a management service. Without it, you as the administrator cannot interact with Client Hyper-V, but it is still there and doing its job.

Management Tools

There are three built-in tools that you’ll use to interact with Client Hyper-V:

• PowerShell. PowerShell is the most thorough way to manage with Hyper-V. You can start it within an elevated standard command prompt by typing PowerShell and pressing [Enter]. I tend to dig it out of the Start menu and pin it to the taskbar.
• Hyper-V Manager. Hyper-V Manager is not as robust as PowerShell for management, but it is adequate. It is also helpful for connecting to virtual machines’ consoles. Hyper-V Manager can be found in Administrative Tools. I tend to pin this to the Start menu. You must Run As Administrator if you are logged in with a non-administrative account.
• Virtual Machine Connection. This tool can be invoked within Hyper-V Manager by right-clicking on a virtual machine and clicking Connect. You can also enter vmconnect into any elevated prompt (including the Cortana local search). You will need to Run As Administrator. Once it opens, you can pick the virtual machine that you want to connect to from the drop-down.

It’s worth reiterating that you must always interact with Hyper-V using elevated prompts or graphical applications opened with Run As Administrator. VMConnect is kind enough to tell you when you don’t have sufficient permissions, but most other tools will be silent. For instance, running Get-VM as a non-administrator will simply return nothing, even when virtual machines are present and operational. Hyper-V Manager’s virtual machine list will also be empty.

Configuring Client Hyper-V

I’m not going to take you through every option available for Client Hyper-V, but I’m going to touch on the biggest points. Client Hyper-V works perfectly well immediately after you enable it and reboot, so it’s really just a matter of putting a few final touches on it.

To get started, open up Hyper-V Manager. In Windows versions past, you could simply open the Start menu and start typing “Hyper-V Manager” and after a few keystrokes, the built-in search tool would find it. This still works for most people, but many have encountered a bug where Cortana struggles to find things on the local computer. That went away for me after a few updates but the suggestions that I found to fix it directly did not work for me. If you find the “Windows Administrative Tools” group in the Start menu, Hyper-V Manager is there. I suggest pinning it to the Start menu or something similar so that you can easily reach it later.

Once you have Hyper-V Manager open, it should already have your local computer selected. Right-click on it and click Hyper-V Settings. If that option isn’t available, you didn’t Run as administrator.

A screenshot of the window that you’ll see is below. I’ve changed it to the Physical GPU tab so that you can see that RemoteFX is functioning and has automatically selected the video adapter. Sift through the other tabs and check that items are set as you expect. Feel free to change things as suit your needs. I would recommend keeping Enhanced Session Mode enabled everywhere you find it, or you’ll lose some host/guest interaction capabilities with your virtual machines. If you’re not certain about a setting, the best thing to do is leave it alone.

Basic Configuration

Once you’re finished there, right-click on the local computer again and click Virtual Switch Manager. Make certain that, on the right side, the selected type is External and click Create Virtual Switch.

Starting Virtual Switch Manager

Set the following options on the new virtual switch page:

• Name the virtual switch. There is no need to get fancy with this. Use something that you can remember and that you can type. Future you will thank you.
• Next to the External network dot, choose the physical network adapter that will host the virtual switch. You may need to look in your network adapter list if it’s not obvious which is which.
• Unless you have multiple virtual network adapters, leave Allow management operating system to share this network adapter. If you don’t, the physical adapter that you choose will be able to connect virtual machines to the physical network, but you’ll have to manually create a virtual NIC for the management operating system (that’s the Windows 10 installation that’s running Client Hyper-V) to continue using the physical network (or come back in here and check the box).
• If your management operating system currently participates in a VLAN, check the Enable virtual LAN identification for the management operating system and enter the necessary VLAN ID in the text box. If you’re at home using regular home networking equipment, you’ll definitely want to skip this box. If you’re connected to commercial-grade equipment at work and don’t already know what to do, it’s highly likely that you will skip this configuration. Otherwise, talk to your network administrator.

Virtual Switch Manager

When you’re done with setting up the virtual switch and you OK out, you might lose connectivity for a few moments while the networking settles down. It needs to recreate your networking stack on a new virtual adapter, so expect that to take a bit of time.

If you connected to a wireless network adapter, you might face some difficulties. You wouldn’t be the first. I do not personally have much expertise in addressing these problems but your odds of finding suitable resolution are not great. Usually, it either works in the beginning or it never works at all. You can try updating drivers. If you just can’t get it to work, never fear! You can follow the steps in the next section to create a NAT network so that you don’t need a virtual switch on top of the physical adapter.

Configuring NAT Networking in Client Hyper-V

This process has changed several times since the feature was introduced in a technical preview of Client Hyper-V and a lot of the currently available instructions are wrong. Even Get-Help for New-VMSwitch shows options that don’t work. The following instructions were tested and known good for Client Hyper-V on Windows 10 build 14393.447 (run “winver” from the Start menu).

As with many things in Windows, there is more than one way to make this all happen. There is only a single step that absolutely requires PowerShell, which means that I’m going to counsel you to do the whole thing in PowerShell. You can do all the other steps in the GUI if you prefer. So, I’ll start with a basic outline of the steps, then I’ll show you the PowerShell that can make it happen:

1. Determine what network range you want your NAT network to be. You only get a single NAT network on a Client Hyper-V system.
2. Create an internal virtual switch.
3. On the management operating system’s adapter for the internal virtual switch from step 2, assign an IP that will function as the router IP on that network that you thought up in step 1.
4. Create the NAT network (PowerShell only).
5. Attach virtual machine(s) to the virtual switch that you created in step 2 on the network that you created in step 1 using the IP that you assigned in step 3 as the router.
6. Assign IPs from within the guest operating systems.

Be mindful of step 6. Client Hyper-V does not contain a DHCP server and will not distribute addresses for that NAT network. In case you were about to ask, no, Client Hyper-V does not support DHCP relay, either. You must either create a virtual machine running DHCP in that network or you must manually assign IPs. I’d go with the latter.

Here are steps 2-4 in PowerShell for the network 192.168.100.0/24 (192.168.100.1 through 192.168.100.254):

New-VMSwitch -SwitchName vSwitchNAT -SwitchType Internal
New-NetIPAddress -InterfaceAlias 'vEthernet (vSwitchNAT)' -IPAddress 192.168.100.1  -PrefixLength 24
New-NetNat -Name vSwitchNAT -InternalIPInterfaceAddressPrefix 192.168.100.0/24

The first line creates an internal virtual switch named “vSwitchNAT” (could be done in Hyper-V Manager, as you saw above). An internal switch allows the host operating system and guest operating systems to use the same virtual switch, which, by definition, means that a virtual adapter will be automatically created for the management operating system. When such a virtual adapter is automatically created, its name is always in the format of vEthernet (name of the virtual switch), so I know that this one will be named “vEthernet (vSwitchNAT)”. If you name your virtual switch differently, use that name on your second line. I have also decided to pick the first valid IP in the network that I created, hence the 192.168.100.1 (this could be done in network connections). Note that I do not give it any routing information, such as a default gateway. The third line creates the NAT network. It will see the adapter with IP 192.168.100.1 and automatically treat it is as the router for that network.

Now, I just need to connect virtual machines to it. On the properties for a virtual machine, I do exactly that:

Select NAT Switch

I finish up by accessing the guest’s networking and giving it an IP on that network and using the host management adapter as the default gateway:

NAT Client IPv4

NAT in Windows 10 has more capability than what I’ve shown you, but this should be enough for most. Start on the NAT PowerShell page for more information.

Continuing On…

There are a great many other things that I could show you, much more than would fit in a simple blog post. If this is your first time using Client Hyper-V, or any Hyper-V, spend some time kicking the tires. Begin by right-clicking your host in Hyper-V Manager and clicking New and Virtual Machine. The wizard should be easy enough to follow. Once your new VM is created, right-click on it and click Connect. That’s VMConnect. You’ll find the start and stop controls. You’re now on your way to being a Client Hyper-V guru!