Virtual Desktop Infrastructures (VDI): What's real today, what's not, and what's needed

Over the last several months, the concept of a Virtual Desktop Infrastructure (VDI) has become the buzzword in a lot of IT shops. Organizations are using (or looking to use) VDI to solve a number of issues they are facing.

Over the last several months, the concept of a Virtual Desktop Infrastructure (VDI) has become the buzzword in a lot of IT shops. Organizations are using (or looking to use) VDI to solve a number of issues they are facing. Of course, for the last year I’ve been talking about what VDI is missing in order to make it a real solution and why it can’t beat Terminal Server in a lot of cases. Well, maybe I have seen the light. I mean for some problems, VDI is a perfect fit. For others it’s not so perfect but is still being crammed in nonetheless because someone hates Citrix or TS (or just loves VMware).

In this article, we’ll quickly go through an example use case that a VDI solution will fit almost perfectly and the types of use cases where it doesn’t fit. (When VDI doesn’t fit it’s generally for cost reasons. I mean it would be great to have multi-node clusters for every server on the network but we don’t do it because of cost.) Once we look at the history of SBC and when to use VDI, I’ll then draw a “pie in the sky” VDI solution from the bottom level (the VMs) all the way to the top level (the management tools). I’ll note the components of the solution that are already available and, more importantly, describe in detail the components do not exist yet that are being looked at by numerous vendors.

Before we get started, I want to point out that a number of organizations are implementing or have already implemented VDI solutions. For the most part, these solutions have been cobbled together with scripts, snips of custom code, hacking of existing products, and of course good old duct tape. This article describes a theoretical solution that could be implemented by a single vendor or two with a couple of core technologies, I am NOT saying that the items I say don’t exist can not be accomplished with hacks and tricks—it’s just that no solution on the street has been developed as a package to address specific VDI shortcomings.

What is VDI?

First let’s describe VDI from a high level and compare it to more traditional server-based computing models.

The image on the right shows a traditional SBC model. The users all have access to a desktop GUI via an individual session on the terminal server. This server has a single OS installed; an instance of Terminal Services to provide the sessions and session management, and a set of applications that can be used by all the users on the server.

In the VDI model on the left, a single server is used again, but a hardware virtualization layer is added to this server in place of a more traditional OS like Windows Server. The Virtualization layer provides numerous Virtual Machines that are each supplied with an operating system, applications, and a unique GUI / desktop environment for each user.

As you can tell by the image, a VDI solution provides the same basic functionality of a traditional SBC solution. This functionality is (primarily) to provide a centralized desktop via a protocol like RDP or ICA. Besides the Virtualization layer and numerous OSes, the two solutions look almost identical. (The key word is ’almost’.)

With VDI you gain a couple of benefits that you cannot achieve in a SBC environment, including things like:

  • The ability to provide a unique environment for each and every user.
  • Each of these environments can be completely customized with different apps and settings without impacting other users.
  • Users can be granted more control of their own “virtual” desktop to allow them to install and modify applications if needed.
  • Applications that were not multi-user friendly (i.e. “we cant get this to run on Citrix”) can be run in this environment since each instance is just like installing the app on a new desktop.

The problems start when you think about the solution from its very basic components. Let’s say your boss decides that you need to provide 100 desktops to developer users in India. Each developer needs local admin rights, the ability to reboot the machine, install apps, etc. Basically every one of them must have their own machine. A few years ago the only way to do this would be to buy 100 desktops, stack them in a room or in the datacenter, load up PC Anywhere, Dameware or some other remote control solution, and tell them to go to town. Of course right now you’re frowning at the thought of this, but really is a VDI solution that much different? You still have the same number of OSes, you still have the same number of application installs, you still have to use some type of third party software to get your users connected to the machines, remote printing is going to be an issue and so are peripherals, etc... Starting to sound kind of lame, huh?

The truth is it’s not that lame. Virtualization has allowed you not to have to buy a hundred new boxes and instead get maybe 4, 5 or 6 servers and create the target machines as virtual machines. This, of course, could drop the solution cost pretty significantly.

