How to run Kali Linux on Client Hyper-V

How to run Kali Linux on Client Hyper-V

Personally, I find Microsoft’s recent moves to improve support for Linux and its overall relationship with open source to be very exciting. I’ve taken full advantage of these new opportunities to rekindle my love for the C and C++ languages and to explore Linux anew. Since my general line of work keeps me focused on the datacenter, I’ve similarly kept tight focus on server Linux builds and within the confines of Microsoft’s support matrix. Sure, I’ve had a good time learning other distributions and comparing them to what I knew. But, I also realize that I’ve been restricting myself to the safe walled garden of enterprise-style deployments. It’s time for something new. For my first step outside the walls, I’m going to take a crack at Kali Linux.

What is Kali Linux?

The Kali Linux project focuses on security. In most of the introductory literature, you’ll find many references to “penetration testing”. With a bit of searching, you’ll find a plethora of guides on using Kali to test the strength of your Windows computers.

The distribution itself is based on Debian. Truthfully, even though I’d like to tell you that we’re going to stray far, far away from the beaten path, we won’t. Almost no one picks up a copy of the Linux kernel and builds an all-new distribution around it. Nearly every maintained distribution connects somewhere into the general distribution categories on Microsoft’s list. Anything else falls under the category of a “source-based” distribution (like Gentoo). I’d need to drastically improve my Linux knowledge to help anyone with one of those.

Why use Kali Linux?

The distributions that I tend to cover in these articles fall best under the category of “general purpose”. In that respect, they have much in common with Windows and Windows Server. You stand up the operating system first, then install whatever applications and servers you need it to operate or provide. Web, DNS, storage, games — anything goes.

Kali Linux has a purpose. You could use it as a general purpose platform, if you want. That’s not an optimal use of the distribution, though. Kali is designed to probe the strength of your environment’s computer security. During install, there won’t be any screens asking you to pick the packages you want to install. You won’t get an opportunity to tick off boxes for LAMP or DNS servers. If you want those things, look at other distributions. Kalix Linux is here to pentest, not hand out IP addresses. Err… well… I guess rogue DHCP qualifies as security testing… But, you get the idea.

A natural question, then, is, “So, Eric, what do you know about pentesting?” The answer is: very little. Where I work, we have a security team. I can notify them when I build a new system, and they’ll test it and send me a report. I accept that I will never rise to expert level, if for no other reason than because I don’t have the time. Still, I should know more than I do. Many seasoned sysadmins would be surprised at how easily an attacker can break into a system set at defaults. Since the people behind the Kali Linux project have done all the work to make a convenient entry point, I’m going to take advantage of it. I recommend that you do the same.

Why Use Client Hyper-V for Kali Linux?

I won’t tell you why you should use a Microsoft hypervisor as opposed to some other hypervisor. I use Microsoft platforms and services for almost every aspect of my home and work computing, so my natural choice is to stick with it. If your story is different, then stay with what you know.

I will tell you that Client Hyper-V makes more sense than server Hyper-V. I’ll make an exception for those of you that run Windows Server as your primary desktop. That’s not a thing that I would do, but hey, no judgment here.

Why I use Kali Linux under Client Hyper-V:

  • Kali Linux is best used interactively with a desktop interface. If I were to run Kali from within my datacenter, I’d need to use VMConnect against a remote host. I’ve never liked that.
  • Most attacks won’t come from within the datacenter, so why would your primary penetration testing tool live there? Put it into a user network. Run it from a computer that can access your wired and wireless networks.
  • Hyper-V allows you to perform all sorts of spoofing quickly and easily. You can flip MACs and hop networks in moments. You can hide Kali behind NAT to fool many network access protection schemes and then, within seconds, drop it on the network alongside my host OS.
  • I don’t want to replace my primary desktop. I don’t necessarily need to use any hypervisor; I could just install Kali right to my desktop. I could stand up a second physical machine right next to me and use Kali on that. But, this is the sort of thing that hypervisors were built for; more computers in less space. I can keep my general purpose desktop and have the special-purpose Kali running happily together.

Downloading Kali Linux

As a side effect of having a specific purpose, Kali Linux does not provide many install flavors. Start at the Kali Linux homepage. Click the Downloads header at the top of the page. Behold — the list. It looks long, but there’s really not that much there. You’re mostly picking the bitness (most are 64-bit) and the user interface experience that suits you.

This article uses the standard 64-bit distribution of Kali Linux 2017.1. If you choose something else, your experience may be different.

Verifying the ISO File Hash

Since we’re talking security, let’s start by verifying our file. On the Kali download page, next to the file link, you’ll find its SHA256 hash:

Downloading kali linux images(source:, as of June 17th, 2017)

Use PowerShell to determine the hash:

You’ll get output that looks like the following:

kali linux with client hyper-v

If you’re OK with “good enough”, you can do a quick ‘n’ dirty eye scan — basically, just visually verify that the codes look more or less the same. Even minor changes to a file will throw off the hash substantially. But, it’s not impossible to have two files with a similar hash. And, since we’re talking security, trust no one.

In your PowerShell prompt, do exactly this:

  1. Ensure that you are at the beginning of a new command line; no text entered, just a prompt.
  2. Type a single quote mark: ‘
  3. Use the mouse to highlight the Hash output from the previous command. Press [Enter] to put it on the clipboard. Right-click to paste. That should place the code immediately after the single quote.
  4. Type another single quote mark to close off the file hash.
  5. Enter a space, then -match, then another space.
  6. Type another single quote mark to start a new string.
  7. Highlight the corresponding hash code on the Kali download page. Switch back to the PowerShell prompt and right-click to paste it.
  8. Type another single quote mark to close off the published hash.
  9. Press [Enter].

This is what you should see (with possibly different hash values):


If you get an error, check your input. If you get False, check your input. If the input is OK, then your file does not match the expected hash. Most likely, the download corrupted. Maybe somebody hijacked it. Either way, get another.

Installing Kali Linux as a Guest in Client Hyper-V

On to the good stuff!

Creating a Hyper-V Virtual Machine for Kali Linux

I do not mean for this article to be a tutorial on creating VMs in Client Hyper-V. I assume that you know how to create a virtual machine, attach an ISO to it, start it up, and connect to its console.

I have a script that I use to create Linux VMs. The more I use it, the more deficiencies I notice. I will someday make this script better. Here’s what I currently have:

This script creates a dynamically-expanding VHDX using a 1 megabyte block size, in accordance with Microsoft’s recommendation. A commenter on another of my Linux articles pointed out that the 1MB block size does not result in significant space savings on every Linux distribution. I have not tested the difference on Kali. It uses ext4, so I suspect that you’ll want the 1MB block size.

I used the script like this:

It was necessary to pre-create the target VHDX path. That’s one of the deficiencies in the script. It’s also necessary to turn off Secure Boot after creation.

During use, I learned that Kali wants so much more memory than 2GB. These memory numbers are somewhat laughable. Be prepared to turn them up. It does seem to run well enough at 2GB, but I’m thinking that 4GB would be a more reasonable average running expectancy.

Installing Kali Linux from ISO

In case you missed it from the previous section: disable Secure Boot. Hyper-V does not include Kali’s boot signature. I did enable TPM support for it, but I don’t yet even know if Kali will make use of it.

From here, I doubt that you really need much from me. Installation of Kali is very straightforward. It shares one annoyance with Ubuntu: it has an obnoxious number of input screens broken up by long file operations, rather than cohesive input gathering followed by completion operations.

An installation walkthrough:

  1. You’re given many options right from the start. I simply chose to Start installer:
    kali linux installNote that several errors regarding not being able to find anything on SDA will scroll by; don’t worry about them. That’s normal for an empty disk.
  2. Choose the installation language. I also want to draw attention to the Screenshot button; This appears on every page, so you can store install images for later retrieval:
    kali linux language
  3. Choose your location. Be aware that the options you see are determined by your language selection! The following two screenshots show the outcome of choosing English and French in step 2:
    English Choices

    English Choices

    French Options

    French Options

  4. Choose your keyboard layout:
    kali linux keyboard
  5. The installer will then load some files and perform basic network configuration. I noticed that it performed IP assignment from DHCP; I did not test to see what happens if it can’t reach a DHCP server.
  6. After the component load, provide a host name. It appears to automatically choose whatever name DHCP held for that IP last. Only provide the name, no domain.
    kali linux network
  7. Provide your domain name. You can invent one if you aren’t using a domain, but you must enter something.
  8. Enter a password for root. Even though it mentions user creation, you aren’t creating a standard user account like you would in other distributions.
    kali linux password
  9. Choose your time zone. Options will be selected based on your earlier region choices. Why it appears at this point of the installer, I certainly do not know.
  10. Choose how you want your disk to be laid out and formatted. I personally choose Guided – use entire disk because I’m not the biggest fan of LVM. Any of the first three choices are fine if you’re new and/or not especially picky.
  11. Confirm disk usage:
  12. Then confirm partition usage:
  13. Confirm disk usage:
  14. And again… (this installer needs a lot of polishing):
  15. Now, your formatting options will be applied and files will be copied. This will take a while and there will be more questions, so don’t go too far.
  16. Now you need to choose whether or not you’ll allow software to be downloaded from the Internet (or a specially configured mirror). If you choose no, you’ll need to manually supply packages or add a repository later.
  17. If you need to enter proxy information, do so now:
  18. You’ll have a few more minutes of configuration, then what appears to be a completion screen.
  19. There’s still more stuff to do, though:
  20. As soon as that part completes, the system will reboot and launch into your new Kali environment.

