Why do we need "Software" client hypervisors?

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.

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:

  1. 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.
  2. CHV's need to work with everything - offline VDI (all vendors), virtual security appliances (Neocleus style), operating systems, directories, networks, devices, you name it.
  3. 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.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

One aspect of this I could see happening occurs once we have pervasive client hypervisors.  ISVs will be free to provide their "application" in the form of an OS.  Not a general purpose OS such as Windows or a full Linux, but a ultra light weight OS with just what they need and nothing more.  

No install and no constraints,  Just an application appliance in the form of a VHD (or whatever).  Multimedia, as well as Process Emulation software (software that mimics real world process sequences; think everything from weather analysis to second life) would be better off on a "real-time" OS than a general purpose OS.  But that can't happen  until the client hypervisors are all there, and we have a stable small number of interoperable virtualization formats so any hypervisor can use any disk format.  We are close, but not quite there on the interoperability front -- so that will come if we can ever get the client hypervisors.


@Tim Managan ... i really like that thought, an isv delivering their app as an application running on baremetal chv or efi ...however... as much as we knock OS's =  interoperability and intra-app access to other apps data sources, dependencies, etc have me wondering.

Perhaps chv and efi 's true win is very simply removing the opex of IMAGE TUNING for specific hardware. Could customers now have, truly, ONE IMAGE that is platform agnostic (laptop, desktop, vm, streamed, linked, iPhone, RDP/ICA/PCoIP/ALP/RGS viewed...etc)??

Now, do i need to have one EFI or CHV to do this...or, will they all allow interop?

Hmmmmm....another cup of coffee to ponder.


Check out www.splashtop.com for a cheaper version of Phoenix that is already embedded in some OEMs. The concept of embdded is great for JEOS (just enough operating system) application delivery. In other words you don't need a full or Windows OS to run all apps, so why bother being the point. I think the reality is that there is room fro both embedded and full CHV. I can see the JEOS type solutions for Netbooks etc where I just need light weight access to certain app types. Where i need more Desktop like functions, I'd rather go to a CVH. 9i.e. personal mac with a windows work os).


Gabe, This idea is very communist... Where does it end? :)  This idea would turn equipment into more of a basic commodity then it already is.

Actually I think you would still end up with the same situation you have now, different vendors with slightly different ideas on how to do everything. Which I believe is the best system, sure it's a bit chaotic but  from the chaos comes innovation.


All I know is that client side hypervisors is going to make Intel and AMD wet their pants.  Finally a reason to convince someone to purchase that eight-core desktop chip.  You'll need it to run your 12 client hypervisor OS's simultaneously. :)



Interesting idea and certainly worth the discussion. When we started Virtual Computer, we felt that we needed to be hypervisor agnostic such that the management system we built could be used on another hypervisor platform if one was to become ubiquitous in themarket. Our feeling was that microsoft would be the likely candate to do that and we took steps to insulate the end-point management layer (where we implement our high-value features) from the hypervisor itself.

As it turns out, Xen has a good chance of getting a very wide-spread deployment across PC OEM's but I do think the market will remain fragmented for a long time. this is primarily for two reasons:

1) these products are all new and changing rapidly. We are currently planning releases every 3 months to get new features, performance tuning, and bug fixes  onto the client (we call that NxTop Engine).  imagine if you had to udpate your bios every 3 months on your PC. I don't think people would be too keen on that.  It's also quite likely that the day you buy your product from a PC OEM, it will require an upgrade to that layer of firmware (a behaivor that sounds alot more like software than firmware)

2) Microsoft has not been heard on this topic. If they get serious about a hypervisor as the base for Windows, they would likely get very wide spread deployment (assuming they did it in an open manner and supported more than just Windows environments).  That's not to say intel, vmware, citrix or the PC OEM's themselvs wouldn't have a huge impact on the success or failure of such a solution. It just says Microsoft will gain alot of attention if it enters the market with bare-metail hypervisor technology.

just my .02,