This leaves you with several issues that need to be solved, including the connectivity, application installations, application upgrades, OS management, VM provisioning, load management, and of course performance monitoring/management and maybe even a number of peripheral issues. Also (with today’s virtualization technologies) you need to put those VMs (encapsulated in files) onto a SAN if you want redundancy. If not the loss of a single server can create the loss of a large number of VMs and their customizations from the users.

As you can see the basic infrastructure is available to provide the platform. The connectivity and management and other surrounding pieces are missing in order to make this a really competitive solution.

<Preachy Rant>
Before I get too far I should note that I believe that VDI is NOT a Citrix replacement in 95% of the use cases, but instead is a solution that fits specific needs and most likely will run side-by-side with terminal servers to fill these needs. VDI is a powerful/useful technology for UNIQUE desktops or apps that will not run on Citrix or on Citrix via an application virtualization software like Softgrid or Citrix’s AIE technology. If you want to host a call center and all the machines/desktops should be identical with little to no modifications possible, buy a terminal server, have it set up correctly, and save the money by using VDI for unique PC deployments or those “no way it runs on Citrix” applications.
 </Preachy Rant>

Okay, so you’ve decided that you need to get these 100 desktops done, but PCAnywhere is so 1999 that you just have to jump on the VDI bandwagon. What issues / needs are you going to have to address, and where can the software come from to address these needs?

Let’s start with a “pie in the sky” view of a perfect VDI solution:


In the perfect VDI solution, you would see an easily managed (one or two tools) environment. If you use Citrix and Terminal Server as your starting point then it’s easy to see what you need. The Perfect VDI solution would have or support the following:

  • Session load balancing of “pooled” VMs that are identical.
  • Capabilities to have unique VMs for specific users and still allow them to connect to pooled VMs if needed.
  • A secure way to access these desktops remotely.
  • A management tool that would allow you to see/manage the following:
    • Locate users (which pooled VM are they connected to)
    • Show connection information (where are they coming from how long have they been connected)
    • Timeouts for session active and disconnected times
    • Ability to reset or remotely reboot a VM
    • Ability to pull a VM out of the pool for maintenance or troubleshooting
    • Centralized way of publishing and establishing security for the VDI connectivity
  • A connection method that allowed for the “easily” supported printing and peripheral environment.
  • Ability to add to the pooled VMs resources as load increases WITHOUT having numerous VMs sitting around idle and eating resources. This is akin to dynamic VM creation
  • A way to centrally patch and maintain the pooled VMs that is easier than managing a bunch of unique desktops.
  • Better peripheral support, specifically, printer mapping and management.

When you begin to look at the ideal VDI environment you begin to see it is almost IDENTICAL to a current Citrix or Terminal Server deployment except for the fact the VDI environment has an OS and app instance per VM. This is where the solution begins to loose some of its coolness. You now need to install an OS and its apps, and manage, update, and patch the OS, and the apps for each VM. There may be some ways to simplify that, but before we go there lets look at some of the key features that are needed in a perfect VDI solution, how they are being done today, and how they should be done.

Session load balancing of “pooled” VMs

In most VDI deployments this is not being done (or at least not being done well). In some cases administrators are manually mapping users to VMs by giving the user an IP address or computer name and having them connect via the RDP client. The connection method varies. Some use an RDP file deployed to the user’s existing desktop, some use thin client configured to use a CE based RDP to connect to the desktop, and some companies are hacking/faking out software used for load balancing TS sessions to load balance XP desktop sessions.

What we are talking about is a management tool that allows you to add a list of computer names into a central tool. You would assign that pool a name and then assign permissions to that pool to groups of users. Pie in the Sky would be to even select specific or users or groups of users and allow them to connect to the pool and give them the OPTION to save their VM for later use or not. This would give certain power users the ability to spawn a unique VM from the pool for later use where task-based workers may not receive the option at all. This could also be useful if you have a base image that all users would use (unique and pool users). In another case you could assign multiple groups of users to the pooled resources. Then have the option to allow a submit (unknown to them) to automatically be spun off into a unique VM where session settings and changes are saved. In this case each VM starts with the same base image but only groups or users that are assigned get to “keep” their VM from the pool.