Getting Started with Kali

Here’s your login screen! Remember to use root, because you didn’t create a regular user:


And finally, your new desktop:


Post-Install Wrap-Up

I know that you’re anxious to start exploring this wonderful new environment, but we’ve got a bit of housekeeping to take care of first.

At the left, in the quick launch bar, hover over the second icon from the top. It should be a black square and the tool tip should say Terminal. Click it to launch a terminal window:


Since we’re running as root, the terminal will already be running with the highest privileges. You can tell by the # prompt as opposed to a > prompt.


Install Extra Hyper-V Services

The required Hyper-V components are already enabled. Let’s add the KVP, VSS, and file copy services. Enter:

This installs the file copy, KVP, and VSS services. Whether or not they start depends on whether or not the relevant services are enabled. The default Hyper-V setting enables all except Guest Services, so all except the file copy daemon should start automatically. Use service --status-all | grep hyperv to find out:


Change the Scheduler to NOOP

Linux has an I/O scheduler, but Hyper-V has an I/O scheduler. Turn off Linux’s for the best experience.
Edit the GRUB loader:

This will load the GRUB configuration file. Find the line that says:

Change it to:

Press [CTRL]+[X]. You’ll then need to press [Y] to save the changes, then [Enter] to indicate that you want to save the data back to the file you found it in. That will leave you back at the prompt.

And finally:

Exploring Kali Linux

You have now completed all of your installation and preparation work! It’s time to take Kali for a spin!

If I didn’t make this clear enough earlier, I’ll be crystal clear right now: I don’t know that much about penetration testing. I recognize many of the names of the tools in Kali, but the only one I have a meaningful level of experience with is Wireshark. So, don’t ask me what this stuff does. That’s why we have the Internet and search engines.

Let’s start with the boring things to get them out of the way. In the top right you’ll find some system status icons. Click and you’ll get the system menu:


  • Hyper-V doesn’t (yet?) enable audio out of Linux systems, so the volume slider does nothing.
  • Where my screenshot shows Wired Connected, you’ll find your network settings. Click it to expand the menu where you can access them.
  • Where my screenshot shows Proxy None, you can click to access your proxy settings.
  • Where my screenshot shows root, you can click for a Log Out option and a link to your logged on user’s account settings.
  • The wrench/screwdriver icon takes you to the system settings screen. It’s analogous to Windows’ Control Panel. I don’t think you’ll need me to explain those items, so I’ll just recommend that you create users aside from root if you intend to use this desktop for more than just pentesting.
  • The padlock icon locks the desktop. From a lock screen, just press [Enter] to get a login prompt.
  • The power button icon takes you to a cancel/restart/shutdown dialog.

Move left from the system area, and you’ll see a camera icon (it appears in the screenshot above). Click that, and you can record your screen.

Now, the fun stuff! In the top left, you’ll see Applications and Places menu items. Places includes some shortcuts to common file system locations; it’s sort of like the Quick Access section in Windows Explorer. I’ll leave that to you to play with. Click Applications. You’ll immediately see why Kali is not a garden-variety distribution:


The Usual Applications group gave me a chuckle. You’ll find all the things that you’d find on a “normal” distribution there.

You met the quick launch dash earlier, when you started the terminal. It sits at the left of the screen and contains everything marked as a favorite. It will also include icons for running applications. The nine-dot grid at the bottom opens up Kali/Gnome’s equivalent to Windows’ Start menu. From there, you can launch any item on your system. You can also add items to the Favorites/Dash area:


Get Testing!

You’ve got your shiny new Kali install ready to roll. Kick the tires and see what you can accomplish.

Oh, and remember that we’re the good guys. Use these tools responsibly.

Windows 10 Creators Update for Hyper-V – 4 New features

Windows 10 Creators Update for Hyper-V – 4 New features

Microsoft recently released what it called the “Creators Update” for Windows 10. This massive update came with many new features added to Windows 10, which included a few new features for Hyper-V enthusiasts. Most of them are so-called “quality of life” features to both Devs and IT pros.

Here’s an overview of what’s new in Windows 10 for Hyper-V users.

1. Checkpoint and Save for Nested Hyper-V

While this is definitely not a huge deal for production environments, for work or home lab environments running nested Hyper-V (like me) this is an awesome update.

For those that aren’t familiar with the term, nested Hyper-V is when one or more Hyper-V VMs are running on a Hyper-V node. This set up allows you to perform tests on a Hyper-V cluster without having to pay for the extra cost of hardware. Running nested Hyper-V still has some caveats, like not being compatible with AMD CPUs (Ryzen AMD fanboy here!). However, the update has finally squashed an issue with taking snapshots in nested Hyper-V.

Now we can take snapshots and saved states of our Hyper-V VMs running on Hyper-V! This is pretty nifty as I can now have multiple Hyper-V configurations in my lab and easily swap between the different snapshots. Microsoft stated they are continuing to work out the kinks with nested Hyper-v setups, this is a good step in the right direction.

2. Dynamic Resize for Enhanced Session Mode VMS

I’ve used my fair share of both ESXi and Hyper-V throughout the years and I have to say, in my opinion, Hyper-V definitely has a smoother console of the two. But now, with the Creators Update, Microsoft has reassured this statement. With VMs that are using Hyper-V Enhanced Session Mode, you can now resize the VM console and the screen image will “dynamically” adjust with it!

Check out the image below from Microsoft’s website. It’s pretty sleek!




3. Multiple NAT Networks and IP Pinning

This feature helps to alleviate some of the challenges developers have been experiencing with running Windows Containers. One of those challenges has been running multiple NAT networks on a single host. With this new update, you can now use containers, emulators, etc with multiple NAT networks on the same host. You’ll also be able to create and test applications from the container host as well as get access to the container by specifying the IP address of the host and port number.

This is an important update and a good push in the right direction. The more developers start developing apps for containers, the sooner the current IT genre can transition to a “server-less” environment. As of late, the word “containers” has become labeled a “buzz word” and everyone has their own opinions on whether it will become a standard in the future.

Either way, the developers that are designing applications to be run on docker/ windows containers are also creating the building blocks for how IT Pros will be managing and designing our IT infrastructure in the future with micro-services. The easier Microsoft can make it for developers to design and test on container infrastructure the better.

4. Improved Memory Management (for Developers)

Initially, Windows App developers were getting low memory alerts when running device emulators inside Visual Studio. Now with this new update, they can get accurate memory metrics and no longer get these false positive alerts. Just like the previously described feature, this is another improvement for developers.

Other Quality of Life Features

Some of the other features that were released where quality of life fixes like VM Quick Create, which allows you to create a VM with only a few clicks. Additionally there is the new feature called Zoom for VM Connect that allows one to configure a zoom level within the VM remote console.

As you can see, the Creators Update had quite a few quality of life enhancements to Hyper-V for both VMs and containers. It certainly indicates the next-gen features that Microsoft is focusing on and pushing to perfection for the next round of infrastructure innovation and will be exciting to watch in the future.

If you’re interested in more information about these features, you can find the official Microsoft article about them HERE.

What are your thoughts?

Do you have a new favorite Client Hyper-V feature from this list? Is there anything you would’ve liked to see in terms of improvements that weren’t added?

Leave a comment below and let us know what you think!

Confusing Terms and Concepts in Hyper-V

Confusing Terms and Concepts in Hyper-V



If I ever got a job at Microsoft, I’d want my title to be “He Who Fixes Stupid Names and Labels”. Depending upon my mood, I envision that working out in multiple ways. Sometimes, I see myself in a product meeting with someone locked in a condescending glare, and asking, “Really? With nearly one million unique words in the English language, we’re going with ‘Core’? Again?” Other times, I see myself stomping around like Gordon Ramsay, bellowing, “This wording is so unintelligible that it could be a plot for a Zero Wing sequel!” So, now you know one of the many reasons that I don’t work for Microsoft. But, the degree of my fitness to work in a team aside, the abundance of perplexing aspects of the Hyper-V product generates endless confusion for newcomers. I’ve compiled a shortlist to help cut through a few of them.


