Now that you have your VDI project under way, you need to test the deployment's performance. VDI testing should involve one of the most important parts of your project:
When the interest in virtual desktop infrastructure (VDI) began, IT departments and consultants scrambled to deliver virtual desktops to the users -- with eager, wide-eyed managers and executives looking over their shoulders. But some of the crucial pieces can get left behind if you rush a complex VDI project.
There have been many conversations about why VDI deployments fail, and a lack of effective virtual desktop testing with the user base is one of the main reasons. When I see a partially or completely failed VDI project, I ask how the organization did its VDI performance testing.
If your VDI testing only involves the IT staff, you have a problem. Here are some considerations for doing proper VDI performance testing with your actual users. Keep in mind that these factors are flexible based on the size of the implementation and user base.
Get to know your users
I don't mean just know their names or where they work. You need to create relationships and get a real understanding of what jobs your users do. This may prove to be a challenge with larger shops, especially if you're a consultant, so using a supervisor or a few (tech-savvy) employees may be the best avenue to take.
Before and during your VDI testing, you should watch your users work with their desktops. Most people don't like having someone over their shoulder all day long, and you by no means have to take it to that extent, but you should take a little time and observe users interacting with their desktops. (This would also be difficult in larger shops, but you could just check out a few VDI users.) You need to understand what they expect, what they see and what, if any, nuances they may have.
Tailor your VDI testing
Now that you've filled your notebook with all the user information, it's time to create the VDI testing environment. Your virtual desktop testing methodology should cover all the expected VDI users, although that depends on your individual project needs. Remote users will probably have different needs than task workers or executives, for instance.
More on VDI testing:
Using VDI as a software test environment
FAQ: Virtual testing and development environments
You should also set user expectations up front. In a perfect world, you could supply everything your users want in a desktop, but that's just not practical or even efficient. Create the test desktops to mimic the bare minimum requirements right off the bat. That way, you can always add functionality later instead of taking it away.
Then, do a sample walkthrough with your users. You don't have to sit there and do a lot of hand-holding. Just get a feel for what the users experience and what comments they make.
Finally, make sure to educate VDI users (or at least attempt to) on the concept of desktop virtualization. Most users may not know they're running a virtual desktop, but there are some out there who are actually interested in what VDI is. Take the opportunity to show off some of your expertise (while not getting too technical, of course).
Educate them on just how much faster (use that word -- it has more appeal to end users) and more efficient their virtual desktops will be without all the extra stuff, such as picture desktops and weather widgets, running on it. Use this time to impress on VDI users that bells and whistles almost always mean a slower desktop experience.
One thing I cannot stress enough is to make sure you allow enough time for VDI testing with your users, and then allocate even more time. Ample testing means better testing, which leads to a successful VDI implementation for you, your organization and -- I'll say it again -- your users.
ABOUT THE AUTHOR:
Mike Nelson has been in IT for more than 20 years, with exposure to a very diverse field of technologies and solutions. He has devoted over half a decade to virtualization and server-based computing. Nelson is currently a senior analyst at a Fortune 100 company in the U.S. Midwest.
This was first published in May 2012