vSphere cluster design for 10 to 60 hosts: how many clusters, how many hosts per cluster and why

How many clusters 10 to 60 hosts need

In vSphere cluster design for 10 to 60 hosts, the estate needs as few clusters as its failure domains, workload types and licence boundaries allow. The hosts per cluster follow from the workloads with one host down, with at least 3 hosts on vSAN or 2 on NFS or Fibre Channel, well below the 96 hosts per cluster (64 with vSAN) in Broadcom’s Configuration Maximums. In most estates of that size this means a management cluster, one or two general production clusters, and a separate cluster only where a specific reason applies: databases and ERP whose licences are counted per host, a DMZ, virtual desktops or GPU hosts. Each extra cluster holds back at least one more host for failover and maintenance, so each split needs a reason that outweighs that host.

With VMware Cloud Foundation 9, the management domain is the first cluster: Broadcom’s design library asks for 3 hosts on vSAN in the Simple deployment model and 4 in the High Availability model. With vSphere Foundation, management VMs can share a production cluster.

Reasons to separate a cluster, type by type

Broadcom TechDocs VCF 9.0 design library: single-rack cluster model, management domain model, vCenter design (29 September 2026); vSphere 8.0 resource management (16 September 2026). Reasons for databases, DMZ and VDI are our reading.

A cluster is the boundary of vSphere HA, DRS, EVC and, on vSAN, of one datastore. VMs inside it share failover capacity and move between hosts without an outage.

Departments, test and production, or VMs with different backup schedules can share a cluster, separated by resource pools, tags and permissions. Our guide to the NSX distributed firewall covers network separation inside a cluster, which on VCF needs the vDefend add-on and on VVF is not available. Where the security policy accepts that logical separation, the DMZ can stay in a production cluster; where it asks for separate hardware, the DMZ becomes a cluster.

GPU hosts usually get a cluster of their own, since vGPU VMs move only to hosts with the same GPU type and the vGPU settings for DRS apply to the whole cluster, as our guide to GPUs in vSphere explains.

Management cluster and the VCF 9 management domain

Broadcom’s management domain model of 29 September 2026 lists what the management domain holds: ESX hosts, vCenter, a dedicated NSX Manager and SDDC Manager for all workload domains in the VCF instance, plus VCF Operations and VCF Automation in the first instance of a fleet. It can also run business workloads, and in that case Broadcom recommends four resource pools (management, NSX Edge nodes, user edges, user VMs), with the implication that “You must manually create the vSphere resource pools and manage their settings over time.”

The workload domain model recommends the opposite: “Use workload domains for customer workloads”, with the implication “Requires additional hardware.” Each workload domain is assigned a vCenter and an NSX Manager, with the NSX instance dedicated or shared, and the workload domain vCenter appliances run in the management domain.

Broadcom TechDocs, VCF 9.0 design library, vSphere single-rack cluster model, requirement VCF-CLS-REQD-CFG-002 (29 September 2026). Other clusters: additional management clusters and workload domain clusters.

Broadcom offers Simple and High Availability models for the management components: its single-site blueprint runs three-node clusters of VCF Operations, VCF Automation and NSX Manager. The blueprint with minimal footprint runs single VCF Operations and VCF Automation nodes protected by vSphere HA and deploys “all management and workload components” in one vSphere cluster. On vSphere Foundation, vCenter, VCF Operations and backup appliances can share the production cluster, with HA restart priority above the business VMs.

Our VMware optimisation service covers architecture updates of vSphere, vSAN, NSX and VCF, in agreed maintenance windows with a rollback plan. Tell us which VCF or VVF version you run and where your management appliances sit today.

HA and DRS settings per cluster type

The VCF 9.0 single-rack cluster model requires vSphere HA “to protect all virtual machines against failures” and vSphere Lifecycle Manager images for all clusters. It recommends admission control “for one (1) ESX host failure and percentage-based failover capacity”, with the implication “In a cluster of four (4) ESX hosts, the resources of only three (3) ESX hosts are available for use.” VM Monitoring is recommended on each cluster; it helps only applications that restart cleanly after a reboot.

For DRS, Broadcom recommends “the default fully automated mode with medium threshold” on all clusters. Its stated implication is that after a vCenter outage the mapping of VMs to hosts “might be difficult to determine”, so export VM placement on a schedule. EVC is recommended on all management domain clusters, at “the highest available baseline that is supported for the lowest CPU architecture”, and only where all hosts have CPUs from the same vendor. For workload domain vCenter appliances, the vCenter design recommends HA restart priority high.

Database hosts are chosen for socket size, so that large VMs fit one NUMA node. How much admission control holds back, and why it checks reservations rather than usage, is the subject of our guide to host consolidation and HA admission control.

VM-host rules and clusters bound by application licences

Some database and ERP licences count the cores of every host on which a VM runs or may run. The two designs are a separate cluster for that software or a host group inside a larger cluster with a VM-host rule. Which one the licence agreement accepts is a legal assessment for the company’s legal department.

