VMware View 5 Performance and Best Practices

As I’ve said a couple of times, I’m pretty passionate about End User Computing (EUC) and where that technology is heading towards (like the end of desktops as we know it :).  I was afforded the awesome opportunity to be apart of a sub-group within the vSpecialist organization that focuses on EUC and specifically lately Virtual Desktops.  This means I spend a lot of time trying to read, and absorb as much as I can about it to try and keep up with the likes of Jim Sanzone (@theSANzone), Andre Leibovici (@andreleibovici) , Aaron Chaisson (@AaronChaisson) etc.  The team is just full of VDI rockstars.  On my way back from San Francisco @VMwareView tweeted out a link to a new Performance Study they published called “VMware View 5.0 Performance and Best Practices” and to say it was a timely tweet would be an understatement.  I’ve been consumed with just a ton of VDI discussions over the last few months and out of these discussions I’ve blogged about some of the various information I’ve collected.  You can review them HERE and HERE.   I flipped through this new performance whitepaper like a Vince Flynn or Robert Ludlum novel.  It’s a REAL page turner if you are into VDI and wanting to get a really good understanding of how to tweak your VMware View 5 environment to improve performance.  I thought I would call out a few things that you might be interested in.  I would HIGHLY encourage you to download and read through the document.  I’m only covering some of the highlights.

So, first things first.  I’ve been in the storage industry for the last 12 years, so I feel like what I’m about to say should hold some merit.  Pay attention to how you size your storage array.  It is the leading cause of Virtual Desktop deployments failures.  TRUST ME.  If you haven’t had a chance, check out my blog post called “Quick VDI Sizing HowTo”.  It takes you through a good understanding of things to consider.  Also, you should read up on EMC FastCache and the use of SSD’s in helping in your storage sizing efforts.

Let’s assume you’ve already done all of that and now you want to focus on other sizing information.  What I like to tell customers is VDI requires some hardware.  “Some” is a relative term but as you scale from 100’s of desktops to 1000’s of desktops you will soon find out that you need to understand some of the hardware sizing rules of thumb.  vSphere 5 and VMware View 5 have done some really really cool things around driving more efficiencies in regards to hardware.  Remember, “efficiency in regards to hardware” is all about driving as many VM’s (Desktops etc) as you can on the amount of hardware you have. 

So here are a couple of cool “rules of thumb” you should keep in mind when sizing the front side of your View 5 environment.  By the way, your mileage will vary on this, I’m guessing someone can tell me that they get 10x the numbers I’m putting here but at the end of the day, I like to be a little conservative.  I’m also using the numbers VMware has published.  These numbers are also based on the use of VMware View Planner.

• Desktops per CPU Cores: I get asked this a lot “What is the rule of thumb on the number of VM’s per core”.  In View 4.x the number was roughly 7 VM’s per core.  In View 5 they have done some really nice optimization around CPU scheduling.  Optimization is another word for “Put more VM’s on a given host” 🙂  In View 5 the number looks to be around 14.  This is based on 1vCPU per desktop. <see page 15>. 

• Desktops per Host Memory:  Normally for Windows 7 (32bit), I recommend 1GB per desktop (1.5GB – 4GB per desktop on 64bit Win7).  For 32bit Win7 if you look at the chart on page 19 you can see that if you have a physical host with 96GB of memory, in 4.1 you would typically see about 84 desktops per 96GB of Host Ram and with 5.0 it gets a little better at 91.  96GB’s is usually the sweet spot for most of my customers.  If you are those that like to use 256GB of memory per host (this REALLY helps cut down the number of blades you would need to deploy) then your numbers for 4.1 was 223 and at 5.0 it ooched (technical term) up to 242 Desktops/VM’s.

• Desktops per X Bandwidth – Lately I’ve been speaking to more and more customers that have RoBo (Remote Office/BranchOffices) and it seems T1 lines are a popular choice for them 😦  In View 4.5 and 4.6 the rule of thumb was about 5 to 7 desktops per T1 (or about 250k per desktop) and in most cases customers had 10 to 15 desktops they needed to support so a single dedicated T1 lines just wasn’t enough to support PCoIP.  You could switch to RDP and my understanding is that bandwidth number would drop to about 100k per desktop.   The VMware View team really spent a TON of time trying to optimize the hell out of View 5 and I certainly think they did a fantastic job.  In fact, if it’s any indication to how serious they took to optimizing PCoIP just notice that the first few pages of the doc is all about bandwidth !!  Things like Client-Side Caching, Lossless Codec Optimization as well as their “Build to Lossless” features really do a TON to reduce the amount of bandwidth needed.  Keep in mind, in a LAN (local) environment this probably doesn’t have nearly the effect as it will on WAN connected clients.  So, the disappointing thing is they really don’t call out a “Desktop per X Bandwidth” type metric which seems very disappointing.  I read over on Andre’s blog (MyVirtualCloud.Net) that the number is around 70Kbs to 150Kbs per desktop so I’m going to lean towards that number for sizing.  Keep in mind, those numbers are based on a lot of the tweaks that are called out in the document. 

• Number of View 5 Hosts per Cluster – this one gets missed a lot.  Andre wrote about it here but it bears to be repeated.  View 5 still has the limitation of 8 Hosts per Cluster. 

Fun with Numbers:

So, lets assume you are going to deploy a Virtual Desktop system for your environment.  You want to start off with 100 for the POC but you need it to scale to 1000 desktops.  If you need to eventually support 1000 desktops, lets assume 96GB of Host memory is the way you will be going then you will need 11 hosts to support it.  If you want to set this up in a HA Cluster then you will need to setup 2(ea) Clusters.  Also, don’t forget that if you want HA then you need to add overhead into your design to accommodate for that.  FUN !!!

The net-net is to use these rules of thumb to help guide you in the initial sizing of your deployment.  I can’t urge you enough to download and read through the whitepaper above !!

@vTexan