Citrix tries to explain XenClient to Their Friends at VMware
The buzz around XenClient at last week’s Citrix Synergy conference in San Francisco was simply amazing. Customers on the show floor were excited. Partners like Intel, Dell, HP, Microsoft and McAfee talked extensively about its significance. And thousands of IT pros flooded our download sites to get their hands on the XenClient Express test kit to start giving us their early feedback.
Just about everyone who has been following this industry closely, in fact, seems to understand the game changing significance of bringing bare-metal hypervisors to client devices. They realize that technologies like XenClient introduce an entirely new level of security, manageability and flexibility to the world of desktop virtualization. They love the idea of being able to run more than one desktop on a corporate-owned device. And they understand the power of giving corporate laptop users these virtual desktops “to go” that work when the user is disconnected from the network, then automatically synch all changes whenever they’re connected.
The only ones who don’t seem to quite understand the value of XenClient, in fact, are our friends at VMware. Following our announcement last week, they posted a rather interesting blog with a blow-by-blow critique of XenClient based almost entirely on the premise that bare-metal virtualization isn’t practical for employee-owned devices in a BYOC (bring-your-own-computer) arrangement.
Uh… yes, guys… we get that. With all due respect, however, it kind of misses the point though, don’t you think? While we certainly agree with your observation, dismissing XenClient based on its fit for BYOC is a bit like saying that compact cars have no value because they’re not good at hauling lumber or towing boats. Maybe we’re missing something here, but with laptops now comprising nearly 40% of all corporate-owned devices – and growing every day – it seems to us that giving customers a solution which securely and seamlessly extends the benefits of desktop virtualization to millions of corporate laptops is a pretty big deal.
Some would say VMware’s sudden distaste for bare-metal client hypervisors after their high-profile announcements last year is not because they don’t get it, but is simply a reflection of their own struggles to deliver a viable product in this space. I’ve even heard a few cynics refer to their much-hyped CVP (client virtualization platform) as the “Canceled Virtualization Project” based on unconfirmed rumors that it has been all but shelved, at least for now.
Knowing firsthand how challenging it is to deliver a bare-metal client technology like XenClient, however, I’m more than willing to give VMware the benefit of the doubt on this one. After working on CVP for more than a year, I’m sure they have a far better appreciation now for how challenging a project like this can be… especially when you’re essentially trying to go it alone as they are. Even with our more than 20 years of experience in desktop computing, we could never have delivered something as groundbreaking as XenClient without the tremendous collaboration of partners like Intel, HP, Dell, and the open source Xen community, as we shared with Synergy attendees last week in our “Making of XenClient” video.
Perhaps the reason VMware seems a bit confused about all this is simply because doing anything at scale on the desktop is still relatively new territory to them. Desktop virtualization is, after all, far more than just VDI… and it’s radically different from their bread-and-butter world of server virtualization. Or perhaps we just didn’t do a good enough job in explaining everything last week. It certainly wouldn’t be the first time. While we spend a lot of time trying to come up with the right words to explain our products and strategies clearly, I’ll be the first to admit that we don’t always hit the mark – especially with something new like this.
Whatever the reason, I thought I’d take the opportunity to offer a few key points to (hopefully) clarify the role of XenClient as we see it today, as well as our views on where it fits into the big picture vis-à-vis things like BYOC and type-2 hypervisors.
A Few Key Points about Client-Side Hypervisors
1) Bare-metal hypervisors offer unparalleled security, performance, management and flexibility for corporate-owned laptops – Bare-metal client hypervisors (often referred to as “type 1”) allow multiple completely isolated virtual desktops to run on a single corporate owned laptop. With only a thin layer of software between the virtual desktops and the hardware, they can deliver new levels of performance and security that are simply not possible with other types of client hypervisors, by directly accessing hardware subsystems at the microprocessor level. This architecture also allows for strong isolation between the virtual machines, essentially putting a brick wall between the virtual desktops. As a result, security or resource issues in one virtual desktop can’t affect the others.
2) Type-2 hypervisors have a role too – As excited as we are about XenClient, that doesn’t mean we don’t see a valid role for “type-2” client hypervisors that run on as guests on top of a traditionally installed local desktop OS. Solutions like Parallels and VMware Fusion, for example, can be useful in giving consumers who don’t have the luxury of an IT department an easy way to run Windows on their Mac. And in an IT environment, type-2 hypervisors like Microsoft’s Virtual PC, combined with the management capabilities of Microsoft MED-V, can offer a promising solution to app compatibility challenges for customers moving to Windows 7.
3) No matter how many times we hear it, the concept of “Checking-Out” a VDI desktop to run offline still seems like a highly questionable scenario – Maybe we’re missing something here, but if this is what VMware is planning to position as their answer to XenClient in the upcoming View 4.5 release, I have to admit that we still don’t get it. The idea they have promoted in the past goes something like this. First, IT gives everyone a traditional VDI desktop running on the server. Whenever a user needs to go on a trip, they simply “check out” their desktop by downloading it from the server and installing it on a type-2 hypervisor on their laptop. Sounds like an interesting idea, until you realize that downloading an entire VDI desktop when it’s time to catch a plane could easily take an hour or more. Even if users do decide to go through that hassle once, why would they ever bother to upload their desktop to the server again when they get back in? If the end result is simply a bunch of laptop users running around with desktop VMs on type-2 hypervisors, how again is that better than the far more secure, fast, manageable bare-metal approach? It may work in the lab, but we somehow have a hard time believing many CIOs will consider this so-called “offline VDI” approach a serious option for large scale deployments.