Five things to consider before you deploy VDI

VDI isn't a cure-all for your remote computing woes. It can be costly and complex to deploy if you don't know what you're getting into.

If you're new to VDI, it's easy to get drunk on its promise without understanding its perils.

Virtual desktop infrastructure (VDI) can be intoxicating at first glance. A world without the hassle of physical desktops, where you get to pick your own access device, seems like paradise after all those years of bumping your head while crawling around under someone's desk. But VDI isn't right for every scenario, and some of its touted benefits -- such as improved security -- come with serious gotchas.

Keep these five major points in mind before you deploy VDI:

Not all remote desktops are VDI

VDI is just one of several possible ways to provide a remote desktop experience. It's not the only way. Depending on your needs, technical expertise and current infrastructure, it may not be the best way, either.

The strictest definition of VDI involves a full desktop operating system instance that is hosted on a server and delivered to a remote client via a network connection. The entire desktop, not just the applications, is virtualized this way. Users can install their own software as needed, instead of just being provided with a fixed set of applications, and they can connect to the virtual desktop from any network-connected client device. The client access device can be a traditional PC, a thin or zero client, or even a smartphone or tablet. (The choice of client device, however, may limit the sorts of things users can do. What you lose in consistency of client experience, you gain in flexibility of access.)

VDI doesn't just provide users with access to an application set, a la Citrix Systems' XenApp. It also isn't the same as using a service such as LogMeIn to remotely access one's desktop machine. If you need people to still have individual PCs in a specific location (e.g., under their desks), or if you only need to provide remote access to a specific application, then those solutions are going to be more immediately useful than VDI.

Don't deploy VDI to solve the wrong problems

VDI, like any other technology, isn't a panacea. Don't use it to solve problems it isn't really designed for.

VDI is designed to solve a specific problem set. It removes the need for users to be attached to given physical PCs to do their work, and it allows them access to a full desktop environment from whatever access point they're using. Here are two things VDI doesn't do:

  • Automatically cut costs: If you aren't able to provide hard numbers for how moving to a VDI model will be cheaper, it probably isn't. Look at the total costs of creating the VDI back end, provisioning access devices and setting up a maintenance routine.
  • Provide a unified user experience: With VDI, each user's system still needs to be configured and maintained separately. It's possible to automate a good deal, but VDI still isn't the ideal way to ensure everyone is doing the exact same things. If anything, a big part of VDI's appeal is to allow each user some flexibility in customization: their own application loads, their own desktop experience and so on.

VDI isn't spray-on security

A bit of conventional wisdom about VDI is that it's an inherently more secure setup than physical desktops. After all, if the actual desktop resources are under literal and figurative lock and key on a server somewhere, that's a more secure setup than having a physical box under a desk or in a laptop bag, isn't it?

Yes and no. VDI does make it easier to secure desktops from the outside; it doesn't make them any less vulnerable to being compromised from within-- a point Brian Madden has made before. As he noted, a VDI setup does not make the desktop instance itself any more inherently secure. It's still possible for end users to wreck their own systems by downloading the wrong thing. It may be easier to restore those systems or contain the damage they cause, but those are still more headaches you shouldn't have to deal with.

You should take the time to provide the same kind of endpoint security that you would with a conventional desktop system. How you go about doing this is entirely up to you, but don't neglect it.

Don't forget the network

Once you've decided to deploy VDI, a major potential omission is failing to provision the necessary network resources. VDI protocols are designed to be lean and mean, even on gigabit Ethernet, but networks can be bogged down if you thoughtlessly pile up enough instances on the same port or switch.

If you have VDI users who routinely work with high-bandwidth resources, realize that you now have two bandwidth issues to deal with, not just one: the bandwidth to and from the VDI instance on the back end and the bandwidth to and from the client access devices. The latter will be far less burdensome than the former, but it won't be negligible -- especially not if you're allowing the use of client multimedia extensions, such as Microsoft's RemoteFX.

Don't forget storage, either

Virtual desktops contain full operating system and application instances, so they can end up using a great deal of storage on the back end if they're not provisioned properly. VDI typically relies on SANs for storage, but they are pricey and don't deduplicate easily. In addition, you may be forced to spend some time harvesting real-world behavioral statistics about the needed level of IOPS to tune your storage for VDI. It helps to do some calculations ahead of time as well.

Windows Server 2012 has some storage technology advancements in the area of native deduplication and storage pooling, but don't count on those features alone to get you out of the woods. A software solution such as Unidesk's may also help; it splits the storage you use into tiers to optimize efficiency.

Dig Deeper on Virtual desktop infrastructure and architecture