There’s a fair bit of buzz about the debut of XenClient at Synergy. I’ve been living my desktop life on XenClient since December 2009, and I thought I’d share some experiences with the current release, named Stewie, and offer some views on the use cases for rich-client desktop virtualization. If you’re a follower of Family Guy, you’ll know that:

Stewie is a one-year-old with a very sophisticated psyche. He reached his first birthday in the season 1 episode “Chitty Chitty Death Bang”, and has remained the same age ever since. His nature and mannerisms are nice with typical childlike interests and actions. While highly literate and able to cite pop culture references that date much further back than his age would let on, he is also entranced by Raffi and the Teletubbies.

You probably can’t see how relevant this all is to client hypervisors, but Stewie would probably be a great recruit for the XenClient dev team, given his technical talents. And at Synergy, Stewie will be on show after a long bake in the dev group and with our private beta users.

Perhaps you noticed that in the first paragraph I used the term “rich-client desktop virtualization” and not “rich client hypervisor-based desktop”. The term “desktop virtualization” is used broadly to describe the category of next-gen desktop and application delivery, and so implicitly covers server-hosted apps (XenApp 6) and VDI based Desktops (XenDesktop 4) VDI Edition, as well as a broader set of client-side virtualization technologies that enable us to exploit rich clients while delivering user experience, security and manageability benefits. Here are a few

  • Windows 7 native client: App Streaming(App-V), Profile Virtualization (Roaming Profiles) & Windows Folder redirection, coupled with Citrix Dazzle and Receiver allow you to self-subscribe to apps you need, and manage your data.
  • Windows 7 native client, with a need to use a legacy Windows XP app that doesn’t run on Windows 7: Either MED-V to run the incompatible app as a seamlessly meshed client-local VM that appears to be an app, or XenApp to gain access to a hosted implementation of the app in a VDI-style hosted XP VM
  • BYO Windows 7 PC or Mac: A user-owned device running Windows is brought into the corporation to run corporate apps/desktop. Since the corporation doesn’t manage and can’t trust the Windows instance on the device, hosted desktop/apps using XenDesktop 4 makes most sense. Also, if the device is a laptop, this permits the user to gain access from anywhere that they are connected to the net.
  • Corporate PC with “separate worlds” for corporate and personal use: Uses a client-side hypervisor to offer the user a less- or un-managed personal VM where they can use personal apps, store personal data and state, and browse freely; and a corporate VM that is locked down, with limited or no user app installation, and all corporate data and state properly managed. For this one could consider using a type-2 hypervisor on the client (VPC, VirtualBox, ACE, Fusion), however security concerns would dictate that:
    • The personal VM runs on a type-2 hypervisor hosted by of a well managed, secure, native OS – Windows 7, and specifically NOT the other way round: No point in having a locked down corporate desktop running on top of an untrusted user-managed host.
    • Given documented vulnerabilities of type-2 hypervisors (eg: VMware player), whereby a hosted VM could attack the host, one might not want to pursue type-2 virtualization at all for this use case, but rather:
    • Use a type-1 hypervisor (XenClient) to force isolation & protect both VMs from each other, as well as extend isolation into the network (Personal VM traffic gets injected into a separate VLAN and pushed outside the firewall)
  • Subset of the above: Corporate PC that is required to run multiple corporate desktops with different security / policies covering user access, on a type 1 XenClient hypervisor. This is more typically known as “Multi-Level Secure” (MLS)
  • Finally, there’s the ability to stream to a rich client the OS that it needs to boot, over a wired network.

This list is by no means comprehensive (I think in general it’s subjective), but the key point is that XenClient is intended to address a very specific use case: users who need multiple isolated desktops on a rich client. Isolation means that, for example:

  • Copy and paste between VMs doesn’t work
  • One VM cannot snoop network traffic from the other
  • Even in the case where apps from one VM are shown in “seamless” mode on the desktop of another, you can’t print what’s in the app windows
  • Keystrokes/mouseclicks (and in future, gestures or other input devices) are exclusively owned by a VM at any time, to prevent snooping by an attacker in the other VM This use case is therefore the polar opposite of Microsoft’s with MED-V, where the delivered app-compat XP VM is as completely merged with the state of the native host OS as possible.

OK, back to Living the Vida Local, and my experience of XenClient. During the Stewie development and pre-alpha tests an occasionally flaky build would mean that I would lose my VMs completely. Bit annoying but not particularly so since my VMs have always been stateless anyway – all my user state is continually backed up. I have to admit that I often found myself booting only one VM – the work one – because the boot time for two VMs is rather tedious, and two VMs chew more battery than one. But if you’re only going to use one VM, what’s the point in having a hypervisor? Then there was the annoying “sleep causes guest to lose time” bug (which has occasionally beset other virtualization platforms too), that meant that I was late for all my meetings for a while.

I also found that my behavior is perhaps more idiosyncratic (it definitely is idiotic) courtesy of my tech-focussed role and the Citrix embrace of client-side “any-ness” such as our BYO policy: I wanted access to my personal state and apps, even when I only had one VM running, so I started using GotoMyPC to get back to my Mac at home, from my corporate VM running on XenClient. What a mess! This was not what we were after.

Now that XenClient “Stewie” is getting ready for exposure to a larger set of users, the power management is excellent – there is some secret sauce at work that I can’t disclose yet – the bugs are (hopefully) all fixed, and the only real limitation for multi-VM use is the boot time. This I suspect will be addressed over time as client devices become more powerful and support virtualization better. There are still quite a few user experience quirks such as limited multi-monitor support and knowing how to get printing to work, but the system is very usable. My initial user experience issues, such as a scheduler interaction that messed up Microsoft OCS and Skype performance, and having to figure out how to get my 3G USB device to work by and manually inserting the driver, have mostly been addressed. But issues such as this are a good reminder of how challenging it is to address all devices and still deliver great user experience – something that we have all taken for granted in Windows for so long. Support for sleep states, power management, and feedback on useability have helped enormously. During the Stewie development project we have started to learn just how painfully hard a job it is to build a client-side type 1 hypervisor, and reminded that we still have a way to go. Thankfully our architecture specifically aims to pass as many devices as possible directly through to Windows, which is a help.

In summary: Stewie is a great kid, but remember he’s only a 1 year old, and still loves the teletubbies.