VDI is great for many reasons and works well in a lot of places. True, there are a lot of consultants and vendors really pushing the technology, and in many ways, the promise of what VDI could be is still a few steps ahead of what VDI can do today.
I've been involved with countless VDI projects over the years, and truth-be-told, a majority of them do not deliver the expectations or savings that everyone hoped they would.
Underestimating the hardware requirements
When companies start to think about VDI, one of the first questions asked is "how many users can I
fit on a server?" Of course, the VDI vendors are nice enough to publish numbers, such as "six users
per core" or "eight users per core." Numbers like these sound great and really help you get to a
quick ROI. Unfortunately, those numbers come from the people who are in business to sell you VDI
solutions, so they have to be taken with a grain of salt. I'm not suggesting the vendors are
outright lying, but I'm sure they have very special, or limited, use cases that produce those user
density numbers.
When tackling a VDI project, it's critical to test your user density with real users on the actual hardware. For example, you can't assume that you can get 100 users on this box because you see only two users have consumed 2% of the server. This thought process is a sure way to fail.
Underestimating the network requirements
Remember that VDI is a form
Requires Free Membership to View
When you register, you’ll also receive targeted alerts from my team of editorial writers and independent industry experts with the latest news, tips, and advice to help you do your job more efficiently and effectively. Our goal is to keep you informed on the hottest topics and biggest challenges faced by IT professionals today working with desktop virtualization technology.
Cathleen A. Gagne, Senior Editorial Director
of server-based computing, and when you replace a user's desktop with a
VDI desktop, all of their actions traverse the network. This means the network and VDI
traffic have a huge impact on the success of your project.
The problem usually starts in testing when the project team tries to estimate how much bandwidth will be required to support a number of users. A bunch of connections are open and a simple script to simulate load is run -- the team then thinks those numbers can be extrapolated out. Once the project rolls into production, "real" users do a lot more than the project team tested for. Users watch videos, listen to music, drag windows around, etc. So the project "fails" for either of the following reasons:
- The network can't support the real-world users, so they blow out the budget and ROI model by beefing up the network.
- The users have a bad experience and they revolt.
How to guarantee your VDI project doesn't fail
VDI can be used very successfully in today's world if you use it only where it makes sense and
avoid these common mistakes. So before you start any VDI project, consider the following:
- Make sure you really need VDI -- and have a real reason that a cheaper solution, like Terminal Server, does not work.
- Ensure that the current version of the product you're buying actually solves your needs today. Don't buy because the "next version will be better."
- Test. Test. Test. VDI is a totally new way of delivering desktops to users. Make sure you understand everything before you commit to a solution. Test your networks, your server capacity, your disk imaging software -- everything!
| ABOUT THE AUTHOR: |
| Brian Madden, Independent
Industry Analyst and Blogger Brian Madden is known throughout the world as an opinionated, super technical, fiercely independent desktop virtualization expert. He's written several books and over 1,000 articles about desktop and application virtualization. Brian's blog, Brianmadden.com, receives millions of visitors per year and is a leading source for conversation, debate and discourse about the application and desktop virtualization industry. Brian is also the creator of BriForum, the premier independent application delivery technical conference. |
This was first published in May 2009