Ability to have unique VMs for specific users and still allow them to connect to pooled VMs if needed

This may sound silly, but the concept of running multiple desktops (or applications) is nothing new.  I mean let’s assume your environment grows a bit and you use VDI for some type of custom application that conflicts with everything including notepad. Now you have a user with a thin client (or fat) that connects to their custom desktop that they’ve been using for a month or two, they’ll also need access to the customer application and thus its pooled desktop. This needs to be done easily, meaning that you need an easy connection method, maybe a web interface that allows the user to select a desktop from the ones they are authorized to use or the ability to directly launch the second desktop from within the first (and still support any peripherals needed).

Right now people are using the RDP client to connect to an XP Pro VM. Then they are either establishing another connection with RDP client from their desktop or not doing it all. This will not work in the long run. (I once had to change about 500 users Program Neighborhoods over to published apps and NFuse because these multiple connections where a nightmare.) As VDI expands, this too will become a problem if there is no centralized brokering mechanism.

A secure way to access these desktops remotely

Let’s face it, a lot of the VDI solutions being implemented are for outsourced developers. Not all mind you, but enough that remote access (or should I say secure remote access) is an issue. The basic idea is that the end user needs a simple yet secure way of accessing the desktop that won’t require the hosting company to drop a bunch of software on the remote client. This screams clientless SSL VPN, or possibly SSL encryption built into the VDI desktop client. In addition it means a software package that is Internet facing that could (or should) integrate with some different types of backend directories (e-dir, AD, maybe throw in SecureID).

How are people doing it now? “Hopping” is the only way to describe it. In some situations companies are publishing the RDP client in Citrix. Users then come into a Web Interface server, login, run the RDP client published app, get routed through a Citrix Secure Gateway into a Citrix session running the MS-RDP client, and use it to launch the RDP session to the XP Pro machine. This is essentially a double hop. It works, but it causes overhead, requires a Citrix license just to run the RDP client, and is basically one session for the price of two.  In other cases, companies are creating firewall rules and VPN connections to allow users to open TCP 3389 from their PC to the XP Pro box. When doing this it’s often a multi-step process for the end user (we know how that works out) or requires you drop a package on their desktop and support it.

What would be ideal? A single hop that integrates both the session brokering and session connectivity without a middleman. (Think of a secure connection to the XP Pro box that looks like an ICA session to a Citrix Presentation Server.)

I know, I know, I’m comparing a bunch of this stuff to Presentation Server. But hey, if something works, model after it, don’t re-invent the wheel.

A complete management tool for the environment

One of the funnier things I see in the VDI realm is that the Non-TS guys kind of have to re-invent all the hacks that Citrix and Terminal Server guys had to do in NT 4.0 and the early days of Server Based Computing. For you old timers, you’ll remember changing the “My “ icon on the session desktop to %username% on %computername%. Well I’ve seen them doing these in XP Pro VMs. Why? There is no management tool to easily tell you which user is connected to which VM, how long have they been connected, or what is the state of their session is.

These are simple things taken for granted in Citrix and TS since the tools have been there forever. A huge step in VDI would be a tool that looks like TSAdmin.exe or MFadmin.exe but is geared towards the VDI market. (Of course I just had to geek out and make a mock up one that you can see below).

Yeah, I know it looks like a TS admin tool, and it’s supposed to. The same concepts you’re familiar with in TS also apply here. The difference is that this tool would need to show the resource groups available, the individual virtual machines available, and of course the users connected to them. In addition I think such a tool (with the rest of the required infrastructure) should be able to:

  • Locate users (which pooled VM are they connected to)
    • Very important for troubleshooting and security reasons
  • Show connection information
    • Right now this is not being done or being done by login scripts that note the login time and username in a central access DB for logon and logoff times.
  • Should allow session shadowing
    • this could somewhat be done today with Dameware on the machine and the end user connecting via RDP
  • Timeouts for session active and disconnected times
    • Some would say you could use domain timeouts (and I already got an e-mail, thanks) but we are really talking about a session open for 29 hours by a single user. How do you know when that happens?
  • Ability to reset or remotely reboot a VM
    • Absolute must. I would say you need hooks from this tool to reboot the VM maybe suspend, obviously take it out of the pool of resources, and possibly to log the user off the VM cleanly. Right now people do this by accessing another tool (like with Vmware’s Virtual Center or VS 2005’s web interface, but I would want the application to be able to call the APIs and from this console handle the shutdowns and restarts)
  • Ability to pull a VM out of the pool for maintenance and or troubleshooting
    • Noted above but is a must.
  • Centralized way of publishing and establishing security for the VDI connectivity
    • Today people are basically doing a one-to-one ratio (VM:User) or hacking together load balancing from other tools. That’s great until you have a centralized way of getting at the desktops and need to restrict Suzie in accounting from seeing the comptrollers desktop remotely. I mean how many of you actually set the local logon rights on desktops? It would be a pain to manage on lots of images.

