Why Citrix + AHV provisioning path and management is superior to VMware Horizon

Posted by on January 19, 2017 in Citrix | 3 comments

In this post, I’ll contrast and compare the different management and provisioning path architectures between Citrix on Nutanix AHV using Machine Creation Services (MCS) and two leading VMware Horizon options. While there is always numerous options within deployments the examples here will be based on the best and leading alternatives. I’ve prepared a 5,000 and 25,000 user examples to illustrate how a common sized environment would look versus one at a larger scale. This will display the difference in how things scale and whether complexity increases or remains low.

The reason to look at this is to help understand how failures, patching, upgrades and human error might affect the resiliency of the provisioning path and management interface. If the control plane is down for the underlying hypervisor the VDI broker layer will not be able to provision or manage the desktop VMs. This can have serious implications for users as they may be unable to access resources if they are disconnected or logoff and when they return there are not enough available desktops due to a control plane issue.

On the operations side, this is an important discussion also, because organizations demand simplicity in architectures. They do not want solutions that are complex to set up and maintain. So I will also look at how many management interfaces the alternatives impose on admins and point any areas of concern.


Citrix + AHV 5,000 User Example

In the first example, we are looking at 5,000 XenDesktop users deployed on Nutanix AHV hypervisor. XenDesktop communicates directly to the AHV cluster via the Prism cluster IP address and utilized API calls to perform actions. Prism is the distributed management interface and runs as a service in the Nutanix controller VM (CVM) on each node. This means that Prism is always available during upgrades and should a node, CVM or a service fail one of the other nodes will accept incoming connections to Prism and API calls.

In the sample diagram below I’m showing XenDesktop connecting to a single AHV cluster running all 5,000 desktop VMs. This is to showcase the power and flexibility that AHV and Prism provide. AHV does not have a maximum cluster size limit like legacy hypervisors impose. With Prism running on every node in the cluster the management and provisioning operations for VMs and the cluster scale out linearly with the cluster. This means that there is no difference in the performance of provisioning or management operations whether a cluster is 3 nodes or 80 nodes. This allows architects to design for large clusters when applicable without any concerns over imposed cluster size limitations.

Should there be valid reasons the 5,000 desktops could be split into more than one cluster. Reasons for doing so might be workloads that don’t mix well or adversely affect desktop density or the desire to divide into distinct failure domains.


  • No Single Point of Failure (SPOF) for provisioning or management
  • Node or VM counts do not limit cluster sizes
  • Linear performance of control plane
  • Highly available control plane and provisioning path
  • Simple architecture that easy to deploy, manage and operate


  • VMware Horizon does not support AHV

VDI provisioning path.001


VMware Horizon 5,000 user example

In this first VMware Horizon example, we are looking at the classic way of deploying vCenter server. This scenario does not matter if you deploy Windows or vCenter appliance variations. In this classic method vCenter is a single point of failure (SPOF). This means that the environment can be severely impacted during upgrades and failures that take vCenter offline for more than a few minutes.

Another significant constraint to call out is that VMware does not recommend building blocks of infrastructure that host more than 2000 desktops. This means that each block will consist of a vCenter server and one or more vSphere clusters. In our 5,000 user example, this architecture forces us to have 3 vCenters and the number of clusters below them is open to how the architect wants to design based on requirements. By limiting the scale of each vCenter, VMware is keeping the performance and responsiveness within acceptable limits. But this approach, when scaled becomes inefficient because you are using additional resources and the number of items to manage and update continues to scale as you add users.


  • Fairly simple to deploy and is well understood after long VMware history
  • Widely supported by applications


  • vCenter is Single Point of Failure (SPOF)
  • vCenter is limiting factor of 2,000 desktops per vCenter
  • VMware composer SPOF for linked clone provisioning

VDI provisioning path.003


VMware Horizon 5,000 user example w/vCenter HA


This example is just an alternative to the previous one in that I’ve inserted the new vCenter High Availability (HA) option that was released in vSphere 6.5 recently. The vCenter Server Appliance (vCSA) must be utilized if you want to use this HA option. The sizing and architectures are the same. The primary difference is the availability of vCenter in this alternative. To deploy the vCenter HA config you are required to deploy 3 vCSA VMs for each vCenter that you want to be highly available. There will be an active, passive and witness VM in each deployment. Multiply this out with the three blocks required to deliver 5,000 users and we now have nine vCenter appliances to deploy, manage and upgrade.
This adds a lot of complexity to the architecture for the benefit of increasing the resiliency of the provisioning path and management plane.
  • HA option provides resiliency for vCenter features
  • Complex to deploy, manage & understand
  • vCenter HA option uses lots of resources with 3x virtual appliances each
  • Unclear how vendor plugs may work in this architecture
  • vCenter is still limiting factor for 2,000 desktop VM limit per vCenter
  • As design scales complexity increases by having so many management points

VDI provisioning path.004


Citrix + AHV 25,000 User Example

In this and the following examples, I have now scaled the number of users to 25,000 to see what effects this has on the different architectures and management experience. For the Citrix and AHV architecture, nothing changes here other than the number of users. Citrix can accommodate the large number of users within a single deployment. On the AHV cluster side of things, I have elected to evenly divide the users between four different clusters. I could have chosen a single cluster but that felt extreme, architects can also choose more clusters if that meshes with their requirements. Within Citrix Studio, each AHV cluster will be configured as an endpoint that can be provisioned against.

