There has been a lot of noise in the past few weeks from companies like IBM, Citrix, and VMware pushing the idea of providing desktops to users in the form of virtual machine-based remote Windows XP desktops instead of the "traditional" way of publishing a desktop session on a Terminal Server or Citrix Presentation Server. In this article, I'll take a brief look at the announcements from the past few weeks and then dig into the pros and cons of this architecture.
Last Week's Announcement (Not the first... Certainly not the last...)
Citrix, IBM, and VMware used the momentum around VMworld to announce their view of the virtualized desktop world, calling it "IBM Virtualized Hosted Client Infrastructure." If you didn't read the press release, here's the short version:
IBM Servers [Blades or xSeries] + VMware Workstation + Citrix Application Delivery = Virtual "desktops" for users that are cheaper than regular desktops
IBM's offering is:
(a) not actually available yet
(b) only available from IBM Global Services consultants
(c) something that other companies have been doing for years
(d) a good move for a huge vendor that suddenly doesn't have a PC business anymore
(e) all of the above
Of course the answer is E.
How will this affect you?
The short answer is that last week's announcement won't directly affect you. However, it raises some interesting questions that are worth considering. It's pretty safe to say that for the past several years, the de facto method of providing hosted desktops to users was to use Citrix or Microsoft Terminal Server to publish a desktop session on a terminal server that users access via ICA or RDP. You end up with huge terminal servers hosting dozens or hundreds of sessions each. The newer alternative is to use a product like VMware or Microsoft Virtual PC to break a server into multiple VMs each running Windows XP, and then to provide ICA or RDP remote access for users so that each user is connected 1:1 to a virtual machine.
Of course this idea is not all that new. I've written about this concept when HP launched their version of it a few years ago (I called it "bladed PCs"), and going back even further I did something like this ten years ago using Cubix hardware blades running Windows 95, PCAnywhere, and banks of modems.
What does this have to do with Citrix?
Ever since Citrix's surprise messaging change a few weeks ago (where they're suddenly calling Presentation Server "application virtualization"), it seems that every new press release that has the word "virtualization" in it also has "Citrix" in it. But where does Citrix fit into this picture? If you have VMware that cuts your server up into a bunch of Windows XP VMs, why don't you just access them via XP's built-in remote desktop capability and RDP?
There are actually several cool ways that Citrix can be involved here. First and foremost, one of the biggest features of Citrix's Presentation Server infrastructure is that they have this great application publishing capability that can securely deliver application access to end users in a variety of different ways. (Icons on a webpage, Start menu or desktop integration, a SharePoint web part, Program Neighborhood, etc.) By tossing Citrix into the virtualized desktop mix, Citrix could then provide access to a user's virtual desktop via these same channels. (It kind of fits into their whole "we provide access to everything" message.) In fact, they could even do cool things like tying this into the Citrix Access Gateway or their GoToMyPC products. This integration is something that Citrix is calling project "Bladerunner." Bladerunner (which was originally announced a iForum a few weeks ago) will also contain some dynamic provisioning capabilities that will help with the logistics of providing workstation VMs to users.
So why would anyone do this? Why give users their own virtual machines instead of a virtual desktop on a Presentation Server?
Advantages of Publishing Individual Virtual Machines
- Better performance.
- No application compatibility issues.
- Better / easier security.
- You can "suspend" individual VMs and then move them from server to server.
- The clients run the "workstation" version of software.
- Users have more control over their individual desktop.
- Users can take their sessions with them when they go offline.
- Easier backups.
Better performance. (In theory, anyway.) Any performance gains might depend on whether your backend is made up of blades or regular servers. Obviously if you only have one user (or a handful of users) on each blade, then your users could run bigger and more powerful applications without negatively affecting as many users as a terminal server environment. If you're using VM software to cut a huge server into dozens of Windows XP VMs, then you will have the ability to partition the resources for each VM in a different way than regular Citrix sessions.
No application compatibility issues. Since each VM is a standalone workstation, you don't have to worry about applications that don't like to have multiple copies running at the same time, and you won't have to deal with Citrix AIEs.
Better / easier security. Since each user would have their own standalone Windows XP VM, you wouldn't have to worry as much about locking down each user's session. If a user screws something up, they won't affect other users.
You can "suspend" individual VMs and then move them from server to server. This would be cool for doing maintenance. Imagine a scenario where you could hit a button in a management console to "move" a user to another server. Maybe the user would receive a popup box that said "Please wait a moment." Then the server would dump the memory contents of their VM to the SAN, a VM would be provisioned on another physical piece of hardware, and the VM would be brought back online. This whole process would probably take less than 30 seconds, and the user would pick up right where they left off. Another use of this technology would be that you could have an additional "timeout" setting. For example, maybe after 20 minutes of no activity, a user's session would be disconnected (where it is still running on the server, but disconnected from the workstation). If the user still doesn't connect back to it after an hour, the system could "suspend" the session by dumping the memory contents to disk, and then free up the hardware for someone else. Whenever the user decided to connect back in, the session would be re-hydrated and the user would pick up right where they left off--regardless of how long it has been.
The clients run the "workstation" version of software. Since these VMs would be based on Windows XP instead of Windows Server sessions, any software or applications would see the sessions as real workstations. You could use workstation versions of all your software.
Users have more control over their individual desktop. Again, since each user would get a full Windows XP workstation VM, they can customize it however they want (or as much as you let them). But as the administrator, you can be more flexible about what you let your users do since you don't have to worry about them screwing up other users.
Users can take their sessions with them when they go offline. Remember that VMware provides a generic view of the hardware to users no matter what the physical hardware looks like. So in an environment where all users' desktops are provided to them as VMs, they could use centralized backend servers when they are in the office, and then use laptops running VMware when they hit the road and need to run offline. There could be a one button "take offline" option that suspends the user's session and then copies down the disk image and memory space to the laptop where it could be resumed. You could even have generic laptops that users could "check out" when traveling. Imagine VMware ACE with the flexibility of running remotely or locally, and easily switching back and forth.
Easier backups. All you would have to do is to backup the disk image files for all the user's workstations (and these are probably already on a SAN). Then if a user lost something, it would be simple to "roll back" their laptop to whenever they wanted. You could even take this a step further and provide an automatic snap-shotting service that did this once an hour.
Disadvantages of Publishing Individual Virtual Machines
- More server hardware is required.
- More software is required.
- Management tools are needed for the desktop VM.
Of course with all of these great advantages, there are several downsides to providing desktop sessions via Windows XP VMs to your users.
More server hardware is required. Giving each user a full workstation VM will require more computing resources than simply giving them a session on a terminal server. A dual processor server with 4GB of RAM can probably run 100 desktop sessions as a terminal server. With VMware, you're probably only looking at maybe 20 Windows XP VMs. If you're using blades, you might only be able to fit a handful of users on each blade.
More software is required. In addition to your OS and application software, you'll also need the VM software (from VMware or Microsoft) and you'll need some software to manage the provisioning of VMs for users (Citrix Bladerunner, etc.). Of course this will also cost more money.
Management tools are needed for the desktop VM. Since this model is more like "traditional" desktops in that each user has their own Windows XP VM, you'll need tools to manage patching, antivirus, spyware, software installations, and configuration management.
Integrating published workstation VMs into your environment
Like I said when I wrote about Bladed PCs, this solution doesn't really compete with Citrix published applications, it competes with traditionally-deployed desktops. You could certainly access a Citrix published application from within your remote Windows XP VM session. (This would use Citrix's ICA passthrough technology which works very well.) In fact, you could still use technologies like Softricity or Citrix's Project Tarpon for desktop application streaming--it's just that in this case, the application would be streamed to the Windows XP VM instead of a physical desktop, but the same design questions would still apply.
With all this discussion, there's still one major point that we haven't touched on that I'd like to go back to:
What do you run the backend on--blades or huge servers?
At first you might think that you can skip the whole VM thing and just use blades on your backend to provide a 1:1 blade to user ratio. While that's certainly possible, it not ideal in today's world. If you use blades, you should still use VM software to virtualize the desktop sessions running on each blade. Why? Two reasons:
Depending on your applications, you can probably put more than one VM on each blade. (Not a lot more, but maybe three or four.)
By using a VM solution, you can still separate your OS image from your hardware. For example, you could have a SAN full of disk images--one for each user. You could then have a rack full of blades sitting right next to it. When a user logs on, the system grabs the next available blade and boots a VM on it with that user's disk image on the SAN. What's really cool about this is that the user's "personal" network shares (My Documents, etc.) could all be "local" within that disk image since that disk image is already on the SAN and highly available and backed up. This would allow you to realize the full list of advantages of this architecture previously listed.
Quite honestly, I don't really see the blades vs. traditional servers as all that important in this case. I think that if you choose to go with this Winodws XP virtualized desktop architecture then it really doesn't matter what you have on the backend. You'll be able to buy whichever makes most sense in your case.
I have to say that I like the idea of a virtualized Windows XP desktop more and more. In fact, I have a Citrix server in my environment that I use for applications, and I have a few huge VMware servers I use for lab testing and training classes. My laptop just broke over the weekend, so I think I'm going to build a remote VMware-based Windows XP desktop and try using that for awhile to see how this works. I'll try running it locally and remotely.
The bottom line is that I like this idea a lot. If I had to provide full desktops to users, I think this is something worth considering. Again, it's not the right solution for everyone, and it certainly will not replace Citrix and terminal server applications, but it's an interesting option that offers some unique advantages that are simply not possible with other architectures.