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!