This particular item doesn’t have a great deal of relevance to Hyper-V for most of us. On the back end, there is a great deal of intersection in the technologies. Site Recovery allows you to replicate your on-premises virtual machines into Azure. But, there’s not a lot of confusion about the technology that I’m aware of. It’s listed here, and first, as an example of what we’re up against. Think about what the word “azure” means. It is the color of a clear, cloudless sky. You think one thing when a salesman walks in and says, “Hi, we’d like to introduce you to our cloud product called ‘Azure’.” That sounds nice, right? What if, instead, he said, “Hi, we’d like to introduce you to our cloud product called ‘Cloudless’.” What?

"Microsoft Drab" Just Doesn't have the Same Ring

“Microsoft Drab” Just Doesn’t have the Same Ring

Azure’s misnomer appears to be benign, as it works very well and sells very well. I just want you to be aware that, if you’re confused when reading a product label or a dialog box, it’s probably not your fault. Microsoft doesn’t appear to invest many resources in the “Thoroughly Think Through Labelling” department.

What Should I Call Hyper-V, Anyway?

Some of the confusion kicks in right at the beginning. Most people know that Hyper-V is Microsoft’s hypervisor, which is good. But, then they try to explain what they’re using, and everything immediately goes off the rails.

First, there’s Hyper-V. That part, we all understand. Or, at least we think that we understand. When you just use the word “Hyper-V”, that’s just the hypervisor. It’s completely independent of how you acquired or installed or use the hypervisor. It applies equally to Hyper-V Server and Windows Server with Hyper-V.

Second, there’s Client Hyper-V. It’s mostly Hyper-V, but with different bells and whistles. You only find Client Hyper-V in the client editions of Windows, conveniently enough. So, if you’ve installed some product whose name includes the word “Server”, then you are not using Client Hyper-V. Simple enough, right?

Third, there’s the fictitious “Hyper-V Core”. I’ve been trying to get people to stop saying this for years, but I’m giving up now. Part of it is that it’s just not working. Another part of it:


With Microsoft actively working against me, I don’t like my odds. Sure, they’ve cleaned up a lot of these references, but I suspect that they’ll never completely go away.

What I don’t like about the label/name “Hyper-V Core” is that it implies the existence of “Hyper-V not Core”. Therefore, people download Hyper-V Server and want to know why it’s all command-line based. People will also go to the forums and ask for help with “Hyper-V Core”, so then there’s at least one round of, “What product are you really using?”

What Does it Mean to “Allow management operating system to share this network adapter”?

The setting in question appears on the Virtual Switch Manager’s dialog when you create a virtual switch in Hyper-V Manager:


The corresponding PowerShell parameter for New-VMSwitch is AllowManagementOs.

If I had that job that we were talking about a bit ago, that Hyper-V Manager line would say, “Connect the management operating system to this virtual switch.” The PowerShell parameter would be ConnectManagementOs. Then the labels would be true, explainable, and comprehensible.

Whether you choose the Hyper-V Manager path or the PowerShell route, this function creates a virtual network adapter for the management operating system and attaches it to the virtual switch that you’re creating. It does not “share” anything, at least not in any sense that this phrasing evokes. For more information, we have an article that explains the Hyper-V virtual switch.

I Downloaded and Installed Hyper-V. Where Did My Windows 7/8/10 Go?

I see this question often enough to know that there are a significant number of people that encounter this problem. The trainer in me must impart a vital life lesson: If the steps to install a product include anything like “boot from a DVD or DVD image”, then it is making substantial and potentially irreversible changes.

If you installed Hyper-V Server, your original operating environment is gone. You may not be out of luck, though. If you didn’t delete the volume, then your previous operating system is in a folder called “Windows.old”. Don’t ask me or take this to the Hyper-V forums, though, because this is not a Hyper-V problem. Find a forum for the operating system that you lost and ask how to recover it from the Windows.old folder. There are no guarantees.

Many of the people that find themselves in this position claim that Microsoft didn’t warn them, which is absolutely not true.

The first warning occurs if you attempt to upgrade. It prevents you from doing so and explicitly says what the only other option, “Custom”, will do:


If you never saw that because you selected Custom first, then you saw this warning:


That warning might be a bit too subtle, but you had another chance. After choosing Custom, you then decided to either install over the top of what you had or delete a partition. Assuming that you opted to use what was there, you saw this dialog:


The dialog could use some cleanup to cover the fact that it might have detected something other than a previous installation of Hyper-V Server, but there’s a clear warning that something new is pushing out something old. If you chose to delete the volume so that you could install Hyper-V Server on it, that warning is inescapably blatant:


If this has happened to you, then I’m sorry, but you were warned. You were warned multiple times.

How Many Hyper-V Virtual Switches Should I Use?

I often see questions in this category from administrators that have VMware experience. Hyper-V’s virtual switch is markedly different from what VMware does, so you should not expect a direct knowledge transfer.

The default answer to this question is always “one”. If you’re going to be putting your Hyper-V hosts into a cluster, that strengthens the case for only one. A single Hyper-V virtual switch performs VLAN isolation and identifies local MAC addresses to prevent superfluous trips to the physical network for intra-VM communications. So, you rarely gain anything from using two or more virtual switches. We have a more thorough article on the subject of multiple Hyper-V switches.

Checkpoint? Snapshot? Well, Which Is it?

To save time, I’m going to skip definitions here. This is just to sort out the terms. A Hyper-V checkpoint is a Hyper-V snapshot. They are not different. The original term in Hyper-V was “snapshot”. That caused confusion with the Volume Shadow Copy Service (VSS) snapshot. Hyper-V’s daddy, “Virtual Server”, used the term “checkpoint”. System Center Virtual Machine Manager has always used the term “checkpoint”. The “official” terms have been consolidated into “checkpoint”. You’ll still find many references to snapshots, such as:


But We Officially Don’t Say “Snapshot”

We writers are looking forward to many more years of saying “checkpoint (or snapshot)”.

Do I Delete a Checkpoint? Or Merge It? Or Apply It? Or Something Else? What is Going on Here?

If you’re the person that developed the checkpoint actions, all of these terms make a lot of sense. If you’re anyone else, they’re an unsavory word soup.

  • Delete: “Delete” is confusing because deleting a checkpoint keeps your changes. Coming into this cold, you might think that deleting a checkpoint would delete changes. Just look under the hood, though. When you create a checkpoint, it makes copies of the virtual machine’s configuration files and starts using new ones. When you delete that checkpoint, that tells Hyper-V to delete the copies of the old configuration. That makes more sense, right? Hyper-V also merges the data in post-checkpoint differencing disks back into the originals, then deletes the differencing disks.
  • Merge (checkpoint): When you delete a checkpoint (see previous bullet point), the differencing disks that were created for its attached virtual hard disks are automatically merged back into the original. You can’t merge a checkpoint, though. That’s not a thing. That can’t be a thing. How would you merge a current VM with 2 vCPUs and its previous setting with 4 vCPUs? Split the difference? Visitation of 2 vCPUs every other weekend?
  • Merge (virtual hard disk): First, make sure that you understand the previous bullet point. If there’s a checkpoint, you want to delete it and allow that process to handle the virtual hard disk merging on your behalf. Otherwise, you’ll bring death and pestilence. If the virtual hard disk in question is not related to a checkpoint but still has a differencing disk, then you can manually merge them.
  • Apply: The thought process behind this term is just like the thinking behind Delete. Remember those copies that your checkpoint made? When you apply the checkpoint, the settings in those old files are applied to the current virtual machine. That means that applying a checkpoint discards your changes. As for the virtual hard disks, Hyper-V stops using the differencing disk that was created when the virtual machine was checkpointed and starts using a new differencing disk that is a child of the original virtual hard disk. Whew! Get all of that?
  • Revert: This verb makes sense to everyone, I think. It reverts the current state of the virtual machine to the checkpoint state. Technologically, Hyper-V applies the settings from the old files and discards the differencing disk. It creates a new, empty differencing disk and starts the virtual machine from it. In fact, the only difference between Revert and Apply is the opportunity to create another checkpoint to hold the changes that you’re about to lose. If I had that job, there would be no Apply. There would only be Revert (keep changes in a new checkpoint) and Revert (discard changes).

If this is tough to keep straight, it might make you feel better to know that my generation was expected to remember that Windows boots from the system disk to run its system from the boot disk. No one has ever explained that one to me. When you’re trying to keep this checkpoint stuff straight, just try to think of it from the perspective of the files that constitute a checkpoint.

If you want more information on checkpoints, I happen to like one of my earlier checkpoint articles. I would also recommend searching the blog on the “checkpoint” keyword, as we have many articles written by myself and others.

Dynamic Disks and Dynamically Expanding Virtual Hard Disks

“Dynamically expanding virtual hard disk” is a great big jumble of words that nobody likes to say. So, almost all of us shorten it to “dynamic disk”. Then, someone sees that the prerequisites list for the product that they want to use says, “does not support dynamic disks”. Panic ensues.

Despite common usage, these terms are not synonymous.

With proper planning and monitoring, dynamically expanding hard disks are perfectly safe to use.

