A VDI implementation introduces complexity, and if your customers aren’t prepared for that, your project can go south in a hurry.
Physical desktop management
Pushing a VDI implementation without regard for its use cases
Virtualization vendors pushed hard in the early days of desktop virtualization, erroneously insinuating that VDI could solve every desktop management problem.
But desktop virtualization fits naturally into only a specific set of use cases. A VDI implementation makes the most sense where there are desktop user groups that use the same applications, such as customer service reps or sales. That similarity, and common applications and configuration, are key to making a VDI solution work for an organization.
Make sure you’re listening to your clients before suggesting a VDI solution, because it may not fit their needs.
Ignoring VDI’s role in service delivery infrastructure
A successful VDI implementation fits desktop delivery into a customer’s application delivery infrastructure. It should not try to shoehorn all application deliveries into VDI, because many applications just don’t work well atop a virtualized desktop.
Delivering those applications via other avenues may be a more appropriate solution. Smart solution providers understand fully the application delivery requirements of their customers before ever starting a VDI sales conversation.
Focusing on storage consumption, ignoring storage performance
Storage performance is often today’s biggest VDI bottleneck, rather than storage capacity.
Yet while storage performance -- particularly during logon activities -- is monitored, this important measurement may be ignored in favor of storage consumption. In fact, a VDI implementation affects both storage consumption and storage performance.
All levels of storage performance should be monitored including hardware, virtual machines, the hypervisor and storage network performance, because if you’re not monitoring it you won’t know if it’s affecting performance. To ensure that your VDI implementation succeeds, insist that the necessary monitoring tools are used.
Neglecting the need for high availability
The failure here is two-fold. The first failure can happen during initial testing and evaluation of a VDI implementation in a small environment. Here, high availability (HA) may be overlooked because customers are focused on encouraging user acceptance of VDI, which can be costly. Clients need to be aware of the array of components required to power VDI and how important HA is for each component in a production environment.
The second failure occurs when clients don’t understand how many components a VDI solution adds to an IT infrastructure’s service delivery. Storage must be redundant, but so must desktop controllers and provisioning servers; even DHCP servers become mission critical. Don’t fail your customers twice by forgetting the HA.
Failing to plan for performance, particularly after initial success
This final failure applies during a specific point in time during a VDI’s implementation. That all-critical time is immediately after success is declared in the initial small-scale environment, and a client is ready to ramp up to full production. This is when the enormity of VDI’s interconnections -- and the holes in your scalability planning -- begin to show through. Storage, networking, monitoring and other IT services can quickly create a bottleneck during the VDI ramp up period. Ignoring any user complaints or concerns about performance can quickly fail a move to full production for a system that worked fine in small scale.
A VDI solution obviously isn’t for everybody, nor is it for every MSP. The technologies and experience required for success go beyond those needed for server virtualization. Make sure you’re fully comfortable with all of VDI’s use cases and common failure points before kicking off a client project. It is, after all, your reputation on the line should the project end in disaster.
About the author
Greg Shields, MVP, vExpert, is a partner with Concentrated Technology. Get more of Greg's tips and tricks at www.concentratedtech.com
This was first published in April 2012