Five reasons a VDI project stalls: What's the holdup?

Consolidation confusion

A few weeks ago, I warned against thinking desktop virtualization is the same as server virtualization. It's worth looking into this pitfall even further and considering consolidation issues in particular.

Server virtualization is about consolidating workloads that are consistent, boring and practically begging to be standardized. Servers pretty much sit there and do their thing in predictable, manageable ways.

Desktop virtualization -- and in this case, VDI -- has many differences:

• Users actually access the virtualized desktop, so they need 3-D graphics, remote peripheral support, a good network connection and more.
• It's not about consolidation with desktops. All you're doing is moving the workload from the cubicles to the data center.
• Virtualized desktop resource access is completely random, because each user is unique. You can plan on boots, logons and things like that, but even the day-to-day activity is hard to gauge.

The technologies that drive desktop virtualization are also different. VDI administrators, for instance, have to consider linked clones, IOPS, disk streaming, user data disks and other factors that simply don't matter on the server virtualization side. Add to that all the other aspects of desktop virtualization, such as Remote Desktop Services, client-based virtual machines, operating system streaming and application virtualization, and you can see how complexity could stop a VDI project in its tracks.

Doing too much at once

In 2009, many of us assumed Windows 7 migrations would drive VDI adoption, and even though that didn't pan out, some companies still see that as a catalyst. For those companies, I have a message: Just focus on Windows 7 at this point. You already have your hands full learning the differences between Windows XP and Windows 7. If you try adding a VDI project into the mix, you're setting yourself up for failure.

You should migrate to Windows 7 -- you only have two years left! -- then worry about a VDI project. You may use aspects of desktop virtualization to help your Windows 7 migration, but don't try to face all the challenges of migration and desktop virtualization at once.

Not knowing why you're doing this in the first place

Let's face it: Virtualization is sexy. Desktops, on the other hand, are boring. But when we combine the two technologies, we get VDI (which means we've brought sexy back). Still, that's not much of a reason to do a VDI project.

Since VDI is only a small part of desktop virtualization, it may not even be the right technology to use. You not only need to know what business problem you're trying to solve with desktop virtualization, but also which technology is appropriate. Picking the wrong one can leave you with a solution in search of a problem, which is a waste of time and money.

Forgetting the user environment

If you come from a desktop background, you know that a user's desktop might as well be another appendage, something he or she holds near and dear. If you swoop in with your fancy VDI project and the endpoint experience sucks, it doesn't matter how awesome the virtual desktop environment is or what devices they can use to access the desktop.

You have to respect the users and the user experience. Just because you can lock things down doesn't necessarily mean you should. Plus, if the virtual desktop environment is only "good enough" to get the job done, users aren't going to want to spend all day working with it. User revolt will stop a VDI project dead in its tracks.

Moving bad habits to new environments

There are many bad habits admins have when it comes to traditional desktop management that don't translate well to a VDI project. In many cases, you may not notice those habits, because the ridiculously powerful PCs under the desks have more than enough horsepower to shoulder the load. When you move computing into the data center and share resources, however, bad habits multiplied by more bad habits become apparent pretty quickly.

For instance, you don't want defrag to run on virtualized desktops. Imagine the workload placed on the shared disk by 30 or 40 machines running defrag at the same time! (Antivirus scans would have the same effect, for that matter.) Clean the image out and make sure you lock down or remove such features from the image so users can't start them.

So, evaluate how you manage your desktops now and look for holes. You'd rather identify bad habits sooner than later. I promise.

ABOUT THE AUTHOR:
Gabe Knuth is an independent industry analyst and blogger, known throughout the world as "the other guy" at BrianMadden.com. He has been in the application delivery space for over 12 years and has seen the industry evolve from the one-trick pony of terminal services to the application and desktop virtualization of today. Gabe's focus tends to lean more toward practical, real-world technology in the industry, essentially boiling off the hype and reducing solutions to their usefulness in today's corporate environments.