A Review of VMware View 5.1 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 VMware View 5.1.

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

VMware View 5.1 introduced many new features and improvements, however this release is not particularly focused on scalability from a maximum and limits perspective. The scalability improvements introduced in View 5.1 come from three very important features: View Storage Accelerator (CBRC), View Composer Array Integration, and support for 32 host clusters when using NFS. Read more about the new VMware View 5.1 features in What’s New in VMware View 5.1 (beyond Marketing).



The limits may vary according to the releases in use. The limits in this post are specific to VMware View 5.1, View Composer 3.0 and vCenter Server 5. The comparisons are against limits published with VMware View 5.0


· 8 Hosts per Cluster when used with VMFS – did not change
This limit is hard-coded in View Composer; however it comes from a VMFS limitation on the number of hosts that can simultaneously read from a single VMDK. This VMDK in a VMware View environment with View Composer would be the Replica disk.

· 32 Hosts per Cluster when used with NFS – changed from 8 Hosts per Cluster

· 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.

· 2,000 VMs per vCenter – did not change
Despite the limit above I recommend you to keep this number at around 1,500 desktops and observe vCenter response times as you scale up to 2,000. VMware View generates a large amount of operations (power on and off, reconfiguration, cloning, snaps) that consume vCenter resources.

· 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



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



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




8 pings

Skip to comment form

    • Martijn koopman on 05/21/2012 at 11:22 pm

    Hi Andre,

    Thanks for the update, however one remark. Vcenter limit is 10.000 from vcenter 4.1 and above, See the architecture planning guide page 50.

  1. @Martijn koopman
    10K VMs is the supported number for server workloads. For VDI the maximum supported is 2K per vCenter. A maximum of 5 vCenters per View Pod will allow you to scale the solution up to 10K desktops.


    • Martijn koopman on 05/23/2012 at 5:22 am

    That’s not wat Robert B. told me 🙂

  2. @Martijn koopman
    I think there was a misunderstanding between you and Robert B. Please refer to page 50 (VMware View Building Blocks) of the VMware View Architecture Planning Guide for View 5.1.


    • Martijn koopman on 05/30/2012 at 2:51 am

    Thanks Andre!
    Hoewever I’m getting pretty confused by now

    Will forward you an email if you don’t mind

  3. I do not understand the difference between 10k or 2k – that difference is quite A LOT. I cannot image “VMware View generates a large amount of operations (power on and off, reconfiguration, cloning, snaps) that consume vCenter resources.” – uses THAT much resources that vCenter ‘breaks’. So if I would have a server workloads, I’m not allowed to power on/off, reconfig VMs etc?!? Seems rather odd, and since VMs can scale larger then ever, isn’t it just a case of adding more resources to the vCenter and SQL server?


  4. @Bouke Groenescheij
    2,000 desktops is the number that has been currently validated by VMware QE group and is supported by the Global Support Service. The number of desktops supported will greatly vary according to the type of use.

    10K is the limit tested by the platform team, but this is without VMware View, which doesn’t involve multiple simultaneous power-on, power off, recompose etc.. operations.

    Depending how your VDI implementation is used you could easily run out of recourses within vCenter Server if there are many concurrent operations, such as recomposes, power on or power off.

    If your workload is static you may go beyond 2K desktops but be aware of the supportability issue.
    I am writing a new article to talk specifically about this subject.


    • Ibrar on 07/18/2012 at 10:42 am

    A View Block which is one vCenter delineation – but includes the entire management block to manage the block is MAX 2000 Virtual Desktops.

    You can have x5 VMware View Blocks inside one VMware View POD.
    One VMware View therefore consists of 10,000 virtual desktops.

    One POD will therefore have 5 management blocks to manage each cluster.

    Best way to scale a View environment is block by block until you build one POD.
    Then start All over again 🙂



    • Ronald on 09/05/2012 at 7:34 am

    I’m looking for the maximum number of pool you can have in a view implementation. I can not find a number any where. Do you know if there is a limit ?


    • chadd on 12/12/2012 at 5:09 am

    “140 VMs per LUN with VAAI support”

    What issues will be seen if you go over 140?

  5. @chadd
    Those are VMware validated numbers. You may go over 140 but should pay attention to common storage metrics, such as latency, response time, IOPS always ensuring the desktops are responsive enough for your use case.


  6. @Ronald
    I don’t think there is a physical limit on the number of pools you may have in a single View deployment. However, I can foresee you having latency and slowness to work on the View Manager FLEX interface, as it may get slow.


    • Munna. on 02/18/2013 at 8:53 am

    I am using VMware View 5.2.0. The problem is when i am using Autocad 2012 & 2013 in View Desktop, The Mouse is not working as expected-Like Physical machine. Lagging mouse performance in View Desktop. Is there any optimization for mouse in View.

    Thnaks in advance

  7. @Munna.

    VMware View 5.2 has not been officially released. If you are participating in the Beta I would recommend you to asking in the Beta Community. Sorry, but I am under NDA and not allowed to respond to you question here.

    Thanks for your comprehension.


    • Mulford on 04/23/2013 at 8:47 pm

    The number of virtual machines per LUN (140/VAAI) is when they are linked clones? If so, what is the limit if I want to use full virtual machines? It should be SIOC enabled for this?

    I am quite confuse because I have been reading a lot of documents about “how many VMs per LUN/Datastore” and the one of the best I found says 20 VMs (I guess Full VMs) per LUN even using VAAI.

    I had working with View Planner 2.0 and different test using IOmeter and the sizing of the LUN is one of the most complicated steps (also storage performance/IOPS ).

    Thanks !!

  8. Mulford, those are VMware validated numbers. You may go over 140 but should pay attention to common storage metrics, such as latency, response time, IOPS always ensuring the desktops are responsive enough for your use case. The same is valid for Full Clones.

    SIOC won’t solve low performing storage array, but rather will not let a noisy VM steal IOPs from other VMs. It will promote fairness.


    • vsoft (@vsoftinfotech) on 01/17/2014 at 12:32 am

    In case view 5.1 How many Linked clones VMs we can have in the VMFS datastore and how many full clones Vms in the VMFS datastore.

  9. vsoft, the numbers above are VMware validated numbers. You may go over 140 VMs per datastore/LUN but you should pay attention to common storage metrics, such as latency, response time, IOPS always ensuring the desktops are responsive enough for your use case. The same is valid for Full Clones.

    • vsoft (@vsoftinfotech) on 01/17/2014 at 6:35 pm

    Thanks for the reply and congrats for new job. Just one more question. In case of view 5..0 or view 5.1 can i have 32 node VMFS cluster with full clones.

  10. vsoft, yes, you may have a 32 node cluster with VMFS datastores. However, you should not overload each individual datastore. If you have VAAI enabled, you should place a maximum of about 140 desktops in each LUN. If you are using NFS, this number is higher, but you also should pay attention to latency and IOPs for each individual datastore/export.

    Thanks for the congratulations!

  1. […] Comme évoqué plus haut, les clusters View utilisant du stockage NFS peuvent supporter jusqu'à 32 hôtes. Il me semblait intéressant de rappeler les limitations de cette version (d'après l'article d'Andre Leibovici à ce sujet): […]

Leave a Reply