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).
Limits
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
History
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.
16 comments
1 ping
Skip to comment form ↓
Martijn koopman
05/21/2012 at 11:22 pm (UTC -7) Link to this comment
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.
Andre Leibovici
05/22/2012 at 11:39 am (UTC -7) Link to this comment
@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.
Andre
Martijn koopman
05/23/2012 at 5:22 am (UTC -7) Link to this comment
That’s not wat Robert B. told me
Andre Leibovici
05/25/2012 at 9:59 am (UTC -7) Link to this comment
@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.
Andre
Martijn koopman
05/30/2012 at 2:51 am (UTC -7) Link to this comment
Thanks Andre!
Hoewever I’m getting pretty confused by now
Will forward you an email if you don’t mind
Bouke Groenescheij
06/05/2012 at 1:09 pm (UTC -7) Link to this comment
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?
Cheers,
Bouke
Andre Leibovici
06/05/2012 at 2:11 pm (UTC -7) Link to this comment
@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.
Regards,
Andre
Ibrar
07/18/2012 at 10:42 am (UTC -7) Link to this comment
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
Regards
Ibrar
Ronald
09/05/2012 at 7:34 am (UTC -7) Link to this comment
Hello,
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 ?
Regards,
Ronald
chadd
12/12/2012 at 5:09 am (UTC -7) Link to this comment
“140 VMs per LUN with VAAI support”
What issues will be seen if you go over 140?
Andre Leibovici
12/12/2012 at 11:49 am (UTC -7) Link to this comment
@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.
Andre
Andre Leibovici
12/12/2012 at 11:51 am (UTC -7) Link to this comment
@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.
Andre
Munna.
02/18/2013 at 8:53 am (UTC -7) Link to this comment
HI,
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
Andre Leibovici
02/18/2013 at 9:51 am (UTC -7) Link to this comment
@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.
Andre
Mulford
04/23/2013 at 8:47 pm (UTC -7) Link to this comment
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 !!
Andre Leibovici
04/25/2013 at 4:12 pm (UTC -7) Link to this comment
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.
-Andre
VMnerds blog » sortie de View 5.1
05/19/2012 at 1:49 pm (UTC -7) Link to this comment
[...] 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): [...]