Conversely, Dynamic disks are mostly useless. A handful of products require them, but hopefully they’ll all die soon (or undergo a redesign, that could work too). In the absence of an absolute, defined need, you should never use Dynamic disks. The article linked in the previous paragraph explains the Dynamic disk, if you’re interested. For a quicker explanation, just like at this picture from Disk Management:

Basic and Dynamic Disks

Basic and Dynamic Disks

Dynamic disks, in the truest sense of the term, are not a Hyper-V technology.

Which Live Migration Do I Want?

I was attempting to answer a forum question in which the asker was configuring Constrained Delegation so that he could Live Migrate a virtual machine from one physical cluster node to another physical node in the same cluster. I rightly pointed out that nodes in the same cluster do not require delegation. It took a while for me to understand that he was attempting to perform a Shared Nothing Live Migration of an unclustered guest between the two nodes. That does require delegation in some cases.

To keep things straight, understand that Hyper-V offers multiple virtual machine migration technologies. Despite all of them including the word “migration” and most of them including the word “live”, they are different. They are related because they all move something Hyper-V, but they are not interchangeable terms.

This is the full list:

  • Quick Migration: Quick Migration moves a virtual machine from one host to another within a cluster. So it’s said, the virtual machine must be clustered, not simply on a cluster node. It is usually the fastest of the migration techniques because nothing is transmitted across the network. If the virtual machine is on, it is first saved. Ownership is transferred to the target node. If the virtual machine was placed in a saved state for the move, it is resumed.
  • Live Migration: A Live Migration has the same requirement as a Quick Migration: it is only applicable to clustered virtual machines. Additionally, the virtual machine must be turned on (otherwise, it wouldn’t be “live”). Live Migration is slower than Quick Migration because CPU threads, memory, and pending I/O must be transferred to the target host, but it does not involve an interruption in service. The virtual machine experiences no outage except for the propagation of its network adapters’ MAC address change throughout the network.
  • Storage Live Migration: A Storage Live Migration involves the movement of any files related to a virtual machine. It could be all of them, or it could be any subset. “Storage Live Migration” is just a technology name; the phrase never appears anywhere in any of the tools. You select one of the options to “Move” and then you choose to only move storage. You can choose a new target location on the same host or remote storage, but a Storage Live Migration by itself cannot change a virtual machine’s owner to a new physical host. Unlike a “Live Migration”, the “Live” in “Storage Live Migration” is optional.
  • Shared Nothing Live Migration: The “Shared Nothing” part of this term can cause confusion because it isn’t true. The “live” bit doesn’t help, because the VM can be off or saved, if you want. The idea is that the source and destination hosts don’t need to be in the same cluster, so they don’t need to share a common storage pool. Their hosts do need to share a domain and at least one network, though. I’m not sure what I would have called this one, so maybe I’m glad that I don’t have that job. Anyway, as with Storage Live Migration, you’ll never see this phrase in any of the tools. It’s simply one of the “move” options.

If you’re seeking help from others, it’s important to use the proper term. Otherwise, your confusion will become their confusion and you might never find any help.

What Else?

I’ve been doing this long enough that I might be missing other things that just don’t make sense. Let us know what’s boggled you about Hyper-V and we’ll add it to the list.

Client Hyper-V vs. VirtualBox

Client Hyper-V vs. VirtualBox

Desktop hypervisors are a popular technology among technophiles. We have all sorts of reasons to use them. Some of us need to test software that other people wrote to see if it’s any good. Some of us need to test software that we wrote to see if it’s any good. Sometimes, we need to restrict activity to a temporary environment. Other times, we just want to keep our primary environment out of the clutches of an invasive installer. Coming up with reasons to use a desktop hypervisor is simple. Deciding which desktop hypervisor to use can be trickier. This article will compare and contrast Microsoft’s Client Hyper-V with Oracle’s VirtualBox.

Download Altaro VM Backup

Start your free 30-day trial of Altaro VM Backup today and see why it's trusted by 40 000+ organizations worldwide. Get started now and run your first backup in under 15 mins!

As a rule, I do not tell people which product to use. I believe that you should pick what best suits your needs. If nothing is available that aligns perfectly, mix and match until you get as close as you can. I do not like it when people choose their product first and then throw out convenient justifications for that choice. Two common examples are, “Nobody ever got fired for buying IBM,” and, “This product is the most popular.” My purpose here is not to dictate which product is superior, but to guide you toward an informed decision. That decision might be to use both hypervisors.

Client Hyper-V v Virtualbox

Client Hyper-V and VirtualBox: A Technology Overview

We’re all technology people here, so let’s begin by looking at these two hypervisors from a technological standpoint.

They’re Not Each Others’ Type

The most obvious difference between the two products is that Client Hyper-V is a type 1 hypervisor and VirtualBox is a type 2 hypervisor. Now, every time that I say “Hyper-V is a type 1 hypervisor” and then try to explain what a type 1 hypervisor is, I invariably get at least a few comments that tell me that my description is all wrong and that, “Hyper-V is…,” and then the commenter proceeds to describe Hyper-V as a type 2 hypervisor. Either my explanations aren’t very good or people just don’t believe that Hyper-V is a type 1 hypervisor. I’m hoping that the biggest part of it is that the line between type 1 and type 2 is not nearly as solid as some people would have you believe, and therefore these commenters just see things differently.

Anyway, I am going to attempt a new method of explaining type 1 vs. type 2, but restrict it to this context.

Hypervisor Startup Process: Oracle VirtualBox

I’m going to start by explaining how VirtualBox is started. It is a type 2 hypervisor and the easiest to understand.

  1. The physical computer is started
  2. The physical computer’s boot system (BIOS or UEFI) hands control over to the operating system installed to the hardware. For VirtualBox, that can be Windows, Linux, OSX, or Solaris
  3. The user (that’s you) starts the VirtualBox application.
  4. The user (that’s you) selects which virtual machine(s) to start. VirtualBox spawns hosting processes

Simple, right?

Hypervisor Startup Process: Client Hyper-V

As a type 1 hypervisor, Client Hyper-V’s startup routine is quite different from VirtualBox’s on a fundamental level.

  1. The physical computer is started
  2. The physical computer’s boot system (BIOS or UEFI) hands control over to Hyper-V
  3. Hyper-V starts the management operating system. The management OS can only be Windows, Windows Server, or Hyper-V Server
  4. In response to automatic settings or manual user (that’s you) instructions, Hyper-V spawns partitions for virtual machines

There are variances in the way that different type 1 and type 2 hypervisors accomplish their goals, so I can’t just make a few blanket statements and walk away. We’ll take a look at a few of the generic differences.

The Importance of Type Differences

You can find a great deal of written material on the differences between type 1 and type 2 hypervisors. In light of the capabilities of modern hardware, virtualization software, and operating systems, most of that material is of questionable value. I’m going to skip the questionable parts and only deal with what we can verify.

For this discussion, the most important distinction between type 1 and 2 is that a type 1 hypervisor is always on. The only way to “stop” Client Hyper-V is to turn the computer off or remove the role. Sure, you can stop the “Hyper-V Virtual Machine Management” service, but that’s not Hyper-V. It’s a management service. I’m guessing that’s why they gave it that particular name. Stopping it prevents you from managing any of the virtual machines, but it doesn’t affect the virtual machines or the hypervisor. You cannot see Hyper-V by poking through the management operating system.

On the other hand, VirtualBox can be opened and closed at will. You can locate the VirtualBox application, its service, and its virtual machines in the management operating system’s Task Manager. If you close the main interface, any active virtual machines will continue running because VirtualBox will leave its hypervisor kernel in memory. If you stop the last VirtualBox virtual machine, then there’s no more VirtualBox. You’ll need to start it again to get any virtual machines running.

The type differences of Client Hyper-V and VirtualBox have several consequences:

  • Client Hyper-V’s management OS uses vCPU like the virtual machines
  • You need to use Hyper-V performance counters to see anything about Client Hyper-V’s resource usage, and that doesn’t tell the entire tale
  • Hardware assignment works differently
  • Resource priority works differently

Hyper-V vs. VirtualBox: Hardware Access

When I read the complaints about Client Hyper-V, hardware issues jump right to the top of the pile. Inevitably, comparisons are made to VirtualBox, VMware Workstation/Player, and other type 2 hypervisors. Complainants rarely fail to mention how device issues are nearly non-existent in those products. The root of the problem sources right to the hypervisor type.

When VirtualBox (or any other type 2 hypervisor) spawns a virtual machine, its container runs inside the management operating system where applications live. Like other applications, they do not have direct hardware access; they must request device access through the operating system.

For example, let’s look at my Windows 10 desktop’s assignment of my sound hardware:

Sound Hardware Allocation

Sound Hardware Allocation


I have multiple sound hardware devices and multiple applications. All hardware access and assignment occurs through the operating system. Note: The above is for illustrative purposes only. You do not use Volume Mixer to connect VirtualBox guests to sound hardware.

