A Review of Horizon View 5.2 Limits and Maximums

Giving continuity to my VMware View Limits and Maximums series (VMware View 4.0 | VMware View 5.0) I am now releasing an updated version for Horizon View 5.2.

As an administrator or architect you should always make sure that your design sizing’s are within the product’s Maximums and Limits in order to be entitled to VMware Support.

Horizon View 5.2 introduced many new features and improvements, including a more scalable architecture that now supports 10,000 desktops using a single vCenter Server (I’ll soon post an article about ups and down for single vCenter architecture).

The scalability improvements introduced in Horizon View 5.2 come from four very important features: Multi-Network Support, Accelerated View Admin Performance, Space Efficient Disk Utilization and support for 32 host clusters when using NFS or VMFS. Read more about the new Horizon View 5.2 features in What’s New in Horizon View 5.2 (beyond Marketing).




The limits may vary according to the releases in use. The limits in this post are specific to Horizon View 5.2 and vCenter Server 5.1. The comparisons are against limits published with VMware View 5.1

· 32 Hosts per Cluster when used with VMFS changed from 8 Hosts per Cluster

· 32 Hosts per Cluster when used with NFS did not change

· 16 VM’s per CPU core – did not change

· 1,000 VMs per View Composer desktop pool or replica  – did not change

· 140 VMs per LUN with VAAI support – did not change
Without VAAI support the recommended number is still 64 VMs per LUN. This limit comes from the number of SCSI LUN reservations caused by VM metadata updates. With VAAI the reservation happens at the VMDK level.

· 10,000 VMs per vCenter – changed from 2,000 VMs per vCenter
VMware is now officially supporting 10,000 virtual desktops per vCenter Server, installable or appliance. This is a major architectural change and should drastically reduce View pod footprint and enables easier backup and DR for the entire solution.

· 1000 VMs per host – did not change
This limit is established by vSphere 5, not VMware View.



Maximum Number of Connections

· 1 Connection Server with Direct connection, RDP, Tunneled or PCoIP, 2,000 – did not change

· 7 Connection Servers (5+2 spares) Direct connection, RDP or PCoIP, 10,000 – did not change

· 1 Connection Server with PCoIP Secure Gateway, 2,000 – did not change

· Total HTML 5 connections per pod, 256 (To be Confirmed) – New Limit
This is a new limit for connections coming via HTML5 protocol.


I find amusing to identify how and when each component of the overall solution was improved or upgraded. The table below demonstrate when each component was upgraded and what is the new limit.


Screen Shot 2013-02-08 at 8.03.20 PM 


This article was first published by Andre Leibovici (@andreleibovici) at myvirtualcloud.net.


