Many people (myself included) have been talking up the benefits of bare metal client hypervisors and how they could play a key role in the success of desktop virtualization. Unfortunately we’ve yet to see client hypervisors enter the mainstream. While there have been some smaller releases here and there, the big companies (Citrix/Microsoft/VMware) don’t have anything yet. (Citrix has released a tech preview, Microsoft has said nothing, and VMware talked them up for awhile but has since gone cold.)
And while we argue about the merits of client hypervisors, desktop virtualization is only in use by 2-3m of the 500m corporate desktop users in the world (according to Gartner’s Mark Margevicius at the IT Operations & Management Summit last month). There’s a lot of talk about what it would take to get the other 99.5% of the world’s desktops virtualized, and client hypervisors have been suggested as an enabling technology that could address a big chunk of those.
But over the past few months it’s become clear that client hypervisors aren’t the biggest thing holding back desktop virtualization. Contrary to what I’ve written before, I now believe that even if a “perfect” client hypervisor magically appeared today, we’d still be no closer to virtualizing the “other” 498m users.This is because the complexities keeping those folks physical have nothing to do with how good client hypervisors are.
(For those who haven’t been following this conversation over the past 18 months, this is the point at which client hypervisor vendors will scream, “THAT’S WHAT WE’VE BEEN F***ING TELLING YOU FOR THE PAST YEAR. IT’S NOT ABOUT THE HYPERVISOR, IT’S ABOUT EVERYTHING THAT SURROUNDS IT!”) Okay fine. So now that I get it, let’s explore this notion a bit more...
Building a good client hypervisor is not the same thing as building a useful client hypervisor. A good client hypervisor would have broad hardware support, great performance, a seamless user experience, solid security, etc. A useful client hypervisor would allow dynamic desktop composition, seamless offline and online flow, and the general ability for a user to work in any context and on any hardware. A useful client hypervisor has to be good, but a good client hypervisor isn’t necessarily useful. (I’m not picking on any vendors here. I think they all know this and they’re all trying to build products that are good and useful.)
Of course the “good versus useful” conversation is not client hypervisor-specific. “Good VDI” provides a good remote user experience and good server utilization, and we have a lot of good VDI solutions today. Unfortunately they’re only “good” for 0.5% of all corporate desktop users. “Useful VDI” would take the tactical stuff we have with Good VDI and add dynamic desktop composition, simple management, great user personalization, multi-modal flow, etc. And while some vendors are creating useful pieces, no single vendor has nailed everything we need for Useful VDI.
Circling back to client hypervisors, we can easily list the characteristics that would make a client hypervisor good and the characteristics that would make it actually useable.
Characteristics of a good client hypervisor
- Runs on lots of different hardware (old and new)
- VMs run with native-like performance
- VMs can access native hardware capabilities (multi-touch trackpads, GPU, fingerprint readers, power state, etc.)
- Supports full VM encryption, remote wipe, etc.
Characteristics of a useful client hypervisor
- Data is continuously backed up
- User environment is continuously replicated
- Users can flow from central environment to client-based environment
- Admins create a single disk image that is used for central and local desktops
- User experience and procedures are the same for central and local desktops
- Disk image is dynamically composited regardless of whether it’s running locally or centrally
- Users can swap hardware with no impact
At first glance it’s easy to see that the capabilities from both lists are great. But it’s also easy to see that the “good” list is more tactical, while the “useful” list describes the things that are more meaningful to users and admins. Ultimately this means that no one really cares about the good/tactical stuff, but that instead we just want the useful things.
And looking through the list of useful things, what on that list actually requires a client hypervisor?
Can’t we just manage the client with a traditional image management systems that can already account for differences in hardware while providing native device access? If we had a system which could flow settings and apps and data around, couldn’t we just flow that down to whatever the client is? Aren’t there already systems that encrypt, back up, and sync local data with central stores? If we figure out how to handle user-installed apps and app layering and isolation, wouldn’t that work with or without a hypervisor?
If so, why would we need a bare-metal client hypervisor?
Last week we explored the possibility that VMware may have cancelled their bare metal client hypervisor initiative. Thinking through the actual advantages that are linked to the hypervisor itself versus the advantages you get with the whole ecosystem, canceling a client hypervisor (if true) might not be a bad idea.
Maybe Microsoft is on to something too by focusing the conversation on the Windows instance instead of the client VM container?
Maybe Chetan is right and the client hypervisor really is just a dumb old typewriter with some more electronics.
Or maybe I’m wrong.
*Footnote: My (growing) list of desktop virtualization paradoxes
- Madden’s VDI versus TS paradox: In order for VDI to make economic sense, you can only use it for situations where TS would also work.
- Madden’s Offline Paradox: If you can take a VDI instance "offline," then why don't you just always run it offline?
- Madden’s Client Hypervisor Paradox: If we had all the technology to make client hypervisors work perfectly, we wouldn’t actually need client hypervisors!
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.