So, when you turn on a VirtualBox guest, you can use its application container to request access to hardware.

Now, think about Client Hyper-V. The management operating system runs in its own partition separate from the guest operating systems. Unlike VirtualBox, Client Hyper-V’s guest operating systems do not have any projection into the management operating system. They can’t just call the API in the management OS the way that VirtualBox guests can because they can’t reach it. There are features in Client Hyper-V that can help you to address this difference, but this is all caused by fundamental differences in hypervisor technologies.

Takeaway from this section: if you want to use USB-attached hardware and external disks with your guest virtual machines, you will have an easier time with VirtualBox.

Hyper-V vs. VirtualBox: Hardware Presentation

This section connects strongly to the previous section. If you flip through a virtual machine’s settings tabs in VirtualBox, you’re going to find a lot of things that you won’t see in Hyper-V. You must decide between a PIIX3 or an ICH9 chipset. You must choose between an Intel audio controller, an ICH AC97 audio controller, and a SoundBlaster 16 audio controller. If you allow a virtual machine to have a USB controller, you must pick from a 1.1, 2.0, or 3.0 device. Hyper-V doesn’t ask you to make any choices like that.

The difference here is also related to that whole type 1 vs. type 2 discussion. Type 2 hypervisors are designed to run in a much wider range of environments, which presents any number of problems. To address those issues, type 2 hypervisors make extensive use of emulation. Emulation is when a software construct mimics the interfaces of a hardware device. VirtualBox emulates all of the things that I listed in the preceding paragraph and more. Client Hyper-V emulates very little — most notable are its IDE controller and the legacy network adapter.

Emulation solves the problems of widespread applicability. As you can imagine, this versatility comes at a cost. The entire purpose of specialty hardware, such as network cards and video adapters, is that they handle their respective workloads so that the burden doesn’t fall elsewhere. Since they’re built specifically for their tasks, they (presumably) do it better than other components built with other goals in mind. With emulated hardware, your general purpose CPU takes on all the responsibility of dedicated hardware.

Takeaway from this section: VirtualBox works with a wider range of hardware on a wider range of systems at the expense of performance-impacting overhead.

Hyper-V vs. VirtualBox: Resource Priority

Because VirtualBox only runs within the hardware-installed operating system, it is at the mercy of that operating system’s scheduler. One of the reasons I skipped any of the typical discussion about CPU rings is that VirtualBox includes this dialog:

VirtualBox Acceleration Settings

VirtualBox Acceleration Settings


What that means is that VirtualBox can access the same features that many people only associate with CPU ring -1 and the virtual machine monitor extensions used by “true” type 1 hypervisors.

However, VirtualBox is still bound by restrictions imposed by the hardware-installed operating system. If you’ve got a run-away Flash game soaking up memory and CPU in your hardware-installed OS, the OS can and will cause your VirtualBox virtual machines’ performance to suffer to any degree that it likes. If it comes right down to it, you can use Task Manager to kill any VirtualBox process or guest.

In contrast, Client Hyper-V provides the same prioritization controls as its server-based big brother. You can prioritize CPU and memory, enable storage Quality of Service, and set network bandwidth limitations for all of your virtual machines.

Takeaway from this section: Client Hyper-V grants fine-grained control over resource prioritization; VirtualBox does not.

Hyper-V vs. VirtualBox: Video Acceleration

This section is a bit different from the preceding discussion because nothing here will be universally true. I will recount how differences in the two hypervisors influenced my experiences. Your mileage may vary.

Both Client Hyper-V and VirtualBox emulate video. In my experiences, I have been unable to distinguish that one is better than the other when it comes to 2D acceleration. I don’t believe that I ask a great deal of 2D acceleration, but I also know that most modern desktop operating systems utilize 2D acceleration in ways that aren’t always obvious until they’re not available. Two prime examples are font smoothing and window animations. With the expressed reservation that your mileage may vary, I do not believe that 2D acceleration should factor strongly in either hypervisor’s favor.

3D acceleration is a different story. Client Hyper-V offers RemoteFX. In my experimentation, it works very well within the confines of what it is designed to do. RemoteFX does not project the video adapter into the guest operating system, so you cannot access all of its functionality. RemoteFX has also worked on every system that I’ve ever attempted to use it with, as long as it contained the requisite 3D-accelerated WDDM-compliant driver.

3D acceleration in VirtualBox is a completely different story. I have utterly failed to ever get it to work well enough to even display a basic Windows desktop properly. I never got close to trying any 3D acceleration features. So, I can’t give you any meaningful comparisons between the two.

Takeway from this section: 2D acceleration appears to be a wash between the two. 3D acceleration seems more reliable in Client Hyper-V.

Hyper-V Vs. VirtualBox: Virtual Hard Disk Compatibility

VirtualBox supports several virtual hard disk formats. You can choose from:

  • VDI, the native VirtualBox format
  • VMDK, VMware’s format
  • VHD, Microsoft’s format
  • HDD, Parallel’s format
  • QED and QCOW, used in QEMU and other hypervisors

You cannot use VHDX with VirtualBox. The ability to use another hypervisor’s disk format does not necessarily mean that you’ll be able to smoothly transition a virtual hard disk from one hypervisor to another, either.

Takeaway from this section: this is almost general information, because the ability to use multiple virtual hard disk formats is not as useful as it might seem at first. If you plan to attempt to move a virtual hard disk from one platform to another without employing a converter, VirtualBox is your best choice.

Hyper-V vs. VirtualBox: Other Video Features

VirtualBox provides a few video features that Client Hyper-V does not directly compete with.

  • Client Hyper-V can display only on one monitor or all monitors. You can specify between one and eight monitors for VirtualBox.
  • VirtualBox provides a server mode that allows remote computers to connect to the hardware-installed operating system to view the console of one or more specific guests. Each endpoint allows multiple simultaneous remote connections. Client Hyper-V provides similar functionality with vmconnect.exe, but it is not as versatile.
  • VirtualBox can make a video recording of a guest operating system.
  • VirtualBox allows you to set a virtual machine to “Seamless” mode. Applications that you start in the virtual machine will appear and operate as though they are running in the hardware-installed operating system.

Takeaway from this section: if any of these features appeal to you, VirtualBox is the only choice.

Hyper-V vs. VirtualBox: Source Code Access

VirtualBox is open source software. If you don’t like something and believe that you can do better, have at it. If you just want to know how it works, download the code set and dig in.

Microsoft is gradually warming to the notion of open source and has submitted a great deal of code to the community. Windows is notoriously absent. As I understand it, the Hyper-V code base is very tightly coupled to Windows. I have my doubts that we’ll ever see Hyper-V’s code published.

Takeaway from this section: if using an open source hypervisor is important to you, that disqualifies Client Hyper-V.

Hyper-V vs. VirtualBox: Usage License

Client Hyper-V ships as a component of Windows 10 Professional and Enterprise SKUs. If you’re otherwise licensed to use one of those, then you are licensed to use Client Hyper-V.

Oracle licenses the current core VirtualBox package (versions 5.x+) under GPLv2. They also provide some “extensions” under a separate license called the “VirtualBox Personal Use and Evaluation License“. I don’t personally use any of these features, although they do encompass some of the features I spoke of above. I did not dig deeply into the terms of this license, but it appears to be fairly generous. As always, I recommend that you allow trained legal counsel to field any of your licensing questions.

As far as guest operating system licenses, those are a separate tale. Neither Client Hyper-V nor VirtualBox provide for any guest operating system licenses at all. If you install any flavor of Windows or Windows Server into a guest operating system under either hypervisor, you must properly license the hardware.

Takeaway from this section: licensing is always important.

Acquiring Client Hyper-V and VirtualBox

If you’re running Windows 10 Professional or Enterprise, then you only need to enable the Hyper-V role to start using it.

VirtualBox is available from its website:

Enhanced Session Mode in Client Hyper-V

Enhanced Session Mode in Client Hyper-V


Hyper-V’s Enhanced Session Mode technology is available for both the standard Hyper-V editions and Client Hyper-V. I’d argue that it’s far more useful for Client Hyper-V. The only common use case involving users interacting directly with the console of a server Hyper-V guest is VDI, and that does not involve Enhanced Session Mode. Enabling Enhanced Session Mode for a server’s guest would be somewhat exceptional. Client Hyper-V reverses that convention. It is normative to directly interact with locally-hosted virtual machines. Therefore, Enhanced Session Mode is preferred for Client Hyper-V.

What is Enhanced Session Mode?

From a technological standpoint, Enhanced Session Mode ties the VMConnect.exe application into the Hyper-V host’s VMBus component. If you’re not familiar with VMConnect.exe, this is the application that you use any time you connect directly to the console of a [Client] Hyper-V guest (ex: clicking Connect on the context menu of a virtual machine in Hyper-V Manager). This allows some communications between the operating environment that you’re connecting from and the guest operating environment that you’re connecting to. Furthermore, VMConnect.exe employs several technologies from the Remote Desktop Client.

