Troubleshooting tips for VDI deployments
A comprehensive collection of articles, videos and more, hand-picked by our editors
Once you've bet your IT strategy on virtual desktops, availability and performance of those desktops become a...
If users cannot access their virtual desktop or performance is too slow to get their work done, the villagers will no doubt come after you with torches, demanding their local desktops back. To help you avoid getting burned, let's look at the top five factors that affect virtual desktop and application downtime, plus how to avoid -- or at least mitigate -- these risks.
Lack of end-user monitoring
Have you ever received a flurry of help desk complaints about poor performance for specific applications? Your infrastructure team checks the network, servers, databases and applications, only to indicate that all infrastructure components are up and running as expected. This situation illustrates the difference between IT services being up and IT services being available from an end-user’s perspective. If users perceive a performance issue, then you have a performance issue, whether your monitoring tools reflect that perception or not.
You can avoid this problem by having an end-user performance monitoring tool in your overall monitoring toolkit. These tools can give you performance statistics and alerts based on availability and response time for your virtual desktops, from an end-user perspective.
A redundant virtual desktop infrastructure (VDI) is key to avoiding hardware failures that can affect virtual desktop availability. Once again, comprehensive monitoring is a great place to start. Many hardware manufacturers now include utilities that use predictive analysis of hardware operating parameters to warn you of an imminent failure.
Still, hardware sometimes breaks with no warning or indication of an impending failure. Hardware redundancy is the logical solution, so redundancy should be designed into your virtual desktop architecture from the get-go.
Incorrect or mismatched QoS policies
When you implement VDI, make sure your vendors or consultants include instructions on how to prioritize virtual desktop traffic on your network using the Quality of Services (QoS) capabilities in your network infrastructure.
Virtual desktop traffic should be configured at the highest QoS priority available, even higher than video or VoIP traffic. This prioritization may be based on virtual desktop protocols, ports used by your VDI, subnets or VLANS or perhaps a combination of these techniques. Also be mindful of mismatching QoS settings among routers and switches. Be sure that all network devices that support QoS have been configured to steer virtual desktop traffic into the express lane; otherwise, a single router or switch can impede user satisfaction with virtual desktops.
Poor storage performance
The type, location and performance of storage also affect desktop and application downtime. It's great to be able to centralize the storage of user data, but there is a big gotcha in using SAN or other network-attached mass storage devices for VDI: disk I/O latency. That's because operating systems read and write data to disk on a regular basis, even when the desktop appears to be idle.
More on virtual desktop availability
Troubleshooting VDI problems: A Q&A
Preventing virtualization downtime and data loss
As the user loads a new application or performs work in an open one, the amount and frequency of reading and writing to the disk storage can put a considerable burden on the network and storage arrays. Data read-ahead algorithms and disk buffering can typically keep up with read requests from virtual desktops, but writing to disk often involves a physical disk head touching a spinning disk platter in order to store the data.
With this in mind, pay particular attention to disk write latency across the network and your QoS settings. Disk writes can be queued in the disk hardware, but that adds latency, which can affect the speed of the virtual desktops.
You'll also have to carefully analyze the write specifications of your storage arrays. It may be cost-prohibitive to buy hardware that is fast enough to give you the low disk-write latency required for a successful virtual desktop implementation. If you acknowledge that you cannot deliver acceptable performance for virtual desktops within your storage hardware budget, maybe management will finally spring for flash-based storage!
The last factor is the hardest one to control: human error. A systems admin might accidentally unplug a critical server or install an unapproved software patch in an effort to improve VDI performance. We recently heard about an IT asset manager who opened an automated tape library in a data center to write down information located inside the cabinet; he was very nearly struck in the head by the tape management robot arm. Talk about unexpected downtime: Ouch!
Formal, enterprise-wide change management procedures are your only defense against the inevitable influence of human error. Your strategy should include:
- Education for technicians, system admins and business leaders on the importance of change management
- A formal change review board comprised of IT personnel
- Enforcement of change windows and "quiet" periods
These five factors are just the tip of a large and complex virtual iceberg. If you keep these causes of desktop and application downtime in mind, you will have a huge head-start in making your virtual desktop project successful.
About the authors
Ed Tittel has been working in the computing industry for over 30 years and writes regularly on Windows and networking technologies. Perhaps best-known for creating the Exam Cram series of cert prep books in the late 1990s, Ed has contributed to over 100 computing books and thousands of articles. He blogs regularly for TechTarget (IT Career JumpStart, Windows Enterprise Desktop) and for Tom's IT Pro and PearsonITCertification. Earl Follis has been at work in IT for over 25 years for companies that include Dell, Tivoli and Nimsoft, with a particular emphasis on network management, monitoring and training. He and Ed have written half-a-dozen books together, including 3 editions each of …For Dummies titles on various NetWare and Windows Server versions.