VDI Tip #3: Analyze the networked activity of your VDI sessions

Nathanael Iversen, Director of Technical Marketing, Xangati

Today’s third tip really talks about the network activity of the VDI session. This ends up being particularly important because in VDI, we’ve actually decomposed the desktop into several different constituent parts.

What we’ve done in VDI is essentially taken a desktop and split it in between a screen display, the backend processing, and the storage for that desktop. These items are typically separated by a network and when you do that, the workload of the network becomes a critical part of the actual end user experience. It becomes important to be able to see the network workload which is not something that that typically falls into the desktop area for management but for VDI, it becomes critical to actually maintaining the end user experience.

Xangati is a tool that enables you to see not only what is going on in the virtual environment, but also in the physical environment and particularly to monitor latency to key remote sites and to verify that the kind of packet delivery that you’re getting out of the network is suitable for a virtual desktop deployment.
One place where this was particularly important was at a large, national law firm. We installed our dashboard and within the first day were able to identify some pretty significant challenges. Interestingly, about 600 VDI users, most of them having issues on a somewhat random basis and yet they were only halfway to where they needed to go and existing network tools were not helpful. In fact, they had doubled the size of their WAN and dedicated half of it just to VDI and they were still having issues. Well, the fascinating thing that we noticed was a particular user was using about 12 mbps in their VDI session. And, there were about a dozen other outliers who were again using many mbps of bandwidth. It turns out that the users weren’t doing anything wrong, it was that the desktop protocol needed to be optimized. There were many settings in the audio and video in particular that were just not optimal for what this organization needed. And, with a little bit of knob and dial twiddling inside the admin console and all of a sudden, everything was running smoothly. And, so, the source of the stall was identified quickly, allowing them to move on and meet their deployment goals.

Stay tuned for tomorrow’s Tip #4 where we look at recording end user performance issues.