About a month ago I was approached by a customer that recently talked to someone over at VMware about the amount of Microsoft server licenses needed for XenDesktop vs. View.  Essentially, they were told that for a 2,000 user deployment, they would need 5 Microsoft Windows 2008 Servers for VMware View and a staggering 48 Microsoft Windows 2008 Servers for XenDesktop.


After further review here is the breakdown they were told they needed for a VMware VDI plus application virtualization solution:

(2) View Connection Servers
(2) ThinApp Servers (File Server)
(1) vCenter\View Composer Server

Now, let’s take a look at what they were being told you need for a Citrix VDI plus application virtualization solution:

(2) XenDesktop Controllers
(2) Web Interface Servers
(4) Provisioning Servers
(40) XenApp Servers

Obviously, the key to the large discrepancy in server counts comes down to XenApp.  How can this be?  It turns out they are using XenApp for application hosting and not applications streaming.  In addition, they are telling the customer that one XenApp server can only support 50 users.

Application Virtualization: Setting the Record Straight

There are so many things wrong with this math (fuzzy math, if you will).  First, let’s talk about application virtualization and the differences.  There are two types of applications virtualization that XenApp can provide; application hosting and application streaming.  To get the proper definitions I decided to use our eDocs site (http://www.citrix.com/edocs).

Application Hosting
Applications are installed on the server, where the processing takes place, and accessed from the server. This is the traditional XenApp application delivery model. For many organizations, this provides the lowest cost of ownership for IT resources because it provides the greatest scalability.

Application Streaming
Executables for applications are put in profiles and stored on a file server or Web server (the App Hub). When launched, the files required to execute the application are streamed to the user device, and application processing takes place on the user device instead of the XenApp server. When applications are streamed to the user device, the user experience is similar to running applications locally. After applications are cached on the user device, users can continue running the apps after disconnecting from the network (referred to as offline access).

Ok, so now for plain English.  A hosted application is installed, then published, on the XenApp Server.  A user launches this published application from their device and it appears to be running locally.  However, what the user is seeing is simply screen pixels of the application.  If you check Task Manager on the client device you will see that the CPU and RAM consumption is not happening there.  Rather, the XenApp server is doing all the heavy lifting and simply sending the screen pixels to the client.

So, application streaming is the opposite.  Instead of the application being installed on the XenApp Server, it is packaged into a profile.  To create this package the application install is run on a clean workstation and everything that happens during that install is captured into a profile.  The profile is then published through XenApp.  However, when the user launches the application, the entire profile (essentially the entire application) is copied to the end device.  In this case, the end device’s CPU and RAM are doing all the heavy lifting.

Why is this important to this conversation?  Well, while Citrix has two major tools (application hosting and application streaming) in its tool bag, VMware only has one.  When it comes to application virtualization VMware has ThinApp which closely lines to XenApp application streaming.  They do not have an equivalent to XenApp application hosting.

Back to my customer example.  Why 40 servers for Citrix’s application virtualization?  This is because they were comparing ThinApp to XenApp application hosting.  That is like comparing a paper and pencil to an iPad.  Two completely different technologies.  Is it too obvious to say now that the iPad costs more than the paper and pencil but can do so much more?  Oh, guess I just did.

Provisioning: To PVS or Not to PVS, That is the Question.

Now that we are beyond the application virtualization part, let’s look at the next thing that bumps up the number of Windows Servers for the solution.  VMware told the customer that you need Provisioning Servers (PVS) for a VDI solution.  However, that has not been true since Citrix introduced XenDesktop 5.0 back in the Fall of 2010.  XenDesktop 5.0 introduced Machine Creation Services (MCS) as an alternative for provisioning virtual desktops.  Essentially, MCS works the same way VMware View creates their desktops.  It is based on snapshot technology.  So, with MCS, there is not a need for a single PVS server.

Another thing to keep in mind is that VMware does not have an equivilent to PVS.  They only have an equivilent to MCS.

Let’s Get Down To Brass Tacks

In order to properly compare Citrix XenDesktop to VMware View, both with application virtualization, we have to level the playing field.  Since VMware cannot do application hosting, let’s take that out of the equation.  Also, since VMware cannot do provisioning the same way Citrix can do it with PVS, let’s take that out of the equation.

So, let’s look at the bare-minimum components needed to stand up both a Citrix XenDesktop solution and a VMware View solution.  For the example, we are going to assume a 500 user environment.

Also, to be fair, I pulled the best practices directly from the VMware View Architecture Planning guide (http://pubs.vmware.com/view-50/topic/com.vmware.ICbase/PDF/view-50-architecture-planning.pdf)

Citrix XenDesktop: Scaling for 500 Users
(2) XenDesktop Controllers
(2) XenApp Servers (Application Streaming)
(2) Microsoft SQL 2008 Servers (SQL Replication)

Summary:  In this solution a total of (6) Windows 2008 R2 Servers are required and (2) Microsoft SQL Server licenses.
* Above solution assumes all components will be hosted on XenServer (which is included with XenDesktop – no extra charge)

VMware View: Scaling for 500 Users
(2) View Connection Servers
(2) ThinApp Servers (Application Streaming) (File Server)
(1) vCenter\View Composer Server
(2) Microsoft SQL 2008 Servers (SQL Replication)

Summary: In this solution a total of (7) Windows 2008 R2 Servers are required and (2) Microsoft SQL Server licenses.

As you can see, a simple 500 user install actually uses 1 more server with VMware than with Citrix.  This additional server comes from their need to have a Virtual Center Server.  This is because VMware only supports ESX with View and not any other hypervisor.  Since XenDesktop supports all the leading hypervisors on the market (Citrix XenServer, Microsoft HyperV, and VMware ESX), we can leverage XenServer which does not have a need for a server the way ESX does for Virtual Center.

Now, just for fun, let’s up the ante.  Let’s look at what a 20,000 user environment would look like.  Again, just bare-minimum.

Citrix XenDesktop: Scaling for 20,000 Users
(3) XenDesktop Controllers
(2) XenApp Servers (Application Streaming)
(2) Microsoft SQL 2008 Servers (SQL Replication)

Summary:  In this solution a total of (7) Windows 2008 R2 Servers are required and (2) Microsoft SQL Server licenses.

VMware View: Scaling for 20,000 Users
(10) View Connection Servers
(2) ThinApp Servers (Application Streaming) (File Server)
(2) vCenter\View Composer Server
(2) Microsoft SQL 2008 Servers (SQL Replication)

Summary: In this solution a total of (16) Windows 2008 R2 Servers are required and (2) Microsoft SQL Server licenses.

So, with scale the Citrix solution gets better.  Let me review how I came up with these numbers.  Again, I used best practice guides from both Citrix and VMware.

Let’s start with the Citrix solution.  A XenDesktop controller server can support up to 10,000 virtual desktops.  However, this is a pretty beefy server.  Our best practice guide says that a (4) Quad Core server is required.  Then, for HA, you would want one extra.  That is how I came up with 3 XenDesktop Controllers.  XenApp when used for streaming only can support a large number of users.  Essentially you scale XenApp the same way you would plan for Zone Data Collectors (ZDC) for a large farm.  A farm supporting 20,000 users would only require 2 ZDC’s since applications are not really running from it.  They ae only there to provide the application list and user access control.

Now, onto the VMware View solution.  VMware’s guide says 1 Connection Server with “Direct connections, RDP or PCoIP” supports 2,000 users.  Using that math I came up with 10.  However, that does not count in any HA.  I am sure that number would have to be increased by at least one.  I could not find a lot of scaling metrics on ThinApp, so I assumed it would peform the same and 2 servers could handle 20,000 users.  Since ThinApp is really just a file server, I think this is fair to say.  Finally, the number of vCenter servers increased by 1.  VMware’s best practice guide says 10,000 VMs per vCenter.  Again, I am not sure about HA.  Maybe I need to add 1 more to have HA.

The Court Rules in Favor of…..Citrix

As you can see there is quite a bit of FUD out there surrounding the number of Windows Servers required for a Citrix solution vs. a VMware solution.  If you compare “apples to apples”, than Citrix comes out looking better.

In the Spirit of Jerry Springer, Here is My “Final Thought”

An old friend use to say, “just because you can do something doesn’t mean that you should do something”.  In this case, just because the Citrix solution can be brought down to the level of the VMware solution doesn’t mean that you should.

Let’s start with MCS.  In my humble opinion, I would not use MCS for a large scale deployment.  It has been tested and proven that it can scale, but I still would not.  Citrix does not charge extra for PVS.  This is because we want you to use it for provisioning your desktops.  PVS scales extremely well.  In the above example of scaling for 20,000 users, 8 PVS servers would fit the bill if they are spec’d properly.  Each PVS server could handle 3,000 virtual desktops.  8 PVS servers could handle 24,000 so you would have HA built in.  That means that the 20,000 user scale goes up to a total of 15 servers.  Still 1 less than the VMware solution.

In the world of virtual servers and Microsoft EA agreements, what really is the big deal of deploying 8 virtual PVS servers to handle all the provisioning?  In the end, your life will be easier as you try to update and maintain the golden image.  Trust me when I say you don’t want to maintain an image using View Composer, or MCS for that matter.

Now, let’s talk about XenApp.  For the purpose of comparing “apples to apples”, I planned for XenApp to be streaming only.  If I can get on my soapbox for a second I will tell you why streaming (either with XenApp or ThinApp) may not make sense.

Let’s assume you have one golden image to maintain.  That image is only the operating system.  Now, you use either XenApp streaming or ThinApp to deliver applications into that golden image.  This means that each time a user launches that application, all the runtime files are going to be copied over the network to that virtual desktop.  The good thing is that now the files are local to the VM so when the users closes and relaunches the application it should be faster the next time.  Now, multiply that times the number of users we are talking abou there (say, 20,000).  That is silly.  Things get even worse though.  If the desktops are non-persistent (and they almost always should be), this local cache is “thrown away” when the user logs off because the VM reboots and goes back to the golden image state.

Now, you can get around this caching over the network by pre-caching.  Pre-caching allows the administrator to open each application while the golden image is in read-write mode so that the cache gets captured in the golden image.  Problem solved, right?  Well, how about when you update that application?  Are you going to allow that update to get copied on each run only to get thrown away with each logoff\reboot?  Probably not.  So now you are going to crack open the golden image again just so you can get that update back in the cache.

Well, after all this updating of the golden image you start to ask yourself, why am I not just installing the application into the golden image without the extra application packaging layer?  Good question.  Off my soapbox now.

So, this brings us back to XenApp.  In a perfect VDI deployment, I would want to leverage XenApp to “host” (not stream) the applications.  This serves three purposes.  One, it makes it easier to update the applications as they are not part of the golden image and are hosted on XenApp.  Two, it takes processing cycles and memory from the virtual desktop.  This means that each virtual desktop will require less CPU and RAM than if you had the application as part of the golden image.  Finally, it gives the users the flexibility of just launching applications instead of a full desktop.  Essentially, there are many times the user will not want a full desktop and just want to get to an application or two.

So, my final thought.  Just because you can create a bare-bones install of VDI using XenDesktop, if I were you I would not.  XenDesktop comes bundled (no extra charge) with PVS and XenApp for a reason, because they work great together.  So, if it were my install, I would leverage PVS and XenApp even though it does require more servers.

“Until next time, take care of yourself, and each other” ~ Jerry Springer.

* By the way – I am open for any comments on this matter.  I don’t claim to be an expert with VMware View.  If I have any of my architecture facts wrong, please feel free to comment.