The point is that in the architecture organizations can accommodate large numbers of users with a small number of clusters of which all benefit from highly available provisioning and management controls. Each AHV cluster can be managed via the Prism interface built into the cluster or a Prism Central can be deployed to allow for global management and report. An important thing to note is that Prism Central is not in the provisioning path so does not have any effect on our architecture explained earlier.


  • No cluster size limits provides flexibility to account for budget savings and ability to meet requirements.
  • Highly available architecture at all levels with simplicity baked in.
  • Small number of clusters reduces node counts by saving on the number of HA nodes for additional clusters.
  • Global management functions without affecting provisioning redundancy via Prism Central.
  • Single Citrix deployment and management point for all users.


  • VMware Horizon cannot benefit from AHV

VDI provisioning path.002


VMware Horizon 25,000 User Example

Now taking a look at the expanded user environment with VMware Horizon architecture you can see that I’m showing the vCenter HA alternative. I think that if you have the option for a highly available control plane most will select that option so I’m not showing the classic single vCenter option.

The architecture is the same but you will notice a few things now that the user count has been scaled up to 25,000. We can no longer deliver that many users from a single Horizon installation (Pod). The maximum users within a pod are 10,000 so we now require three Horizon installs to meet our user counts. To be honest having three Horizon pods does affect the broker management experience but in this scenario has really no bearing on the cluster count or design.

Following the 2,000 users per vCenter rule we will need 13 vCenters to meet our 25,000 user requirement. To keep things clean the diagram shows just a single cluster attached to each vCenter but the 2,000 users could be split between a few clusters under each vCenter if that made sense.

You can see from the diagram that deploying 13 vCenters in HA configuration requires 39 vCenter appliances to be deployed and configured. Yes that’s right, Thirty-nine!! Just think about the complexity this adds to troubleshooting and upgrades. Each one of those appliances must be upgraded individually and within a short window to not break functionality or support. Upgrades now may force you to upgrade Horizon, Horizon agents, clients, vCenter and vSphere all within a single weekend. That’s a lot of work, best you could do is do one of the pods per weekend and now you’re exposing your staff to three weeks of overtime and loss of their weekends.


  • HA option provides resiliency for vCenter features


  • Crazy Complex to deploy, manage & understand at this scale
  • vCenter HA option uses lots of resources with 39 virtual appliances being deployed
  • Unclear how vendor plugs may work in this architecture
  • vCenter is still limiting factor for 2,000 desktop VM limit per vCenter
  • Three vCenter linked mode view to see entire infrastructure view
  • Three different Horizon management consoles to configure and control users
  • Composer is an SPOF for linked clone provisioning per Horizon Pod

VDI provisioning path.005


VMware Horizon 25,000 users on VxRail

In this last example, we are going to adjust the previous example and look at what would change if it was deployed on VxRail appliances that utilize VSAN for storage. The Horizon and vCenter / vSphere architecture would be the same the only thing to highlight is what is added by VxRail.

Each of the clusters that provide resources for each 2,000 user block would be a VxRail cluster. These clusters have a VxRail virtual appliance VM that runs on it and is used for appliance management and upgrades. Given this scale, we now see that each of the 13 clusters will have its own dedicated VxRail manager and does not offer a global management function that Prism Central offers. VxRail manager is not in the provisioning path, but does add to the complexity of managing this type of deployment and should be considered before selecting.


  • Same as previous example


  • Same as previous example
  • 13 Different VxRail managers adds needed complexity
  • VxRail is an SPOF as a single VM running on each cluster for management operations
  • VxRail includes additional software that potential exacerbates this further. (Log Insight, ESRS, etc.)

VDI provisioning path.006



Just to wrap up my thoughts and examples here is that whether you’re designing a small or large scale VDI environment it’s important to understand how the management and provisioning structures will function. These are important to how highly available the solution is and what level of effort will be required to support it from day 2 and on. The resiliency and simplicity that Citrix offers when connect to Nutanix AHV cannot be rivaled by any other alternatives today.


About Brian Suhr

Brian is a VCDX5-DCV and a Sr. Tech Marketing Engineer at Nutanix and owner of this website. He is active in the VMware community and helps lead the Chicago VMUG group. Specializing in VDI and Cloud project designs. Awarded VMware vExpert status 6 years for 2016 - 2011. VCP3, VCP5, VCP5-Iaas, VCP-Cloud, VCAP-DTD, VCAP5-DCD, VCAP5-DCA, VCA-DT, VCP5-DT, Cisco UCS Design


  1. “XD Infra” is a pain to install and manage. You’ve made it look simple.

    • I think that XD and Horizon have similar levels of effort around installing and maintaining the management servers. This was not meant to focus on that, but how they work with infrastructure for provisioning.

    • Have you ever looked at a modern age XenDesktop version (7.x)? This can be installed in 5 min and all you need to do it to click next a few times. Also the management aspect got sooo much simpler over the last couple of years. A recent version of XenDesktop or XenApp cannot be compared to yesterdays Presentation Server.

Leave a Comment

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