Notable capabilities enabled by Enhanced Session Mode:

  • Making local resources, such as printers, disk drives, and USB devices, available to the guest through the console connection.
  • Copy and paste of files to and from the connecting system and the target guest system.
  • Additional screen resolutions and full screen mode.
  • Smart card logins.

To state it simply, Enhanced Session Mode transforms the VMConnect.exe experience to match the Remote Desktop Client experience.

What are the Use Cases for Enhanced Session Mode in Client Hyper-V?

In general, I think it’s fair to say that if you’ve got a Client Hyper-V virtual machine that you use on a regular basis, you want Enhanced Session Mode. If you’re just testing something out quickly and only need to pop in and out of a particular guest operating system, it’s not that critical. If you’re using something for long periods of time, the small window and walled garden of a virtual machine without an enhanced session will eventually feel restrictive.

I could take the easy way out in this session by enumerating the common reasons for Client Hyper-V, such as development and testing environments, then tack on some blurb about how Enhanced Session Mode would make all of that better. You can probably figure all of that out on your own. Instead, I want to paint a very stark picture that contrasts a standard session against an enhanced session. We’ll do that through two use case scenarios.

Client Hyper-V, Enhanced Session Mode, and Security: The Sandbox Use Case

A user forwards an e-mail to you that they receive from someone that they trust, but it has an attached file. The user also says that the phrasing of the message just doesn’t feel right. So, you pop the attachment into your virtual machine to open it in a contained environment. Pop quiz: should you use Enhanced Session Mode with that virtual machine or not?

The answer might surprise you. If you said, “Do not use Enhanced Session Mode”, then you get high marks for thinking securely, but I must deduct points for not having thoroughly done your homework on Enhanced Session Mode.

Let’s start with why you would not want to use Enhanced Session Mode for poking at potential malware. Without Enhanced Session Mode, that virtual machine is essentially a walled garden. Hyper-V isolates its operating environment from the host’s operating environment naturally. Files and data cannot be transferred out of the guest to the host by any means other than a network connection, which is very easily locked down by simply not connecting the virtual machine to a network. You could place the suspect file into a VHDX, attach the VHDX to the virtual machine, and open it up without ever placing any other machine, including the host, at risk. Well done!

But, you worked harder than you had to.

These are the exact steps to accomplish the same feat using an Enhanced Session Mode guest in Client Hyper-V:

  1. In Hyper-V Manager, take a checkpoint of the virtual machine. Optionally, give that checkpoint a descriptive name.
    Checkpointing in Client Hyper-V

    Checkpointing in Client Hyper-V


  2. Disconnect the virtual machine from the network, if it’s connected.
    Disconnected VM

    Disconnected VM


  3. Copy and paste the file from your desktop into the virtual machine’s desktop. This will only work if Enhanced Session Mode is enabled.
    File Pasted from Host to Guest

    File Pasted from Host to Guest


  4. In the VMConnect console pane, click the Basic Session button.
    Basic Session Button

    Basic Session Button


    Alternatively, click View and Enhanced Session to uncheck it.

  5. Your VMConnect session will end and immediately reconnect. Some guest operating systems will lock your session when this happens, causing you to need to log back in. Do so.
  6. Test the file with whatever tools you have available in the guest operating system.
  7. Once your testing is complete, revert the checkpoint. This irrevocably discards everything that was done in the virtual machine since the last checkpoint was taken.
    Revert Checkpoint in Client Hyper-V

    Revert Checkpoint in Client Hyper-V


  8. Delete the checkpoint.
    Delete Checkpoint in Client Hyper-V

    Delete Checkpoint in Client Hyper-V


  9. Clean up by deleting any remnants of the file in your desktop operating system and performing any necessary reporting on your findings.

The next time you connect to the virtual machine, the host’s normal Enhanced Session Mode setting will be in effect. That means that if it was enabled when you started this procedure, it will be enabled the next time that you connect.

The purpose of this exercise is to show you that Enhanced Session Mode can be toggled off and on easily. You can use the same virtual machine with an open copy/paste and device configuration, then switch to the isolated walled garden at a moment’s notice.

Client Hyper-V, Enhanced Session Mode, and Security: The Administrative Privileges Use Case

A common security best practice for administrative staff is to maintain separate administrative logins and non-administrative logins. You should conduct your menial, yet dangerous activities in a non-privileged session. Those activities include e-mail and web browsing. Administrative duties, such as Active Directory tasks, can be carried out either by Run As or inside an administrative session. There are problems with the traditional techniques.

The Problems with Common Approaches to Session Isolation

The oldest technique involving this separation is secondary logon, or Run As.The Run As approach has multiple problems. For one thing, it’s not all that well-implemented. I have problems with several applications and secondary logins. Somewhat embarrassingly (for them), most of those applications are made by Microsoft. Another problem is that Run As crosses an administrative login with an active non-administrative login. That opens up a path, however narrow, for malware to compromise the administrative session by way of the non-administrative session.

To address this, some administrators have begun using virtual machines. That allows them to have two well-isolated sessions running side-by-side. That approach has merit, but, as we’ve discovered over time, most of us do it wrong. We log in to our root session (the one that the hardware boots to) as a non-privileged user, then spin up a virtual machine running an administrative session. That makes sense on the surface, because the root partition usually provides a superior user experience for the applications that we use most, such as e-mail clients and web browsers. From a security perspective, that’s bad.

What’s wrong with it? Well, a compromised host equals a compromised guest, that’s what’s wrong with it. Consider this:

  1. I’m running my desktop Win10 as a low-privilege user and a Win10 guest as a high-privilege user.
  2. I open an e-mail with a malicious attachment, which infects my machine.
  3. The attacker uses a system exploit and gains root access to my desktop.

What’s part of my desktop? That virtual machine with the privileged session, that’s what. The attacker now owns both of my sessions. What we’ve done is grant the low security session a control link over the high security session, which is an immediate security no-no.

That’s not the only problem. With Client Hyper-V, you need to run Hyper-V Manager and/or VMConnect with administrative privileges, or you can’t even connect to your virtual machines. If you sidestep that with another desktop hypervisor, you’re still going to be at least occasionally doing things via Run As. There’s just no way to avoid being an administrator in the root console. What to do?

Solving Session Isolation Problems with Client Hyper-V

Since you can’t avoid being an administrator in the root session, don’t try. Log on to the root hardware as administrator. What!?! No, I’m not crazy. However, this practice requires discipline:

  • Never surf the web in an administrative session
  • Never use e-mail in an administrative session
  • Never run untrusted or unknown applications in an administrative session
  • etc.

With proper discipline, your management environment should never be at meaningful risk of compromise because you never expose it to such risks.

I have no doubt that you’re thinking, “easier said than done”. I agree. Let Client Hyper-V help.

  1. Log in to your root operating system as an administrative account and set it up with all of your fancy administrative tools. Enable Hyper-V, etc.
  2. Create a virtual machine.
  3. In the virtual machine, install all of your day-to-day “unsafe” applications that you use, like Outlook and Word and your music app. Leave Enhanced Session Mode on.
  4. Log on to the virtual machine as your non-privileged account.

In this configuration, the high security environment has control over the low security environment, as it should be. Do you need to download a file for use in the administrative session? Fine. Download it in the low security virtual machine, verify it there, then copy/paste it into the high security session. If your root operating system is compromised, it has the same net effect that it would if you were doing things the other way around. If your non-privileged guest is compromised, then trash it and start over. You lose nothing and stand to gain much security.

The remaining problem in this use case is, of course, usability. That’s where the rest of Enhanced Session Mode comes in to play.

Enabling Enhanced Session Mode in Client Hyper-V

Enhanced Session Mode is on by default in Client Hyper-V, so you should not need to do anything. To verify it, right-click on the local system in Hyper-V Manager and click Hyper-V Settings. Verify that both of the indicated locations in the screenshot below are enabled.

Enhanced Session Mode Configuration

Enhanced Session Mode Configuration


If these are set, any time Client Hyper-V is able to detect that the guest operating system supports Enhanced Session Mode, it will be active.

Video Enhancements in Enhanced Session Mode

If you’re balking at doing your daily operations like web browsing in a Client Hyper-V virtual machine because you do that sort of thing much more often than you work in your administrative session, this is one of the mitigating points. Make your non-privileged guest full screen. When you connect to a guest in VMConnect and it detects that Enhanced Session Mode is available, you’ll get this (unless it has a RemoteFX adapter):

Enhanced Session Mode Video Options

Enhanced Session Mode Video Options


If you drag that slider all the way to the right, it becomes Full Screen. Then it looks a lot like when you use Remote Desktop Connection. Do your work in that full screen session, and minimize back to your primary desktop if you need to. You can also “Restore” it and becomes a very large window that you can move around. Double-click on its title bar to return it to Full Screen mode.

