It’s been a long long time since my last post, and much has happened since then in the desktop virtualization space, both for Citrix and in the wider industry. At the time of my last posting (December 2006, no less!) we were seeing the first attempts to virtualize Windows-based desktops, using home-grown and relatively simple “brokers”. Typically, they would use straight-forward one-to-one mappings between end users and their virtual desktop, perhaps based on the user’s login identity and their virtual desktop’s IP address.
Since then, we have made great strides to deliver more sophisticated solutions for desktop virtualization, and a first batch of products have been released from vendors such as VMware (VDM, courtesy of their acquisition of Propero), Quest (via ProvisionNetworks), Leostream, and others (there’s a good overview available from it2.0). And of course we delivered Desktop Server 1.0 last year, and have now just made a beta version of XenDesktop 2.0 available for download.
A great deal has happened here beyond the obvious name change, and our vision for this product has undergone major shifts over the past year or so. I’d like to use this post to bring you up to speed on how XenDesktop differs from Desktop Server and also many of the other desktop virtualization products.
First and foremost, while Desktop Server 1.0 was a broker that mapped end users to virtual desktops, XenDesktop provides a much more comprehensive approach to delivering desktops. A broker by itself is all very well. It allows you to migrate desktops into the data center, with all the benefits this brings in terms of preventing data loss (remember all those news stories about stolen laptops and hard drives and optical discs getting lost in the post?), reducing downtime, and gaining visibility and manageability – provided you have appropriate tools and processes in place to manage the sprawl of what will typically be VMs that host your virtual desktops.
Of course a desktop virtualization strategy can also introduce new headaches. For instance, you need to think hard about what moving your end users’ desktops into the data center means for the security of other assets in the data center - you’ll probably want to consider a strategy that fences off virtual desktops from other services and data hosted in the data center. More than that, though, moving desktops into the data center by itself doesn’t solve some of the big management problems – you still need to worry about image management, patches, anti-virus, and on top of that you have to keep an eye on the health of the desktop virtualization infrastructure, whether this be XenServer, VMware, blade PCs, or other desktop hosting technologies. Finally, all the images for your virtual desktops need to be stored somewhere, and with multi-GB disk images, this quickly adds up to a substantial storage cost.
XenDesktop includes technology that will help you to tackle these complications, and help you get a long way towards reaping the promised benefits of desktop virtualization (well, that’s my sincere hope anyway). Here’s how we envisage a successful desktop virtualization strategy to play out:
- Lock down your end user’s endpoint devices, or better yet, replace them by Desktop Appliances (the new term for thin clients that are specifically designed to take advantage of desktop virtualization). This minimizes the maintenance overhead and reduces the risk of end users misconfiguring or otherwise breaking their devices. We’ve designed XenDesktop’s end-user UI so that this step becomes as painless as possible for end users: after switching on their device, end users enter their credentials and XenDesktop takes over, connecting them straight to their virtual desktop. Depending on your deployment, this uses a combination of Web Interface and Program Neighborhood Agent technology under the covers, but this is entirely transparent to end users.
- Take advantage of the migration to centrally hosted desktops and consolidate and rationalize the OS images for your end users. Ideally, you should end up with a small number of “golden images” that contain only the base operating system, as well as perhaps a few universal applications that all your users need, e.g. a standard browser or email client. The idea here is to separate the base OS from applications and user data, and hence make it an entity that can be maintained and managed independently and separately, and hence more effectively. Citrix Provisioning Server (also known as PVS – you may be familiar with it under its previous label of “Ardence”) provides the required technology here, and is conveniently included in XenDesktop.
- PVS is used to create and store golden images, which are then shared among VMs, or even blade PCs. In other words, if you have 100 users all using the same base OS, you only need to store the image on disk once and PVS will stream it to the VMs hosting your virtual desktops, on demand. The VMs (or blade PCs) themselves can be entirely diskless, and this can add up to a tremendous saving in storage cost. What’s more, PVS makes managing golden images is made a lot easier as well: if you need to patch your base OS with the latest service pack, you only do this to the golden image. Restarting the VMs suffices to apply the new image across the board. And if the service pack update goes wrong – no problem, it’s trivial to switch back to the previous version of the image. PVS and XenDesktop will also automate the management of AD computer accounts, hence there’s no need for sysprep or other tools, and adding a new virtual desktop is done in seconds: create a new diskless VM, add it to PVS’ client list, and let PVS manage the new desktop’s AD account.
- So now you have a very manageable environment that you can use to deliver generic desktops based on golden OS images to your end users. But your end users will need applications to carry out their daily work (remember, don’t include too many apps into the base OS image, because then you need to manipulate that image every time you need to change or update one of these apps). This is where application streaming or “client side virtualization” comes into play; I’ve briefly touched upon this in my previous post: using XenApp technology, you can deliver applications transparently to your end users, without having to touch or “pollute” the golden image. This allows you to get away with a small number of golden images, even if your users have differing needs with respect to the applications they access: just let XenApp (or alternative technologies) deliver applications to users based on demand.
- Finally, users also need to store data and configuration or personalization settings. Again, these must be separated from the base OS and also the applications, in order to make the entire system manageable and effective. Right now, you’ll have to use off-the-shelf solutions like Windows roaming profiles to store and manage data and settings separately, but naturally we recognize this as a gap and are working towards offering a solution that’s integrated with XenDesktop in the not too distant future.
To recap, XenDesktop has evolved significantly from a broker into a fully fledged desktop virtualization solution that combines a broker, ICA’s high-performance remoting protocol (courtesy of PortICA), virtualization infrastructure (and before you ask: yes, XenDesktop works well with a VMware and Microsoft virtualization infrastructure as well, although of course we’d prefer you to use the XenServer technology that’s included in XenDesktop), image management and OS streaming, a set-up tool for wizard-driven provisioning of diskless VMs with OS streaming, and more. If you want to dig deeper, check out the official XenDesktop product site where you can also download the beta, and join the discussion forums for support.
For my next post I’m planning to go a bit more technical and describe one of the areas that has generated many questions for the beta: how XenDesktop works with AD.