For at the past few years, I've talked about how I think that platform hypervisors are going to move towards the hardware in the future, leaving the current market players sitting not on their own hypervisors, but on a suite of tools to manage/extend the capabilities of the built-in hypervisor on whatever piece of hardware (and therefore embedded hypervisor) is purchased.
I think the same can be said for client hypervisors (called CHV from now on...unless I start getting paid by the letter). In fact, I think that it might be even more important for CHV's to be embedded into the hardware than platform hypervisors. The reason? Adoption. I believe there are the three key points to get CHV's adopted into every day IT, from the home PC to the corporate workstation:
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
- CHV's need to be everywhere - every laptop, every desktop, every netbook. Nobody should have to go "get" a CHV--it should just be there already. Users should be using it (or have it available to them) without knowing it.
- CHV's need to work with everything - offline VDI (all vendors), virtual security appliances (Neocleus style), operating systems, directories, networks, devices, you name it.
- Everything needs to work with a CHV - the reverse is true, too. All OS's should have full access to all the devices (manageable, of course). None of this "one machine has access to the GPU" stuff.
One way I can see to achieve this is to embed the hypervisor directly on to the hardware. Forget Xen, ESX, and KVM. Forget key fobs and memory cards. The key to widespread CHV adoption is embedding it on every single new machine out there, lacing the hypervisor in directly with the hardware at the lowest possible level, while still leaving hooks so that management utilities can dig in and control access to devices, OS's, and system configurations as needed.
Now, I realize that the four companies (Citrix, VMware, Virtual Computer, and Neocleus) currently developing or selling CHV's are going to have a hard time with this, but let's face it, it's better for them, too. Instead of spending all their time adapting to each piece of hardware old and new, why not let the hardware do the work while they focus on what really makes CHV's cool - the management capabilities.
CHV vendors aren't facing the same market that the platform virtualization vendors faced when the "V-word" was new. Hell, platform virtualization almost sells itself. Run 10 servers on one piece of hardware? I'm in. Consolidate the space/resource consumption of your data center by 1/10th and recoup your new hardware expenses in a year or two? Sign me up.
CHV's, however, aren't in demand. There's no ridiculously obvious cost savings or increased efficiencies associated with them. You can't put a CHV on a laptop and have two people use the same device (I mean, you could, I guess, but they're not designed for that). In fact, the opposite is true - you now have a single device for a single user that potentially can require two, three, or more OS licenses! Add to that the fact that there are four CHV vendors currently in the space (With more coming, I'd bet - no KVM-based solutions are out there yet), and you've got a cluster...and not the redundant kind.
And so, the solution to widespread adoption is to embed it. Change the decision that people have to make from "Should we look at all these different client hypervisors?" to "Should we use this technology built in to the computer?" Make it like HyperThreading.
So how does a CHV get embedded into the hardware? Of course, Intel and AMD could sit down and come up with a way to build a CHV into their processors or chipsets, but BIOS manufacturers could also get in the mix. In fact, Phoenix Technologies (yes, THAT Phoenix Technologies) has a lightweight hypervisor called HyperCore that is actually based on Xen (just like three of the four CHV vendors). The first use of HyperCore is a solution called HyperSpace, released earlier this week, which is a sort of pre-boot environment that allows you to run certain Linux applications without booting into Windows. Admittedly, that's not a CHV like we've been talking about, but it is a hypervisor at a lower level in the system. The fact that it's based on Xen means that there may be room to expand on it and make it more robust. So what if Citrix, who's already going to give XenClient away for free, were to partner with Phoenix and other BIOS manufacturers to find a way to include XenClient in the BIOS?
The last thing I want to mention is EFI, or Extensible Firmware Interface. EFI is less like a bootstrap-on-a-chip BIOS and more like a shim OS between the hardware and the operating system (sound familiar?). All current generation operating systems support booting from EFI-based machines, so maybe it's worth looking for ways to build the hypervisor into the EFI on new computers. It's still not in the hardware, but it is one level lower than where we are today.
That's it for this drawn out thought! I'm anxious to hear what you all have to say, so post in the comments or shoot me an email.