Audio, Printers, and USB Devices in Enhanced Session Mode

For me, audio rounds out what I want in my non-administrative session. I work in an environment with lots of people which means lots of distracting noise. Noise-cancelling headphones and a solid playlist constitute the thin wall that keeps me in the land of sanity. Client Hyper-V doesn’t let me down.

In that connect dialog that you saw in the previous section, click the down arrow next to Show Options, then switch to Local Resources.

Client Hyper-V Local Resources

Client Hyper-V Local Resources


Most things that you’ll want to connect can be found on this dialog. One thing to note is that sounds in the virtual machine will be transmitted back to the host by default, but your connected microphones do not transmit into the guest by default. To change that, click the Settings button in the Remote audio section and select Record from this computer under Remote Audio Recording.

Client Hyper-V Remote Audio

Client Hyper-V Remote Audio


You can see the Printers and Clipboard checkbox in the first screenshot. Those are selected by default, so copy/paste and printers should already be functional from the first time that you connect. Printers aren’t perfect, especially with networked printers. For those, I just connect to them as though I were using a physical system and all is well.

But, there are other devices that you might want to use. From that first dialog, click the More button to be greeted with a dialog similar to the following:

Additional Devices in Client Hyper-V

Additional Devices in Client Hyper-V


I don’t have any USB devices to speak of, so nothing appears here for me. If you have a special USB device, this is where you’ll go to enable it. If you don’t see it, make sure to check Other supported Plug and Play (PnP) devices and Devices that I plug in later. That’s your best bet to getting that device to work.

In my case, I like to share files between host and guest without copy/paste (be mindful of the potential security risks with that and maintain discipline — execute unknown/untrusted files in the low security environment only). I have a storage disk that I map. In the above image, that’s Storage (D:). In the guest, it looks like this:

Client Hyper-V Mapped Drive

Client Hyper-V Mapped Drive


It’s more easy to bulk-manage files using a mapped drive as opposed to host/guest clipboard copy/paste.

What’s Not Available in Enhanced Session Mode?

For a work environment, there aren’t many drawbacks to Client Hyper-V aside from the cost to properly license each guest. Aside from a natural human reluctance to change long-standing practices, it’s a winning solution.

Home users, though, even home users like me that still try to practice safe computing, face a problem. You’re not going to be doing any serious video gaming in a Client Hyper-V guest. HTML and Flash games, sure. Java games, maybe. AAA games? Absolutely not. Not even with RemoteFX. Maybe in the next version.

