What technology makes VDI possible?

In part five of his VDI series, Brian Madden explains which technologies helped create virtual desktop infrastructures.


This article is part five of six-part series exploring the current VDI landscape.

Now that we've looking at what virtual desktop infrastructure (VDI) is and where it can be used, let's roll up our sleeves and look at the underlying technology that makes VDI possible.

At the most basic level, you need a virtual machine-solution on the backend, and you need a way for users to remotely access a Windows XP VM (virtual machine).

Fortunately, Windows XP has terminal server functionality and support for the RDP protocol built in. This is called "remote desktop." So really, any thin client that can run an RDP session can connect to a VM via RDP (remote display protocol) and that VM's remote desktop functionality.

If you've ever used VMware before, you can imagine setting up all these VMs, and then assigning a network name or IP address to each one so that each end user knows what Windows XP VM they should connect to.

This is fine in theory, but would be a nightmare in real life. Specific problems include:

  • All the VMs would have to be on all the time, because if a user tried to connect to a VM that was off, the connection would fail. There is no way for the user to tell the VMware server, "Hey! Power on my VM!"

Of course VMware has a scripting interface, and a lot of the early VDI shops wrote these complex scripts and custom web pages that would look at an incoming connection request and then tell the VMware server to quickly power on the VM for that user.

Over the past several months, several companies have released various products that have addressed this problem. These products can be lumped into the generic category called "Desktop Brokers" or "VDI brokers," and they all work in basically the same way. Like the rough scripts of the early adopters, these VDI brokers receive incoming user connection requests and then route the user to a Windows XP or Vista VM that's all ready to go for them. For the sake of space, we won't go into the details of a broker product here, but Ron Oglesby has written this  fantastic overview.

Desktop broker products can ensure that a user is connected to their desktop VM. Great! Now it's just like a "regular" client-based desktop, with each user running their own Windows XP desktop, except we have some of the advantages of server-based computing.

So what's the problem?

The problem is that if you have 100 users, now you have to manage 100 Windows XP desktop images. One thousand users means one thousand images. You get the idea. This goes back to one of the main disadvantages of VDI in general, and that is that a Windows desktop is a Windows desktop, and if you don't manage it, it will be a nightmare --regardless of whether it is physical or virtual.

The dynamic desktop
Let's take another step back. Remember why Terminal Server/Citrix Presentation Server desktops are nice? It's because we only have one instance of Windows running to support 50-75 user desktops, versus 50-75 instances of Windows XP in a local desktop or VDI solution.



  • You can run the Citrix PN Agent software, so that each user gets a dynamic application list in their Start menu. These icons would then launch ICA sessions to seamless published applications running on other Citrix Presentation Servers.

These are only a few options, but the point is that even though you have 50-75 users "sharing" the same instance of Windows, each user gets their own environment. And why is that? Because a generic template desktop is just the starting point, and that desktop template is dynamically customized with roaming profiles, PN Agent application links, and streamed applications to provide the user with their own unique desktop environment.

The dynamic VDI desktop
By now it should be pretty obvious where we're going. On one hand, VDI is cool in a lot of scenarios, but it's no fun trying to manage hundreds of Windows XP desktops. On the other hand, dynamic desktops are used in SBC environments to provide custom desktops for users based on a single instance of Windows.

What would happen if you could combine these two?

You'd get "the dynamic VDI desktop." Imagine a VDI environment where you get both of these sets of benefits. From a technology standpoint, this means that instead of having one VMware disk image for each and every user, you could build a generic template disk image. This image could be provisioned (on demand) as users connect, and it could be dynamically customized with the user's applications. You get a fully custom desktop for each user with the management simplicity of a SBC desktop. It's truly the best of both worlds.

On top of that, there's another major benefit of the dynamic VDI desktop. That's the fact that the VMs don't need to be created (or even running) until a user needs them. So, if you have 1,000 users, but no more than 800 are ever on at the same time, you can scale your environment for 800 users, and the system will provision and start up VMs as users need them.

Before we continue, it's important to point one thing out. These dynamic VDI advantages do NOT mean that the Dynamic VDI Desktop will replace traditional local desktops or SBC desktops. The dynamic VDI desktop is still VDI, and a comprehensive desktop delivery solution will still involve a blend of VDI, SBC, and traditional desktops.

The "best of both worlds" applies to scenarios where VDI already makes sense. (And in some cases, it might help you decide to go with VDI where you wouldn't have previously due to the daunting management demands.) The idea is that you still decide between SBC, VDI, and traditional desktops, and then for the subset of desktops in your environments where you feel VDI is a fit, you can then further decide whether you want those to be static one-to-one mappings, or dynamically provisioned desktops based on a shared template.

Now it's time to move on to the last part of this series, Practical implementation of the dynamic VDI desktop.


This was first published in February 2007

Dig Deeper on Introduction to virtualization and how-tos






Forgot Password?


Your password has been sent to: