Last week I covered the history of client hypervisors and why they won't help administrators achieve offline VDI. Now let's look at some of the uses client hypervisors
The first client hypervisors fell short because they couldn't provide the hardware support and user experience that's necessary to virtual desktop infrastructure (VDI). Today, you can use client-side hypervisors in other ways -- to get flexible desktop management.
Type 1 client hypervisors
Type 1 client hypervisors are useful because they can give virtual machines (VMs) direct access to the hardware, which results in an almost-native experience for the user. They're also more secure than Type 2 client hypervisors because there is no exploitable host OS running between the VMs and the hardware.
Plus, since Type 1 hypervisors interface directly with the hardware, you can manage the hardware directly, too. That means you can enable or disable devices, services or even entire systems based on centralized policies. Not only can you do virtual desktop management, but you get device management, too.
More on client hypervisors
Guide to client hypervisors
Do you need a client hypervisor?
How a client hypervisor executes desktops locally
Perhaps most important, though, is that broadening hardware support among hypervisor vendors means that we have the ability to whitewash our hardware and deliver a single OS image across the board. I've written about this approach in the past as a way to achieve the functionality of virtual desktop infrastructure (VDI) without actually doing VDI.
There are a few challenges that come with Type 1 client hypervisors. The first is that the install process is destructive. There's no way to deploy the solution without wiping the laptop or PC first. You can do a physical-to-virtual migration of your user's desktop, then copy it to the device after you've installed the hypervisor, but that's not a simple process.
The other thing is that the host user interface (UI) isn't something the users will be used to. At best, the host UI is Linux skinned to look like Windows, and the less time the users spend with it, the better.
Type 2 client hypervisors uses
Type 2 client hypervisors, on the other hand, are almost 100% ignorant of the underlying hardware because they rely on Windows to do all the heavy lifting. That means that the installation process is non-destructive and can be deployed everywhere without wiping users' machines. Also, since it runs on a host OS that the user is probably familiar with, the UI feels normal.
That said, there are a few drawbacks with these client-side hypervisors. All the hardware in Type 2 hypervisors is emulated, so rather than sending graphics calls to the GPU directly, the hypervisor directs graphics calls to the host OS and lets it interface with the hardware.
Also high on the list of drawbacks is that, if the host OS is unmanaged, the VMs might as well be, too. Imagine screen-scraping or key-logging malware on the host watching what you type and do in the VM (which would be easy because everything is running through the host OS), and you can see the potential issue.
When you step back and look at the positive and negative aspects of client hypervisors, you end up a far cry from the original use case. Where IT pros once had aspirations of moving VMs around the network or WAN, solving one of our oldest problems, client hypervisors are more useful as a technology to whitewash hardware and allow you to deploy the same Windows image to every computer in your company and manage them centrally.
You have multiple options for doing this, each with its own benefits and disadvantages. You can use Type 2 hypervisors everywhere, but you sacrifice a bit of performance (and possibly security, but that's manageable). Or, you can use Type 1 hypervisors to provide a nearly native experience.
Despite the fact that client hypervisors let us down in the beginning, they've resurfaced as a desktop management solution, and isn't better desktop management what we're really trying to do anyway?
This was first published in December 2012