With the advent of Cloud Computing, the IT industry began making promises that 2009 would be “the year of VDI”.  So here we are in 2010 and as the major hypervisor makers are working diligently to thrust themselves into the desktop marketplace (significantly larger than the server market; VMware, Citrix), I thought it was a good opportunity to lay out a few concepts to frame the discussion of VDI.

At the most basic level, VDI technology is a new method for delivering desktops to users.  Of course users have been using desktops for years, at first running locally on their own PCs, and more recently by accessing remote server-based computing (SBC) desktops running on Microsoft terminal servers or Citrix Presentation Servers. 

Now that various VDI technologies have hit the market, reactions are all over the place.  Some people are talking about how VDI will replace or compete with SBC and traditional technologies.  It is fair to say that there is some overlap between the technologies and therefore some cannibalization is to be e7ected, but the use-cases for each technology is distinct and proper application can mean the difference between success and failure.

The idea is simple. Instead of giving a user a local PC running a local copy of Windows 7, you run the Windows 7 (or Vista) desktop software in your datacenter. Then your users remotely connect to and control their own instance of their Windows desktop in a one-to-one manner from their own client device.

In doing so, the user can use any client device they want to access “their desktop.” If you replace a user’s desktop with a thin client that automatically connects to a Windows machine in the datacenter when the client is powered on, there’s a good chance that the user wouldn’t even know they were using a remote desktop.

In reality, no one would implement this by stacking Windows 7 desktop computers floor-to-ceiling in their datacenter. Instead, VDI is typically implemented by building huge VMware servers running many Windows 7 VMs or by using high-density blade servers running Windows 7.

So why would anyone do this? To understand it, we first have to look at the alternatives. The role of an IT department is to provide applications for users. In order to use an application, a user needs a desktop. (Be it a Windows desktop, a browser window, or something else, there has to be a backdrop that has some method for users to select and launch applications.)

VDI is about providing desktops to users. Before VDI, there were two other ways to provide desktops to users:

The VDI approach adds a third option to this mix. Therefore in order to answer the question of why anyone would want to use the VDI option, we have to look at how the VDI option “competes” against a local desktop or SBC desktop solution.

VDI versus local desktops

When comparing VDI to a local desktop solution, you’ll see that the VDI option lets the users enjoy many of the benefits of traditional local desktops while also adding some new benefits.

Data containment. Since a VDI solution means that users’ desktops are running on servers in a datacenter, the C: drive of each desktop is also running in that datacenter. That means that all data is automatically contained within the walls of the datacenter.

Desktops run on server-class hardware. Since desktop computers are distributed throughout an organization, they don’t have the same redundancy as server-class hardware. A single power supply, drive, or memory failure can take down a desktop computer. Of course the same also applies to servers. However, since there are many fewer servers in an organization than desktops, it’s okay from a financial and risk standpoint to spend money on redundant power, RAID, memory, and other technologies to ensure that server hardware doesn’t have the same potential hardware failures.

Client device independence. In a VDI environment, the ultimate “client” device is essentially nothing more than a screen, a mouse, a keyboard, and some mechanism (RDP, ICA, etc.) for connecting to remote Windows 7 desktops. This means that the client device can be just about anything—a thin client, a Mac, a laptop, or a UNIX workstation.

Ease of management. If you have to manage 1000 desktops, which would you rather manage: 1000 physical desktops scattered all over the place, or 1000 desktops contained in a single datacenter? The simple fact that the client “workstations” are all in the datacenter can have a profound effect on management, patching, backups, provisioning, etc.

Local desktop advantages over VDI desktops

Of course VDI is not for everyone, and certainly there are a several advantages that the “traditional” local desktop model has over VDI architectures.

Local desktops can be used offline (i.e. laptops)

Local desktops can be used offline. This is probably one of the biggest downsides to VDI. In a VDI environment with everything running in the datacenter, if the network link goes down between the client device and the datacenter, or if the user wants to be mobile with a laptop, then the whole VDI concept breaks down.

It's worth noting that there are some novel solutions to this. For example, you could install VMware on a laptop and then copy the user’s VMware disk image from the datacenter to that laptop for them to use on the road, but that introduces its own challenges that are beyond the scope of this article.

