I got an interesting item in my inbox from a friend who was speaking with VMware about their VDI solution.  He asked me if the information VMware was telling him was true. He was especially curious because he knew I wrote the Citrix XenDesktop Enterprise Designreference architecture that VMware was referencing to talk about how much better View was. VMWare’s approach is laughable.  They are taking a detailed consulting design document  and trying to compare it to the VMware View reference architecture, which if you read it like I have (wasted 2 hours of my life), you will quickly see it is high-level and full of marketing spin and provides no insight.  I, on the other hand, was trying to provide all of you in the community with insight into how to design a large, and complex customer environment with XenDesktop.  Anyways, I told him the angle they were using and he thought it was ridiculous.  I was going to leave it at that, but I’ve been seeing and hearing more about it from others so I thought I would provide all of you with the same information.  Let’s break it down: 

Scalability:

  • Misconception: VMWare says that XenDesktop has poor hypervisor scalability. They say that on a 16 core server XenDesktop can only support 40 users (3 users per core). 
  • Truth: The XenDesktop reference architecture for the hosted virtual desktops is 8 cores, not 16.  In the design phase, we estimated 40-50 VMs per server, which averages to 5-7 virtual desktops per core.  We were a little conservative as we were not sure how the unique applications would impact the system.  But you can look at Project Virtual Reality Check scalability white paper to get a good comparison of XenServer and ESX.  Although the design VMWare references was for XenServer, the same estimates would have been used if the hypervisor was running ESX.

Storage:

  • Misconception: VMware likes to say that XenDesktop is a storage pig in that we need a lot of storage associated with each virtual desktop. 
  • Truth: This particular design had a requirement to keep a few system items persistent across workstation reboots so we recommended the creation of a local, persistent disk of between 3-5GB to store items like event logs, performance metrics, antivirus definitions, etc.  This is not NAS/SAN storage; it is the storage on the physical XenServer.  Think about it. You buy an 8 core server, install XenServer, which is small, and the rest of the local storage is wasted.  We utilize that for the persistent store of the virtual desktops.  This means we cannot do XenMotion on the virtual desktops, but most customers I’ve spoken to do not have this requirement.  After looking at VMware’s reference architecture I don’t see any level of detail as to the amount of storage they require.  I wonder why not. 

Workloads:

  • Misconception: VMware states that they can get more users on a hypervisor than we can.
  • Truth: This is all around scalability tests, which I’m not a fan of.  I can easily find you 5 tests that show XenServer is better and another 5 that shows ESX is.  The VMware reference architecture had users connected for 14 straight hours, seems like a long workday to me. I have a question for VMWare: What company did you create this architecture for where users would work for 14 hours? Please tell me as I do not want to work there.  As we all know, the most typical system hit is during startup and logon. So by expanding the session time from a few hours to 14, the overall average utilization rates can be significantly lowered, thus providing an inaccurate estimate to the hardware
  • Truth: The Citrix Reference Architecture made estimates based on the applications and expected real user workload, not simple apps and 14 hour workdays.  VMware’s reference architecture was based on standard scalability samples shown below. If this was an actual user workload, I totally want to work for that company because that job looks so easy:
    • Microsoft Word – Open/minimize/close, write random words/numbers, save modifications.
    • Microsoft Excel – Open/minimize/close, write random numbers, insert/delete columns/rows, copy/paste formulas
    • Etc

RAM:

  • Misconception: The amount of RAM that VMware recommends in their reference architecture is nuts.  They say they can get 96 users on a server with 96GB RAM.
  • Truth: If you subtract the hypervisor overhead you are looking at “USABLE” RAM of about 800MB per virtual desktop.  I say usable because ESX has probably enabled memory ballooning.  It is true that XenServer does not have memory ballooning, but I would recommend customers disable this feature for virtual desktops.  On XenDesktop projects that use the ESX hypervisor, I also recommend disabling this feature.  Users and desktops are more dynamic than server workloads, meaning the RAM consumption is going to fluctuate greatly.  If RAM starts to decrease to the critical threshold, what happens to the hypervisor?  It must free up memory by paging this to disk.  Isn’t this an intensive system process that consumes more resources at a time when resources are scarce?

End Points:

  • Misconception: Vmware talks about the end points and only focus on thin clients and end points that we can repurpose with a Linux OS or locked down Windows OS. What about the newer end points that organizations have already spent money on? 

Provision:

  • Truth: Closer to the end, the reference architecture talks about the time to provision X number of linked clone desktops.  I’m not sure if this is automated or if an admin has to do each desktop one-by-one. I’ll give VMware the benefit of doubt here and say it is automated, but taking 161 minutes (2 1/2 hours) to provision 500 virtual desktops seems long to me.  I personally don’t think this metric is important, even though XenDesktop is measured in seconds.  If it is automated, you do all of this in the build out phase and not in production. So the time it takes is irrelevant to me. Why did they choose to include it? No idea

So my advice to anyone who is still reading this blog… Take everything you get with a level of skepticism.  Do your own due diligence and look at the details to see if things were glossed over or if an in-depth analysis and design was completed.  That recommendation even includes the materials I post.  I try to be open and honest in my blogs, white papers, TechTalks and videos, but I am a little biased to Citrix because they pay my bills. 


If you want to discuss more, or have further questions, then Ask the Architect



Daniel – Lead Architect – Worldwide Consulting Solutions