Skip to comment form

    • Jaime Taylor on 02/20/2013 at 10:41 am

    Did VMware change their officially supported number of desktops to 10,000 after publishing the “What’s New” PDF? It states that vCenter now supports 6,000 desktops.


  1. Hi Andre,

    In your post you mention that the maximum desktops per pool is unchanged at 1,000 but in the spreadsheet you have it as 2,000. Just curious as to which is correct.

  2. Jamie, this seems to be a miss-communication between areas. I’ll follow up on that internally. The official number is 10,000 desktops AFAIK.


  3. Good catch. What is being supported is 2,000 desktops per pool with Single vCenter Pod, or 1,000 desktops per pool when multiple vCenters are in use. I know it doesn’t make sense but these numbers are the validated numbers by QE.


    • Marc Pituley on 02/20/2013 at 2:34 pm

    Will View 5.2 be compatible with vCenter 5.0?

  4. Yes, but some of the new limits and maximums will only apply when you use Horizon View 5.2 and vCenter 5.1.


    • sfayyaz on 02/21/2013 at 1:53 pm

    can you elaborate on the 256 HTML5 connection limit per pod pls?

  5. I am still trying to confirm this number. I’ll get back to you as soon as possible and update this blog post.


  6. Is Vmware View replaced by Vmware Horizon View ?
    Here it’s called Horizon View: http://www.vmware.com/products/view/features.html
    But here its still called Vmware View, and as release 5.1 – not 5.2: https://my.vmware.com/web/vmware/info/slug/desktop_end_user_computing/vmware_view/5_1

  7. I have two questions about the number of VMs per VMFS datastore limit:
    “Without VAAI support the recommended number is still 64 VMs per LUN.”

    I cannot find an official statement from VMware about this limit. The only limit is the one I find in this document: http://www.vmware.com/pdf/vsphere5/r51/vsphere-51-configuration-maximums.pdf
    Powered?on virtual machines per VMFS volume = 2048

    – Do you have a link to an official statement from VMware about this recommended number of VMs (64) per VMFS volume?
    – Does this recommendation also apply to local storage, using a Fusion-IO card for linked clones for example?

  8. Sven,

    The numbers provided by VMware are officially tested and values. There are so many possible combinations that it is impossible to validate all of them. Despite not officially supported, you may go beyond tested values if you feel confident that you have the right infrastructure set to support the new values.

    The same apply for PCIe Storage Class devices, you may populate with more VMs as long you can drive enough IO and throughput to support operations at peak time, specially refresh and re-compose.


    • mn on 03/07/2013 at 10:48 pm

    Hi Andre,

    I’d like to know the requirements for vCenter and SQL server which support 10,000 desktops.

  9. mn,

    vCenter – 64b Win Server 2K8 R2 Enterprise, 10GB RAM, 4vCPU, 50GB Disk
    SQL – should not really change.


    • Sachin on 05/14/2013 at 7:29 am

    Great post Andre! I have a couple of questions.

    I know 32 hosts is a new max, but was that per instance of View or vCenter?

    Also, I understand that the max number of desktops has increased from about 2,000 to 10,000 with View 5.2. I know that sometimes one should not get close to a max because performance can suffer or it is in practice just not wise. So, I’m wondering if VMware really suggests getting close to the new 10,000 max.

    We’re trying to maximize the number of desktops we can support in a single instance of vCenter.

  10. Sachin,

    32 hosts is the maximum number of hosts per vCenter Cluster. You may have more than 32 hosts in a View environment.

    10,000 desktops per vCenter is supported but I would recommend not going close to the limit due to the size of the failure domain and also because of the reduction in concurrent operations.


  11. Hi Andre,

    I have 2 question to the maximums:
    1. 1000 VMs per host -> in the vSphere 5.1 Configure Maximums document there are 512VMs per host or did I get something wrong?
    2. What is exactly this 5+2 spare? 1 Std Connection Server + 4 Replica but what are the 2 spares?

    Thank you.

    best regards

    • sri on 10/29/2013 at 1:47 pm

    2 spares will be in disabled state in view there are not used if something goes bad this will come up

  12. Manfred,

    1 – If you look at the table you will find out 512 VM’s per host is the supported limit.
    2 – There’s no concept of StandBy connection servers. All servers will be utilized at same time; unless you manually disable them. I recommend leaving them all On to spread the load across the cluster.

  13. Please note ‘A Review of Horizon View 5.3 Limits and Maximums’ is already available.

    • ILYA KOZLOV on 02/03/2014 at 2:52 am

    Is there a maximum number of vCenter-servers that I can add to one Horizon View Server 5.2 or 5.3?

  14. Ilya, yes, it’s five. One for each 2,000 desktops, however you can also have a single vcenter. I would recommend watching this video.


  15. Andre, I’m trying to find the supporting details around origin of the recommended number of 140 VMs/LUN with VAAI. I can’t find this limitation documented in any official VMware whitepapers, KB articles or design documentation. The only concrete limit I was able to find was the vSphere VMFS limitation of 2048 powered on virtual machines per volume, and the number of files per VMFS volume, as was mentioned in an earlier comment.
    Since the ATS VAAI primitive offloads the locking to the VMDK from the LUN, it would seem to me that the only reason for the to limit the number of VMs per datastore when VAAI is utilized is based on the average performance when utilizing “most” storage solutions which utilize the default HBA queue depth of 32. With the prevalence of all flash arrays, I’m seeing that many AFA vendors are making the recommendation to increase the Disk.SchedNumReqOutstanding and Disk.SchedQuantum numbers to the maximums to increase the total amount of throughput and IOPS to the array. What I’m really concerned with is that someone with an AFA solution would find this number here and think they’ve done something wrong based on a VMware specific limitation, when it’s actually based on average performance. If these are the numbers that have been validated by GSS as you’ve stated in an earlier comment, I’d think they should be included in the Architecture Planning documentation.
    Some of the other posts I’ve been reading to help me understand:

    Thanks Andre, love the site.

  16. elgwhoppo, sometimes the explanation is simpler that what you would expect. 140 virtual desktops per NFS datastore is what has been effectively tested by the Horizon View QE team prior to releasing the product. Test are normally baselines created using a certain amount of limited and limited to the hardware configuration.

    Is this NFS case, as an example, VMware was using Netapp with datastores that would only fit 140 virtual desktops from a capacity or performance perspective; therefore the number.

    It’s up to you as an architect and consultant do run your own tests and verify that the workload will fit your datastore design. The vSphere team has tested and support 2048, therefore that is also a limit. I’m not sure if this limit is due to technical constraints or purely due to what has been effectively tested by QE.

    For the 140 number, I actually had inside knowledge to what had been tested.

    I hope that answer your question.


Leave a Reply