Local desktops to not have a single point of failure. Even though server hardware is very redundant, if something happens to your back-end servers in a VDI environment, you’re totally out of luck. Compare that to a traditional desktop environment. If one PC fails, that user is out of luck, but the other users can still work.

VDI versus SBC desktops

The other option for providing desktops to users is via server-based computing. This is kind of interesting now because in many ways this was the first VDI solution, and it’s been in place for over ten years. In fact, Citrix didn’t even introduce seamless application publishing until 1999, so anything “SBC” before that was full remote desktops. Of course we didn’t know to call it “VDI” back then, but that’s what it was.

However, today’s Windows 7-based VDI is very different than today’s terminal server / Citrix-based desktop publishing, even though they both fundamentally solve the same business goal (desktops to users).

Let’s compare these two technologies and look at where each has an edge.

Better performance. (In theory, anyway.) Any performance gains might depend on whether your VDI Windows 7 desktop backend is made up of blades or regular servers running VMware. Obviously if you only have one user (or a handful of users) on each blade, then your users can run bigger and more powerful applications without negatively affecting as many users as in a terminal server environment. If you're using VM software to cut a huge server into dozens of Windows 7 VMs, then you will have the ability to partition the resources for each VM in a different way than regular terminal server or Citrix SBC sessions.

No application compatibility issues. With VDI, each backend Windows 7 desktop is a full standalone workstation. This means that you don't have to worry about applications that are not terminal services-compatible.

Better / easier security. Since each user would have his own standalone Windows 7 desktop, you don’t have to worry as much about locking down each user's session. If a user screws something up, he won't affect other users.

You can "suspend" individual VMs and then move them from server to server. If your backend Windows 7 VDI infrastructure was based on VMware, you could have some cool flexibility 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 the Windows 7 desktop VM to a disk, 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 client). If the user still didn'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 had been.

The clients run the "workstation" version of software. Since these VDI desktops would be based on Windows 7 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 7 workstation, 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. If your backend VDI infrastructure is based on VM desktops, you can do cool things since the VM software provides a 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. For VM-based VDI solutions, all you would have to do is to backup the disk image files for all the user's workstations. 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.

After reading through this list, you can see that VDI is cool. It combines the benefits of distributed desktops with the benefits of server-based computing. But there’s a flip side. You also get a lot of disadvantages of distributed desktops.

Management. One of the original beauties of SBC is that you can run probably 50 or 75 desktop sessions on a single terminal server or Citrix Presentation Server, and that server has one instance of Windows to manage. When you go VDI, your 50 to 75 users have 50 to 75 copies of Windows 7 that you need to configure, manage, patch, clean, update, and disinfect. Bummer!

Less server hardware is required. Giving each user a full workstation VM or blade 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 50-100 desktop sessions as a terminal server. With VMware, you're probably only looking at 15-20 Windows 7 VMs.

Less software is required. In addition to your OS and application software, with VDI you'll also need the hypervisor software (from VMware or Microsoft) and you'll need some software to manage the provisioning of VMs for users. Of course this will also cost more money.

Given these comparisons, should you use VDI technology in your environment? Hopefully it’s obvious that any environment can benefit from a blended approach. Just as it makes sense to build a comprehensive application delivery solution that involves server-based computing, traditionally installed applications, and application streaming, you should think about the desktop as “just another application” that can be delivered in many ways depending on the situation.

The over-hyped example that’s always used to answer the question of “why would someone need VDI” is for remote software developers. The idea is that the remote developers can each have their own VM or bladed desktop and do whatever they want to it without affecting other users.

While I definitely think this use case is a good example, the problem is that VDI is also useful in many other ways. My fear is that always using the developer example will lead people to think that they don’t need VDI if they don’t have any remote developers.

The reality is that VDI technology is useful in any scenario where you have power users or users who need strange, non-terminal-server-compatible applications, but where the users still need the flexibility associated with traditional SBC environments. (Connecting to applications from anywhere, over slow connections, etc.)

VDI will be useful just about everywhere, albeit in a limited way. It will just be one of the multiple methods that can be used to provide a desktop to a user.

My view is VDI can play a role in nearly 100% of all companies out there, but only for probably 20-40% of user types at those companies.  So yes, it’s useful, but no, no one is throwing out their SBC environments or desktop computers.



(most data sourced here)