Making the leap to virtual desktop infrastructure

The utopian vision of a fluid and easily managed desktop infrastructure has floated around IT since the dawn of the desktop era. There have been many attempts at corralling the desktop hydra, but none have provided a universal solution. Microsoft Terminal Services, Citrix XenApp, and a host of others have found markets, but the quest for desktop salvation continues.

Enter the newest comer: VDI (virtual desktop infrastructure).

[ Get the full scoop on implementing VDI in the InfoWorld "Virtual Desktop Infrastructure (VDI) Deep Dive" PDF special report. | Better manage your company's information overload with our Enterprise Data Explosion newsletter. ]

At its simplest, VDI is nothing more than one desktop VM per user, running on top of a hypervisor. As with server virtualization, each desktop VM is assigned RAM, disk, and I/O resources, and a full installation of the OS resides on the virtual disk. The user interacts with the desktop VM using a remote display protocol such as Microsoft's RDP (Remote Desktop Protocol) or Citrix's ICA (Independent Computing Architecture). The client is generally a diskless, power-sipping, thin client system that does little or nothing more than connect to the VDI infrastructure.

The result of this and other server-based desktop computing solutions is that the core of the functionality -- and all the precious company data -- is contained within the data center, not spread far and wide among cubicle farms or across many miles to remote sites.

By centralizing desktops, you simplify administration and security and remove the need for such basic desktop maintenance as replacing failing power supplies, hard drives, and so forth. Power consumption is also reduced, and in some cases, cooling costs for dense office spaces drop due to the removal of all those fat client systems and their 350-watt power supplies. The upside can be substantial.

Devils in the VDI details But there are definite downsides to VDI. Some of these issues are found in other server-based desktop computing solutions but affect VDI implementations as well.

Let's start with the most important issue of all: user acceptance and overall performance. Each VDI instance may be fast and snappy while performing relatively mundane tasks like word processing, emailing, or running spreadsheet formulas, but they can suffer mightily when confronted with rich content like Flash applications, videos, or other multimedia applications. This is generally due to the desktop display transport protocol rather than the performance of the VM, but that only makes the problem harder to solve. Very public problems may arise with user acceptance, which is generally the death knell of any large project.

The solutions to this problem can be costly. Some vendors combine efforts on the server and client side and ship audio and video streams alongside the display protocol, matching them up at the client end and using the client's processing power to render the video. This results in much cleaner playback, but requires a more powerful and expensive thin client to handle the extended workload.

Such solutions work well for standard video playback, but they still have issues with Flash video and Flash applications. It's easy to test the performance of VDI or any other server-based desktop computing solution that uses the standard RDP protocol: Just use the Microsoft Remote Desktop Connection client to connect to a server or desktop system and try to view a video on YouTube. It may play reasonably well if you're using a 100Mbps or faster LAN, but it's simply a nonstarter over anything less than that. Generally speaking, watching a video across an RDP connection requires 3.5Mbps of sustained bandwidth.

Bandwidth concerns may dog any form of server-side desktop computing, such as serving desktop sessions across WAN links (a classic scenario for high latency and/or low bandwidth). Printing and proper mapping of USB devices may also be problematic. These issues can be sorted out with the right combination of tools and budget, and aren't exclusive to VDI, but they need to be addressed during VDI planning phases.

Other issues are clearly VDI-specific. The first and most significant: storage requirements. Some VDI implementations require that every desktop system have a virtual disk like any other VM. When you factor in 8GB or 10GB per desktop VM, multiplied by the expected VDI user count, storage quickly becomes an expensive issue. Also, it should be noted that VDI does very little to reduce desktop software administration requirements, because each VM is an island that must be managed like any other desktop system. That means using third-party tools to push updates, install software, and make changes.

And then there's cost. On one hand, VDI may leverage an existing virtualization infrastructure, possibly low­ering the initial hardware cost below other server-side desktop computing solutions. But once you've broken through the layers of software licensing required for VDI, you may find that it eventually evens out. Depending on the solution you choose, you could wind up paying more per desktop VM than per traditional fat client system, with the ROI pushed pretty far out. It's vitally important to run all of these numbers before you jump into any VDI implementation. Factor in thin client costs, implementation costs, licensing, and expansion of an existing virtualization infrastructure.

VDI vs. Terminal Services Distinct parallels can be drawn between VDI and traditional Microsoft Terminal Services solutions. They both place many user desktop sessions on a single server or set of servers and they both use the same protocols to deliver those sessions to the same thin clients. Both offer centralized desktop management tools. But the similarities end there.

A Terminal Services environment places all user sessions on the server OS itself. This means that a single instance of Windows Server 2003 or Windows Server 2008 is installed on a bare-metal server, and all users log into that server instance. Each user session is presented with its own desktop, but runs alongside all the other sessions on that particular server.

The benefit of this scenario is one of scale: Generally speaking, you can probably shoehorn more Terminal Services sessions into a single physical server than VDI sessions, although that depends on the application set. On the flip side, in a VDI environment, it's possible to institute hard and fast resource limits to any user session simply by defining the resources of the desktop VM.

In a VDI implementation, that same server is running a hypervisor, not a full OS, and is hosting some number of desktop VMs. The end effect is that each method places multiple desktop sessions on the same server, but the manageability of those sessions differs significantly.

For instance, with Terminal Services, there's no way to snapshot a session like you can a VM, nor is there a way to migrate active sessions from one physical server to another. This means all users must log off of a Terminal Services server before it can be taken down for maintenance. With VDI, all of the active desktop sessions on that server could be migrated to other servers in the farm without disruption. The server that normally hosts all those VMs could be taken down for maintenance without anyone knowing.

Indeed, as with any advanced virtualization infrastructure, it's possible to completely rebuild the entire underlying physical server structures without taking a single application offline or interrupting a single user.

Further, load-balancing is intrinsic to a properly implemented VDI solution. If one or more desktop VMs are using significant resources on one host system, other VMs on that system may be migrated on the fly to other physical hosts, ensuring that all the desktops have enough resources to go around. In traditional Terminal Services environments this is not possible; a single heavy user session can negatively impact other sessions on the same server without any automated remedy.

But Terminal Services has one big management advantage: Changes made to the host servers are made available to every user session. Application installation is simplified to a degree and global modifications are relatively easy.

With VDI, that's not always the case. Depending on how the desktop VMs are deployed, updates and changes may require manually modifying each VM individually; using third-party management tools; or firing up a desktop VM template, making the changes, and saving the template. Desktop VMs that are linked to the master template will reflect the changes the next time the user logs on.

Nonetheless, application handling is one of the main benefits of VDI over Terminal Services. Many applica­tions simply refuse to function in Terminal Services envi­ronments. Others have limited functionality or may not be supported by their vendor in a Terminal Services environment. This presents a real problem for any Ter­minal Services-based infrastructure, but it's generally not a problem for VDI.

Why? VDI implements a single dedicated desktop instance per user, indistinguishable from a physical desktop at the OS level. Any application that would run on a fat client should run on a VDI VM (with some exceptions made for video and graphics performance). This is a major reason some shops are pushing VDI over Terminal Services.

Read more about how to deploy VDI in InfoWorld's free PDF report, "Virtual Desktop Infrastucture (VDI) Deep Dive," including:

• Planning and implementation
• User acceptance and use cases
• Client considerations
• Beyond the walls: Remote VDI
• Bringing it all together

This article, "Making the leap to virtual desktop infrastructure," was originally published at InfoWorld.com. Follow the latest developments in virtualization at InfoWorld.com.

Read more about virtualization in InfoWorld's Virtualization Channel.