Client Hyper-V in Windows 10

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. Microsoft’s Windows Server blog has decent starter material on the subject. 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

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

    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

    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

    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:

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

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

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

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 ( through

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 (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 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

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 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!

RemoteFX in Windows 10 Client Hyper-V

RemoteFX in Windows 10 Client Hyper-V


The use cases for a hypervisor on the desktop are quite different from those for hypervisors in the datacenter. With only a few exceptions, datacenter virtual machines run around the clock, quietly providing services behind the scenes. They aren’t logged onto very often, and then usually only for administrative purposes. If a virtual machine is running on the desktop at all, its also typically open in a window and seeing regular interaction. It’s reasonable to expect more from that experience than might be typical for server-side virtualization. One of the technologies that help Client Hyper-V to meet that expectation are RemoteFX.

The server editions of Hyper-V also offer RemoteFX. It’s not used as frequently, is disabled by default, and has more requirements. The complete RemoteFX experience on the server requires the Remote Desktop Services stack to be employed, and server-class accelerated GPUs are quite expensive and uncommon. It’s a different story for Client Hyper-V because desktops commonly contain accelerated graphics adapters. Beyond having such an adapter, there are no particular requirements for Client Hyper-V’s RemoteFX.

What is RemoteFX in Client Hyper-V?

I once undertook a journey to enumerate the features of RemoteFX, and gave up after a while. RemoteFX is an umbrella term for several technologies designed to enhance the Remote Desktop/VMConnect experience for Hyper-V guests. Most commonly, we think of video capability because that is the most obvious component, but it is not the only one. If you’re interested in the other RemoteFX technologies, I’ll leave you to perform your own quest. What we’re most concerned with is video. Windows 10’s Client Hyper-V provides strong support for RemoteFX video, which mostly means 3D acceleration. It is available by default, but you must specifically configure a RemoteFX video adapter for each virtual machine that you intend to use it with. I would strongly recommend that you proceed with caution when adding this adapter to any virtual machine whose guest operating system is not explicitly supported by Hyper-V. This TechNet article shows the supported Windows guests and there are menu items at the left that will take you to the lists of supported Linux guests.

Note that RemoteFX video might not be required for a satisfactory Client Hyper-V experience. Some 2D acceleration is available without a RemoteFX adapter. It’s not great, but only your needs can determine if it is acceptable. Also note that RemoteFX video will not magically transform your Client Hyper-V guest into a video gaming powerhouse, regardless of the capabilities of your graphics adapter.

You usually do not need to take any particular steps to enable RemoteFX video for your hosting Windows 10 system. If your video adapter has a DirectX 11.1-compatible driver, it will almost certainly work. In Hyper-V Manager, access the properties of your Windows 10 system and look on the Physical GPUs tab for something like the following screenshot. If you can’t select Use this GPU with RemoteFX, then you have an adapter that won’t work. If your adapter is capable, Hyper-V will have already enabled it.

Basic Configuration - RemoteFX Adapter

Basic Configuration – RemoteFX Adapter


Adding and Configuring a RemoteFX Video Adapter to a VM in Hyper-V Manager

It’s quick and simple to add a RemoteFX video adapter to a virtual machine with Hyper-V Manager. It does not matter what Generation the guest is. These screenshots are for a Generation 1 virtual machine, but the instructions are the same for Generation 2.

  1. In Hyper-V Manager, verify that the target virtual machine is Off. If it isn’t, you’ll need to get it into that state. If it’s online, shut it off. If it’s saved or paused, resume it and then shut it down.
  2. Right-click on the target virtual machine and click Settings...
  3. The Add Hardware tab should already be active. Highlight RemoteFX 3D Adapter and click Add. If the item is disabled, the virtual machine isn’t off or your adapter does not meet the requirements for RemoteFX.
    Adding a RemoteFX Adapter

    Adding a RemoteFX Adapter


  4. A new tab will be added to the VM’s settings dialog named RemoteFX 3D Video Adapter. You can configure the settings as suits you.
    RemoteFX Adapter Settings

    RemoteFX Adapter Settings


  5. The adapter is not truly added until you click OK or Apply, but you can return to this dialog any time that the virtual machine is off to adjust the settings. You can also use the Remove button if you’d rather just use the 2D acceleration. There is a finite number of active virtual machines that your video card will support, so you may find that you need to remove it from some guests if you are running several simultaneously.

Adding and Configuring a RemoteFX Video Adapter to a VM in PowerShell

Adding a RemoteFX adapter in PowerShell is trivial. Configuring it can be a bit tricky.

To add the RemoteFX adapter:

A -VM parameter is also available, and it will accept piped virtual machine objects or names for bulk operations.

To configure the adapter, use Set-VMRemoteFx3dVideoAdapter. You can use -VM or -VMName just as you did with Add-VMRemoteFx3dVideoAdapter. You can also pipe in the output from a Get-VMRemoteFx3dVideoAdapter run to select an adapter. The three parameters of interest are -MaximumResolution, -MonitorCount, and -VRamSizeBytes. As far as I can tell, there’s no way to know in advance what the valid options are (unless you look in Hyper-V Manager or something). So, you can just feed it some gibberish. The error messages will tell you what you can use:

Set RemoteFX 3D Adapter Errors

Set RemoteFX 3D Adapter Errors


With valid values (for my card):

Using the RemoteFX Video Adapter

As soon as you boot up the guest, the RemoteFX video adapter is ready to go. If it doesn’t boot or it won’t show a screen, then your guest operating system probably doesn’t support RemoteFX. Here’s a screen shot of the newly-installed Microsoft RemoteFX Graphics Device – WDDM from within a Windows 10 guest’s Device Manager:

RemoteFX Adapter in Device Manager

RemoteFX Adapter in Device Manager


I would not get excited that you can now start running a bunch of 3D games in Client Hyper-V. That’s not really what RemoteFX is for. A game might work, but it might not. More “run-of-the-mill” applications, like web browsers and operating system GUIs are incorporating 3D, and that’s where you’ll see the most differences with a RemoteFX adapter. As you can see in Device Manager, you’re not getting a direct projection of your video adapter, which means that you’re not going to be able to load the manufacturer’s specific hardware driver, which means that you cannot expose its full capabilities to the guest.

10 Hot Hyper-V Topics of the Moment

10 Hot Hyper-V Topics of the Moment

While we at Altaro always try to keep you all up to date on the latest dealings in the world of Hyper-V and Microsoft virtualization, sometimes there is such a wealth of information released or a large group of product releases that at times it just helps to get it all out there!

Therefore, I’ve prepped 10 useful links below that I hope you will find useful in your IT adventures!

1. The Differences Between Windows Containers and Hyper-V Containers in Windows Server 2016 – This is a hot topic right now. Containers were announced at Microsoft Ignite back in May, but did you know there are going to be TWO different types of containers? There will be Windows Containers which will isolate applications whilst sharing the underlying kernel, but if you require further application isolation you can utilize Hyper-V Containers. Cool Stuff!

2. Why Does Hyper-V Have Network Issues with 1 GbE NICs? – This one is written by fellow Hyper-V MVP Aidan Finn over on the Petri IT Knowledgebase. As someone who works with Hyper-V every day, I completely feel Aidan’s pain on this one. The article mainly centers around the fact that having VMQ enabled on certain NICs will cause all sorts of network weirdness. The problem mainly lies in the hands of hardware vendors that refuse to create VMQ-Friendly device drivers and continue to RE-enable the feature with each driver update. If you’re not aware of this conundrum, check out this article.

3. List of Currently Available Hotfixes for the File Services Technologies in Windows – I Stumbled across this one the other day, and instantly said to myself $KACHING$! While this isn’t hard hitting tech news or a major product announcement, I’ve found myself working on some sort of Windows Storage issue several times and thought to myself, “gee…  I wish there was a list of all the available hot-fixes for this and a list of what is fixed”. Search no more! Even if you don’t need this list right now, book mark it anyway, as you may need it someday in the future and it is a good reference to have.

4. Hyper-V in the Real World – Virtualization Review – Found this one in my twitter feed the other day. It’s more of a general planning guide to Hyper-V deployments, but I found it is very well written and would be a good read for anyone just starting to get into Hyper-V and the Microsoft virtualization space.

5. KB: How to re-associate orphaned VMs with a service instance or VM role in VMM – For those that have run into this issue, it’s a royal pain in the rear end. There were cases where if you had to remove and re-add a host to VMM, certain VMs could become orphaned from a service instance or VM role. With the latest Update Rollup for VMM, you are now able to re-associate them! That leads me into our next link!

6. Update Rollup 7 for System Center 2012 R2 Virtual Machine Manager is Now Available – Not a huge announcement by any means, but if you are utilizing VMM inside of your environment, there are some nice fixes detailed in the link. My personal favorite is the link listed above this one.

7. Hyper-V Storage QoS in Windows Server 2016 Works on SOFS and on LUNs/CSVs – This post was done by fellow Hyper-V MVP Didier Van Hoye on his blog Working Hard in IT. Didier does an excellent job keeping the community up to date on all the storage developments in the Microsoft world and certainly doesn’t disappointed with this post. It’s certainly worth a read and covers some of the exciting QoS developments contained in the upcoming Windows Server release.

8. Storage Spaces FAQ – I’m not really sure if there was just something in the water these last couple weeks or if parts of the world just opened their eyes and realized how AWESOME Microsoft’s Storage Spaces technology is. I had a lot of questions about the technology and how it works in certain cases. So, I figured linking the official FAQ off of Technet wouldn’t be a bad idea. Happy reading!

9. How to Create a Cluster in a Restrictive Active Directory Environment – Clustering – Speaking of questions I get all the time….  I hear about this topic quite frequently from administrators that work in highly restrictive environments such as the defense industry or industries with very stringent compliance requirements. Establishing a cluster in an environment where AD is really locked down can be difficult, but this howto should help.

10. Windows 10 Launch – I couldn’t bring myself to leave this one out. Unless you’ve been living under a rock for the last several weeks you’ve heard that Windows 10 is officially available. I’ve been running it ever since the technical preview went live some time ago, and I must say, it is my favorite OS to date. Very stable and functional interface. It also continues the trend of including Client Hyper-V for virtualizing workloads on the workstation should the need arise.

Well that wraps it up for us! Stay tuned for more Hyper-V goodness and I hope you’ve enjoyed your time reading!


Introduction to Client Hyper-V

Introduction to Client Hyper-V

In talking with IT pros in the industry on a regular basis, I often see ebbs and flows of interest regarding specific topics or technologies, and one such topic that I’ve seen several inquiries on lately is Client Hyper-V.

Its difficult to pin down any one reason, but whatever the cause, it’s very apparent there seems to be a very real lack of information regarding Client Hyper-V. I mention it in conversations and forums and I’m often met with strange looks. Most people think or assume that the only Hyper-V out there is “the” Hyper-V contained in the Windows Server product line. This couldn’t be further from the truth.

What is Client Hyper-V?

Most IT Pros I talk with come from some sort of VMware background. So, the easiest way for me to describe what Client Hyper-V is, is to simply say that it’s Microsoft’s version of VMware Workstation.

For those that don’t know what VMware Workstation is, it is simply a Hypervisor that sits on top of a client operating system such as Windows 7 or Windows 8.

While some of the architectural concepts are different between Client Hyper-V and VMware Workstation (I won’t get into that debate here), the user experience is essentially the same. Both Client Hyper-V and VMware Workstation allow us to run virtual workloads on our desktops and laptops. Even the same desktops and laptops we use in our everyday lives.

Client Hyper-V supplies all the same functionally of Hyper-V, without the enterprise capabilities, such as being able to join a Microsoft failover cluster. The end user will end up with Hyper-V Manager present on their system and VMs can be setup and managed in much the same way a system administrator would do on their production Hyper-V hosts.

Microsoft didn’t re-invent the wheel here, thus making Client Hyper-V very easy to adopt if you have any preexisting knowledge of Hyper-V.

Once I reach this point of the conversation people start asking what the potential use cases are for such an application, so I will cover that next.

Use Cases for Client Hyper-V

It’s a fact of life that most system administrators have to deal with legacy software in their day to day lives. Lets face it, some software is not cheap to upgrade/replace so the longer a user (Or set of users) can continue to use that application the better.

It’s also a fact of life that as operating systems evolve those same legacy applications could potentially begin to run into issues. We’ve all seen this.

Now I’m not advocating that everyone keep their old, crappy, legacy software around. It’s dangerous from a security perspective and the longer you wait to upgrade, the harder it’s going to be to get off that software. However, there are some scenarios where you may need to run said software just a little bit longer.

Scenarios such as:

  • Cost (This should NOT be the only reason stopping you)
  • Your on the cusp of integrating replacement software and need a stop gap
  • Said legacy application also contains legacy data that is maybe only accessed once a year.

If one of these situations fits you, Client Hyper-V could be an option.

Lets say the application in question only ran on Windows XP. You would create a Windows XP Virtual Machine on the end User’s PC and install the legacy application inside the VM. At that point the end user can fire up the VM and use the application as needed.

NOTE: Please make sure you aren’t storing production data SOLELY inside the VM. It goes without saying that you want to have a backup copy of that data somewhere. So plan accordingly.

The next most common use case for Client Hyper-V is test/dev workloads. I personally use Client Hyper-V for this almost on a daily basis.

Assuming your production machine is beefy enough, Client Hyper-V is great for testing new applications or configurations prior to dropping them into your production environment. Simply make (or clone) your virtual machines, and away you go. Plus, if setup on a laptop, it’s a highly mobile Hyper-V host that is great for spinning up virtual workloads on the go. I routinely use it for presentations, and on-premise at customer locations for migrations or utility purposes. The possibilities are endless.

Requirements and Limitations

Next, let’s cover the requirements for running Client Hyper-V. They are as follows:

  • 64-Bit CPU
  • SLAT capable CPU
  • Minimum 4GB of memory
  • Windows 8 Pro or Enterprise
  • Windows 8.1 Pro or Enterprise

What is NOT supported? As stated earlier, this tends to be some of the more enterprise level functions…

  • Remote FX
  • Live Migrations
  • Hyper-V Replica
  • Virtual Fibre Channel
  • 32-Bit SR-IOV Networking
  • Shared .vhdx files

How to Install

Installation is quite simple. It can be conducted via the programs and features section of the Windows OS as seen below. Simply select Hyper-V in the windows features list and click OK to conduct the installation.

A reboot will be required.


Anything Else to Note?

It should be noted that if you’re used to the full blown version of Hyper-V, you’ll find that memory management for the virtual workloads will function a bit differently. This is primarily because Client Hyper-V is intelligent enough to know that since it resides on a workstation, the host system is most certainly doing other things besides just hosting virtual workloads and it is sensitive to that idea.

One other oddity is if you frequently switch from WiFi to a wired connection, you will have to manually re-configure your Hyper-V virtual switch every time you do so. Just one thing to keep in mind.

Wrap Up

You’ll find that Client Hyper-V can be quite a powerful tool when utilized properly. I find myself using it more and more on a regular basis and highly encourage people to check it out and see what it can do for you.

Thanks for reading today’s article, and feel free to contact us should you have any questions comments or concerns!