Broadcom’s vSphere 8.0 resource management documentation, updated on 16 September 2026, calls rules where the VM group “must run on” or “must not run on” the host group required, and “should” rules preferential. It states that “DRS, vSphere HA, and vSphere DPM never take any action that results in the violation of required affinity rules.” The same page lists what is then not done: “DRS does not evacuate virtual machines to place a host in maintenance mode”, and “vSphere HA does not perform failovers.” It warns that “If improperly used, required VM-Host affinity rules can fragment the cluster and inhibit the proper functioning of DRS”, HA and DPM.

A required host group of three hosts therefore needs its own spare host: if one fails, HA restarts its VMs only on the two hosts left in the group. A preferential rule keeps HA working, but the VM may then run on a host outside the group. A separate cluster gives the same isolation with ordinary HA and DRS settings.

Cluster size limits and vSAN per cluster

Broadcom’s Configuration Maximums tool, read in October 2026, lists 96 hosts and 8,000 VMs per cluster for vSphere 8.0. The 96-host limit applies from 7.0 U1 and only to clusters without vSAN. For vSAN in VCF 9.1.1 the tool lists 64 hosts and 6,400 VMs per cluster, with 200 VMs per host on OSA and 500 on ESA. KB 317882 describes these figures as “tested, recommended limits”, and every cluster in a 60-host estate stays below them.

Each vSAN cluster has its own datastore, and its storage policies set a minimum host count, three hosts for RAID-5 2+1 on ESA and six for RAID-6 4+2 or RAID-5 4+1, where 4+1 spans five hosts and the sixth is its spare. Broadcom’s vSAN FAQ of 6 October 2026 recommends one host more than the policies require. Our vSAN ESA sizing guide turns used capacity into raw capacity and a host count per cluster.

Small clusters do not have to carry their own vSAN. The FAQ describes vSAN storage clusters, formerly vSAN Max, as “a centralized shared storage solution for your vSphere clusters”, and datastore sharing between vSAN HCI clusters as an option used mostly ad hoc. A GPU cluster of two or three hosts can mount a storage cluster, which needs at least 4 hosts of its own on a single site, or use NFS or Fibre Channel, where vSAN of its own would need more hosts than the compute does. A DMZ cluster can do the same only where the security policy accepts storage and a storage network shared with internal clusters.

One large cluster or several small ones

Every cluster sized for N+1 keeps one host in reserve, whatever its size. In a 4-host cluster that is 25% of the hardware, in a 16-host cluster about 6%. Under Broadcom’s VCF 9.0 licensing model, ESX hosts are the only assets that consume licence capacity, with “a minimum consumption rule of 16 cores per physical CPU” for most products, so reserve hosts carry licensed cores like any other host. Splitting a cluster into two adds one host, and its cores, to the reserve.

A cluster runs one vSphere Lifecycle Manager image, so a 32-host cluster patched one host at a time runs on two builds until all 32 hosts are done, and a fault in its cluster image or vSAN datastore reaches every VM in it. A failure while another host is in maintenance is more likely with 32 hosts than with 8, so from about 30 hosts consider keeping two in reserve. Primary licences are assigned to vCenter instances, so a split between VVF and VCF runs along vCenter boundaries, as our comparison of VVF and VCF explains.

Worked layouts for 12, 30 and 60 hosts

The layouts below are illustrative, not client cases; each cluster keeps one host for a failure.

Illustrative layouts, our arithmetic; minimum hosts per the VCF 9.0 single-rack cluster model (29 September 2026).

At 12 hosts, one cluster fits vSphere Foundation, or VCF with business workloads in the management domain and the four resource pools. Two clusters give VCF a management domain of its own at the cost of a second reserve host. At 30 hosts, the database cluster exists only if a licence counts hosts; otherwise its 4 hosts join production. At 60 hosts, one production cluster of 32 saves a host, but with two hosts in reserve it is back at seven.

The order of design steps is ours:

1. List the workloads with their peak demand, licences tied to hosts, security zone and GPU type.
2. Mark the reasons that force a separate cluster, and drop the ones resource pools or tags can handle.
3. Choose VVF or VCF per vCenter and, on VCF, the Simple or High Availability management model.
4. Size each cluster on its peak with one host down, and on vSAN to the policy minimum plus one host.
5. Check each cluster against the configuration maximums of your release and vSAN’s 64 hosts.
6. Compare the reserve hosts of the layout with one fewer cluster before you decide.

Our VMware optimisation service covers host and cluster consolidation, in agreed maintenance windows. Send us your clusters, hosts and workloads per cluster through the form below.

What we do

Eurokommerz holds the contract and supplies the hardware under the solution, with EU invoicing, delivery and warranty under European law; the work is done by our engineering partner Vixen.UNO. Under VMware optimisation, Vixen.UNO audits your VMware estate and licences, consolidates hosts and clusters and modernises vSphere, vSAN, NSX and VCF, cross-cluster migrations included. Changes run in agreed maintenance windows with a rollback plan at every stage, followed by support under an agreed SLA. The first call is free of charge, and the price of the technical assessment is fixed before work begins.

FAQ