A connection method that allowed for the “easily” supported printing and peripheral environment.

Yeah. VDI is great until someone prints. Sure there are some ways to get network printers working easily, but then there is the guy in India with a brand new MFC made by some no name company in China, connecting to a desktop in London. Send his support call to Timbuktu because you’re not going to get that printer to work easily.

I would begin to look seriously at some third party companies like ThinPrint for solutions, because I just feel this is going to be a huge issue.

In addition to making printing at least meet the standards of today’s Terminal Server and Citrix environments, you’ll be looking for peripheral support so Suzie in accounting can sync her “CrackBerry” with her desktop. Don’t laugh! If you get VDI running, people will begin to ask for that stuff.
Ability to add to the pooled VMs resources as load increases WITHOUT having numerous VMs sitting around idle and eating resources

This is akin to dynamic VM creation. One thing that has always bugged me about VDI is that it FEELS like WinFrame. Basically if you need to support 30 Concurrent sessions you have to have 30 VMs sitting there whether all 30 are being used or only 2 are being used. Right now this is how most VDI solutions are setup

Now this may not seem like an issue but there is a reason that later version of TS moved to a listener model; it was to reduce the amount of resources used by idle sessions (and these were just virtual sessions within an OS, not the whole OS itself sitting there).

The solution would be to find a way to QUICKLY (read less than 15-30 seconds) provision a VM that’s ready for use. I’m not sure how to do this yet, but its one solution. Another solution (or workaround) would be to determine max load in the farm in any, (say 15 minute) period. If you could accept 6 new logons in 15 minutes then the minimum number of VMs available would be 6. When one is used by a user logging in, another would be created. The one being created would still have a 5 VM buffer before any users tried to get to it.  Now this would be a pretty intense solution, and not elegant by any means, but it’s probably just one idea of 100 that other people have to solve this issue.

A way to centrally patch and maintain the pooled VMs that is easier than managing a bunch of unique desktops

Yeah, now you’ve just added a bunch of VMs to your environment that you need to patch and upgrade constantly. Sure you can dump WSUS in there for Patch Tuesdays, or you can use your existing SMS infrastructure, but there is obviously and added cost for this. 

Today most people are doing that; using existing tools. Personally I think that if the previous issue is solved (a way to quickly provision VMs) then we will solve this. I mean if the VMs are built and broken down all the time, and when built come from a centralized template for the pool being published, then the template would just need to be updated and through the life of the VM (logon and logoff) the VM would be created with the new patches. This of course solves the problems for pooled VMs, but not unique ones. You still need to manage those just like desktops.


Will VDI take over the world? I doubt it. I think it will have its place just like other “Virtualization” technologies like Citrix and TS, Softricity and AppStream, etc. VDI has a place and will solve issues, but it’s just that—another solution to a problem. It’s not the solution to all of our problems. Right now VDI is in its infancy. Those that go down that road are bound to have to jump some serious technical hurdles to create an easily managed system. Just like the first multi-user systems, VDI will solve your problem today, but will be hard to manage compared to some other systems and require some learning curve for your staff. Hopefully over the next few months vendors will get on board and make some of the technology a reality. Citrix is supposedly working on something to help with brokering of the sessions in a more elegant fashion, but that is for another article.

If you have other VDI challenges or solutions you want to note, post to the comments section of this article. VDI is new, and no one has all the answers. That’s what makes it fun.