Nathanael Iversen, Director of Technical Marketing at Xangati (, says:

Companies spanning multiple industries – including education, financial and healthcare – are turning to virtual desktop infrastructure (VDI) as a way to improve their operational efficiencies and bottom line. VDI enables IT to provision and deploy new desktops faster; replace traditional desktops with more cost effective thin clients; as well as enhance overall security by centralizing system administration.

Yet many deployments have been fraught with difficulty – frequently resulting in stalled implementations and cancelled projects.

Understanding the changes that have occurred is the first step in overcoming many new challenges for emerging technologies. VDI has changed the traditional desktop model, and understanding that transformation – and everything else it impacts – is essential to managing the infrastructure and ensuring success for VDI initiatives.

The higher number of applications and desktops in a VDI infrastructure significantly increase management complexity for administrators and create more pressure to guarantee a positive end-user experience. IT needs to fully comprehend how the entire network impacts the VDI in order to satisfy their users and enjoy the advantages of this new technology.

For VDI, the network is front and center

VDI is intrinsically dependent on the network. The network is the conduit by which the virtual desktop – in the virtual data center – continuously feeds its client a “video” of desktop activity. This video, in effect, then “paints” the monitor’s screen with a desktop presentation protocol – like PCoIP, ICA or RDP. In this way, VDI is completely reliant on the network as the delivery mechanism and also faces the same LAN/WAN challenges.

In addition to its reliance on the network, VDI transforms the traditional desktop architecture by splitting it into at least three distinct parts. This includes the thin or zero clients on the physical infrastructure; the desktop VM; and the VM OS image/files accessible via shared storage.

Increased visibility is key

Understanding these architectural changes is critical to managing the communications and interactions between the different components. When companies overlook these changes, they often find their VDI pilots and deployments suffering from intermittent performance problems.

This is because – without visibility into all parts of the infrastructure – administrators are not able to accurately pinpoint and troubleshoot potential performance issues. Tools need to be able to see and capture, for example, when there’s a clash of resources across the WAN. Only by using tools that can provide real-time insights across all infrastructure devices – tracking every VDI session end-to-end as it traverses the network – will VI administrators be able to catch and remedy such potential problems.

In addition, without visibility into both virtual and physical communications, you cannot effectively track network latency or network workloads – two of the most significant issues for successful VDI initiatives.

Poor latency means unhappy users

Any network latency or response time above 200 milliseconds (ms) begins to impact and delay mouse movements, causing a disruption to end users – and adversely impacting their experience.

If you are planning a VDI deployment, it is important to assess up front which remote locations have a regular network response time of less than 200ms. By tracking network latency for remote sites, managers can determine which ones have acceptable tolerance levels before implementing VDI.

Having this data in advance allows administrators to assess whether they can deliver acceptable VDI performance and – if not – allows them to see what improvements need to be made to the existing infrastructure in order to do so. (The administrator should also note that remote sites may also include outsourcer or contractor sites that are not part of their infrastructure.)

If there is an intermittent user problem, administrators also need to be able to quickly see where a network delay is occurring. You can do this by isolating which network hop is injecting the undesirable delay. For example, is the delay on the corporate network, the VPN or in the Internet cloud?

If the network latency issue is on the WAN, administrators need tools that can identify the top talker on the WAN – the user that is most likely responsible for the network congestion causing the latency issue.

Network workload versus available capacity

Unlike in a client/server architecture, a VDI user is always using the network. The range can be from roughly 100 Kbps up to peaks of 5 Mbps and beyond for high-resolution images and videos. By tracking the network workload of each planned VDI’d application, IT can determine which applications can be greenlighted for specific lower capacity network links.

Conversely – when scaling VDI deployments – the administrator must also take into account the available network capacity on those lower speed links, which can include the WAN, VPN and Wireless LAN (WLAN).

As you undertake a VDI initiative, here are a few questions you need to consider regarding network workload and capacity:

  • What is the available capacity of a given network link? If the WAN connection is 1.5 Mbps, how much of it is regularly used for applications that are not going to be VDI’d, e.g. VoIP?
  • How many users regularly use that low capacity connection? Being able to track data regarding how many users regularly use a given network link is important to the administrator in order to determine the capacity requirements for that link. If there are eight active users on a T1 WAN connection (1.5 Mbps), then applications should be limited to those which drive roughly just under 200 Kbps.
  • What network load requirements do specific applications have? For example, what is the network load of an Excel spreadsheet versus a medical imaging system versus a video-conference? VDI management tools need to be able to provide measurements on the to-the-second workload (in bits per second) of every application being presented from the virtual desktop out to a VDI client. This allows managers to model network workload of each likely VDI application and track adjustments to screen resolution/image quality and effect on network workload.

15-minute polling intervals are inadequate for VDI

Relying on any alerting model that uses 15-minute polling intervals is woefully inadequate in a VDI environment because problems come and go in between polls – creating huge blind spots. Because of the critical nature of network latency and network workload for VDI, management tools need to be continuous and real-time.

They should also have the ability to proactively alert administrators to potential problems., i.e. when a WAN link is clogged or a VDI user grabs too much bandwidth. Management tools that do not provide proactive alerting capabilities fall short. IT needs to be given notice about network or storage latency problems before users start flooding desktop support with calls.

Putting all the VDI pieces together

VDI has been called a puzzle. If you consider all of the above pieces, that description is highly accurate. In deploying VDI, administrators need to be aware of all of the infrastructure pieces that can and will affect the experience – and satisfaction – of their end users. Administrators must recognize and be able to see how the desktop and the infrastructure are impacting each other in real-time.

As a transformational architecture, VDI has immense value for businesses. But in order for VDI to reach its potential, IT must understand that a transformational architecture requires a completely new approach to management. You have only one chance to make a good impression with end users. It’s not enough to simply have the infrastructure in place. The right management processes must also be up and ready to go from day one to ensure VDI success.