At Citrix Synergy in May, Citrix announce DesktopPlayer for Mac, which is their response to all the people looking to deliver XenClient to Macs. For legal reasons more than anything else, a Type 1 version of the XenClient hypervisor never made it outside the Citrix walls. To get around this, DesktopPlayer for Mac is an OEM of Oracle VirtualBox, which at first glance sounds like Citrix phoned in the effort. The thing is, Citrix had two choices: build Xen to run as a Type 2 hypervisor on the Mac, or partner with someone who has a Type 2 Mac hypervisor that supports VHD files. Short of creating their own solution from scratch that would take years to certify, they went with VirtualBox, so that at least makes sense.
Citrix positions this as a BYOC solution, and while we like to joke that BYOC really means "Bring Your Own Mac," there are still plenty of Windows devices out there that fit into the BYOC category. Interestingly, Citrix's answer to that situation is simply XenDesktop. If you want to use XenClient functionality on Windows devices, you're out of luck unless you want to wipe the box to install XenClient, which isn't exactly a BYOC-like idea. If Citrix wants to build XenClient out as a BYOC solution, they should build management around Client Hyper-V in Windows 8.
Microsoft missed the boat entirely with Client Hyper-V when Windows 8 was being developed. I'll give them credit for adding the functionality into the OS, but the solution itself is only targeted at IT professionals who either want to build out VMs at their desk before rolling them into production or to people that want to run a few test machines at their desk as well. So, while Client Hyper-V is available to almost anyone, and all of those people have hardware that can take advantage of it, only a tiny subset of them will actually use it.
Citrix could build on Client Hyper-V to extend the reach of XenClient to machines that are in the field currently, both employee- and company-owned. Turning on Client Hyper-V amounts to checking a few boxes, which means that deploying XenClient and VMs could be automated without wiping a user's current desktop. No P2Ving physical desktops or up-front extensive migration necessary. Imagine deploying XenClient to a Windows box. It turns on Client Hyper-V, finds a base image, inventories what's on the user's existing system, and ultimately assembles the bits needed to run that same experience in a VM. That's hard core.
This could even do away with the current Xen-based XenClient because Client Hyper-V is a Type 1 hypervisor. If you're using XenClient for its device management capabilities, those would all still be there, just through a more familiar interface. There would be no more weird-feeling Service VM, and the entire experience would feel familiar to both admins and users.
The most important thing, though, is that if Citrix were to switch XenClient to a Client Hyper-V management solution, they would no longer have to try to stay ahead of all the hardware innovations. Currently, they are about three months behind the times when it comes to compatibility with new hardware. That means that this brand new laptop you just got with a Haswell chip in it probably won't work with XenClient until school starts again. There is a relatively small number of people at Citrix that have to learn about the new hardware, then implement the changes into the XenClient OS, hypervisor, and agent, only to start again almost immediately. It's a daunting, never-ending task that seems a lot like the movie Groundhog Day.
By leveraging Client Hyper-V, Microsoft has done the bulk of the work, and hardware vendors write devices drivers for Windows. That frees up development resources at Citrix and saves customers the headache of having to purposely floor out-of-date hardware. From Citrix's standpoint, there might be a lot to do to make this work, but how hard can it be? The main hangup for DesktopPlayer was finding something that ran VHD files. Client Hyper-V already does that, so what's next? Maybe not that much...
(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.