VDI pilot project guide
A comprehensive collection of articles, videos and more, hand-picked by our editors
There are lots of ways for a desktop virtualization project to succeed, and just as many ways to fail. We talk...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
to a lot of people about their VDI project attempts, and those that have tried and failed have interesting reasons why that happened.
We've boiled the list of reasons desktop virtualization projects fail down to eight, and I'll cover the first few in part one of this series. The point is not to poke fun at people, but to help alert anyone who is starting a VDI project about the potential pitfalls. Make sure you understand things such as Microsoft VDI licensing, and you have a good chance of VDI project success.
VDI is not the same as server virtualization
Desktop virtualization in general is not the same as server virtualization. Desktops are much more complex environments to virtualize than servers. Servers pretty much do the same thing day in and day out, and it's easy to benchmark them and plan for them. Plus, servers aren't very complex in terms of devices that need to be supported.
Desktops, on the other hand, are totally random because the users are random. That means disk I/O is harder to deal with in a desktop virtualization project (writes are random, and you can't cache them like you can reads), and you still have to support all the craziness you do in your traditional desktop environment. Funky USB devices, oddball applications and so on all figure into the VDI project equation.
It's not the end of the world, but don't think for a single second that your desktop virtualization will be easy because you're a server virtualization all-star.
A VDI project is probably not going to save you money
If you're starting a desktop virtualization project, odds are you've filled out at least one cost model. It probably showed that your VDI project was going to save ridiculous amounts of money at some things, and that VDI would prove to be a cheaper, more functional infrastructure. The problem is: Cost models lie.
More on desktop virtualization project failures:
Five reasons a VDI project stalls: What's the holdup?
15 reasons desktop virtualization fails
Why do virtual desktop projects fail?
How to revive a failed VDI proof of concept
How to avoid common VDI deployment problems
You can leave things out of cost models or you can include things that don't really matter. Doesn't adding all the amazing features of VDI to your environment for less money sound a little too good to be true? That's because it is.
Most companies buy in to VDI on the premise that non-persistent virtual machines (ones that share a single master image) are going to be the best path for their desktop virtualization project. Mainly, that's because cost models show it will be cheaper. After implementing a non-persistent infrastructure, however, companies realize that it's not very flexible and they end up trying a VDI project where each user has their own virtual machine (VM). This type of desktop virtualization project works well, but it costs significantly more in terms of storage.
You can't go into a desktop virtualization project thinking that VDI is going to provide tons of new features for less money. It's like buying a car. You wouldn't expect an equal trade for your Ford Fiesta that doesn't even have power windows and a Lexus that can parallel park itself, right?
Misunderstanding Microsoft VDI licensing
You might think that because you're properly licensed in the traditional desktop world, you're good to go when it comes to your desktop virtualization project. You might think that because VDI is like Remote Desktop Services, you have enough client access licenses to go around. But Microsoft VDI licensing is more complicated than that: You need Software Assurance (SA) for every single device that accesses a VM.
Wait, every single device? Not just for the VM itself? What the…?
The truth is that it has become increasingly complex to play by the rules of Microsoft VDI licensing. The simplest answer I can provide when asked how to license Windows in a VDI environment is, "With money."
You're probably aware of Software Assurance, and you might even be buying it for your traditional desktops. If you are, good for you! Those desktops are now entitled to access a VM running the same version of Windows at no extra cost.
If you don't have SA, things get tricky. You can only purchase SA with a device, and that device alone carries the SA entitlement. That means iPads, iPhones and Android devices don't have SA entitlements. If you didn't purchase SA for your desktops, they don't have it either. To fix this issue with Microsoft VDI licensing, the company came up with the Virtual Desktop Access (VDA) license. It's a per-device license, and if you want to use your non-SA entitled devices, each device you use has to have a VDA license at $100.
There are some home-use privileges that come with this, but they all deal rather ambiguously with whether you're actually at the office. It boils down to this: If you want to use your iPad at home and you have a device with SA or VDA in the office, you're fine. If you want to use your iPad at work, even though you also have an SA- or VDA-entitled device, you still need a VDA license for that device. Isn't Microsoft VDI licensing fun?
Good luck with all that. Next week: More reasons desktop virtualization projects fail from the start.
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.