Home » Flash » Performance Tuning VDI Environment – My Opinion

Performance Tuning VDI Environment – My Opinion


This year is the “year of the VDI” as was last year and the year before that. There are very few environments which are as simple but still complex to design and manage as a VDI environment. vSphere has provided a lot of ways to virtualise the server workloads over the years and VMware View (Horizon View) has definitely given it the edge for deploying VDI environments.

There are people who swear by Citrix and there are people who swear by View, I am in the latter group (no surprises there). But there is one thing common between Citrix VDI (Xen Desktop) and VMware View deployments, if not designed and implemented carefully, they can both cause more issues than resolve. Typically, VDI is used to simplify patching OS (Windows) and still have control over the Corporate Data for growing number of people moving towards Macs and iPads for Corporate use. This is a good thing, generally. You relinquish the resources used by “corporate” machines and let people buy the machine that they are happy to use and you still control how they logon to corporate resources and manage the permissions on what they can and cant do.

One thing that a lot of people mis understand is the use for VDI and how they design it. Needless to say, VDI can be slow and cumbersome if not tuned correctly which affect the users perspective of VDI as a technology. A few things to look out for when designing VDI solutions using either Citrix or View:

  • If there are large number of Persistent users, ensure that the resources are in local cache mode, so that they can use the resources on thier local machine instead of hogging resources from the pool.
  • Create multiple pools based on user requirements, Power Users, Heavy Graphic Users, Kiosk users. They all have different requirements and expect different things from the VDI.
  • One size (image) doesnt fit all. If you have a large number of applications, make sure you can virtualise them. Virtualising applications moves the processing of the back end to the servers leaving VDI footprint small and applications run faster.
  • Pre-install (Pre-push) the most commonly used applications in the pool on the base image, patching the application and rolling back from a bad patch becomes easier.
  • Have a seperate cluster to house Heavy Graphic Users. This will eliminate the noisy neighbour problem with other non heavy users.
  • Ensure that all the replica images and base images are on the fastest disk available (FLASH FLASH FLASH)
  • Linked clones can be on slower disk, but if you can use fast disk use it.
  • Persistent Images can be on slower disk, especially if local cache is used, freeing up faster disk for linked clones.
  • Ensure that your vCenter server is not a single point of failure for all your VDI users ( especially when more than 2000 users).
  • If you are designing VDI for branch offices connected by WAN, PCoIP is probably the best option especially if you dont have WAN accelerators between locations.
  • User Disks can be on slower disk but this will impact the user logon experience so use the fastest slow disk you can (see what I did there).
Last but not the least:Dont forget to include the VDI enabling machines (Composer, Connection Server, PVS, MCS, etc etc) in your calculations for resource utilisation.Please feel free to comment and let me know what I have missed and I will include them..


1 Comment

  1. Great points Harsha! I have a few items I checked when I did a POC for a small deployment

    – Separate VDI deployment from Server Virtualization deployment. Different IO profiles, different requirements etc.

    – Think ahead about Profile Management. Seriously contemplate using Persona Management with or without Windows profiles.

    – Ensure DHCP pool’s big enough so all desktops get a valid IP.

    – Size hosts according to requirements. Dont overload hosts so much that if a host fails HA cant restart all VM’s on other hosts. Even if it did, the remaining hosts may get highly oversubscribed.

    – Plan regular recompositions of linked-clone pools otherwise the benefit of linked-clones is lost. More of an ops thing I know, but worth mentioning.

Leave a comment

Your email address will not be published. Required fields are marked *


Check Out koodzo.com!