VMware host consolidation: how many hosts a vSphere cluster needs under per-core licensing

How host consolidation lowers the licensed core count

VMware host consolidation lowers the number of licensed cores, because VVF and VCF are licensed on every physical core of every server where the software is installed, with a minimum of 16 cores per processor. Six hosts with two 16-core CPUs need 192 core licences, four need 128. How far a cluster can shrink depends on its measured peak with one host down, on HA admission control and maintenance headroom and, with vSAN, on the number of hosts the storage policy needs.

The counting rules are in our guide to VMware licensing after Broadcom, and counting an existing estate in our core count guide. Whether a lower core count justifies extra memory, devices or servers is a calculation on your own numbers.

What limits consolidation, constraint by constraint

Broadcom TechDocs (vSphere 8.0, vSAN 8.0, VCF 9.1), vSphere API reference 9.0, KB 438023 and 326889, VVF and VCF programme documents (June 2026).

HA admission control and N+1 in a smaller cluster

vSphere HA admission control holds back capacity for restarting the VMs of a failed host. You set Host failures cluster tolerates and define the reserve by cluster resource percentage, slot policy or dedicated failover hosts, or disable it. For the percentage policy, Broadcom’s API reference for 8.0 and 9.0 says the default calculation uses “the failoverLevel hosts’ resources”. With identical hosts and one tolerated failure, that is 25% of a four-host cluster and about 17% of a six-host one.

HA checks that reserve against reservations, not usage. Per Broadcom’s page on the percentage policy, it sums the CPU reservations of powered-on VMs, 32 MHz for a VM without one, and their memory reservations plus overhead, on hosts that are connected, not in maintenance mode and without HA errors. Where a VM uses more memory than it reserves, the admission control page adds, “insufficient failover capacity is available, resulting in performance degradation on failover”. A cluster with few reservations can pass admission control on four hosts while three could not carry its peak.

Usage is compared with the capacity by Performance degradation VMs tolerate, a setting that needs DRS. At its default of 100% it “produces no warnings”; at 0%, “a warning is generated when cluster usage exceeds the available capacity”. A dedicated failover host takes no VMs until a failure, yet all of its cores are licensed.

Maintenance mode headroom and DRS

A host in maintenance mode takes its capacity out of the cluster as a failed host does. Broadcom’s resource management documentation states that “DRS does not recommend (or perform, in fully automated mode) any virtual machine migrations off of a host entering maintenance or standby mode if the vSphere HA failover level would be violated after the host enters the requested mode.” The host then stays in Entering Maintenance Mode, which in a small cluster with large reservations can stall a patch window.

Sized for N+1, a cluster patches without a spare, so patch windows belong outside month-end peaks. Sized for N+2, it keeps one, which on four hosts holds back half the cluster.

On vSAN, Ensure accessibility, the default evacuation mode, moves only the data needed to keep every object accessible, and Broadcom warns that it “does not reprotect your data during failure and you might experience unexpected data loss”. Full data migration keeps the data compliant but needs a host to move it to.

vSAN host minimums, rebuild reserve and included TiB

A standard vSAN cluster needs at least three hosts that contribute capacity (VCF 9.1 documentation), and the storage policy raises that floor. With mirroring, FTT=n needs 2n+1 fault domains, so FTT=2 needs five; RAID-5 needs four on OSA and three, as 2+1, on ESA, and RAID-6 needs six. A three-host cluster cannot reprotect data after a failure or use Full data migration, and Broadcom advises “a cluster with four or more hosts for maximum availability”. Full data migration needs one host more than the layout itself. KB 326857, whose cause refers to OSA disk groups, names a fourth host for RAID-1, a fifth for RAID-5 and a seventh for RAID-6. For ESA, KB 405876 counts that spare host in the choice of RAID-5 scheme, 2+1 on four hosts and 4+1 from six. Our vSAN ESA vs OSA comparison covers the layouts.

KB 326889 sets the host rebuild reserve by “the capacity of one host relative to the total host count in the cluster”, a sixth of capacity on six hosts and a quarter on four, next to an operations reserve for policy changes and rebalancing. Both are off by default and, per the vSAN 8.0 documentation, unsupported with fault domains, on stretched or ROBO clusters and below four hosts; size for both either way. The included capacity follows the licensed cores, 0.25 TiB per VVF core and 1 TiB per VCF core, against all raw capacity vSAN claims.

Measuring demand: 90-day peaks, not averages

Size on the peak of the cluster total, not on averages or the sum of each VM’s own peak, since VMs do not all peak at once. Ninety days of 5-minute samples, placed to include a quarter-end, cover its month-end runs and backup windows. vCenter keeps 5-minute samples for only one day by default, so the samples come from VCF Operations or an external collector, as our guide to waste in a vSphere estate explains.

1. Export 90 days of 5-minute samples per cluster: CPU usage in MHz, consumed memory, balloon and swap used, ready time per vCPU and, on vSAN, raw capacity used.
2. Take the 95th percentile and the maximum of the cluster totals, with the time of each.
3. Convert CPU to cores by dividing MHz by the clock of one core; vCenter counts cluster capacity as cores multiplied by processor frequency and cluster usage as the sum of the VMs, without ESXi’s and vSAN’s own load.
4. Divide the 95th percentile by the utilisation ceiling you accept with one host down and by one host’s capacity, round up, add one host, and check that the maximum fits with one host down.

KB 438023 reads non-zero ballooning as host memory pressure and host swapping as contention usually “severe enough to impact VM performance”. For ready time it cites industry-accepted thresholds: below about 5% per vCPU is benign, above 10% a noticeable impact. Consolidating 192 cores into 128 raises the vCPU-to-core ratio by half; our CPU ready guide explains the counters behind it.

Our infrastructure audit maps clusters and their actual resource usage from the exports you provide. Tell us which clusters you would like to shrink and which monitoring data you keep.

CPU choice for new hosts under the 16-core minimum

A processor with fewer than 16 cores is licensed as 16, so new hosts should have at least 16 cores per socket. Above that floor the licence follows total cores, and the host count decides how much of them sits in reserve. Every layout below leaves 96 cores after one host failure.

Our arithmetic: at least 16 cores per processor (VVF and VCF programme documents, June 2026) and an HA reserve of one host.

Fewer, larger hosts hold a larger share in reserve, so the smallest cluster does not have the fewest licensed cores, while each extra host is another server to run. Smaller sockets also mean smaller NUMA nodes, and ESXi keeps a VM’s vCPUs and memory within one node when the VM fits (KB 438023), so the widest VM sets a floor for cores per socket. A retired host kept as a spare with the hypervisor installed still counts for licensing.

Worked example: six hosts to four

This example is illustrative, not a client case. Six hosts, each with two 16-core CPUs and 512 GB of memory, run VVF on 192 licensed cores. vSAN ESA stores 30 TiB of VM data with a RAID-6 policy at FTT=2. Over 90 days, the 95th percentile of the cluster totals was 55 cores of CPU usage and 1,700 GB of consumed memory.

Illustrative figures; our arithmetic with 0.25 TiB per VVF core (VVF programme document, June 2026) and RAID-6 and RAID-5 2+1 at 1.5 times the data (vSAN 8.0 documentation).

By step 4 with an 80% ceiling, CPU needs four hosts, while memory needs all six hosts with 512 GB and four with 768 GB, so memory, which adds no licensed core, sets the host count.

On vSAN, FTT=2 cannot stay on four hosts, so the data owner has to accept FTT=1, which on four ESA hosts can be RAID-5 2+1 at the same 1.5 times the data. Without new devices, used capacity and the 16 TiB rebuild reserve would take 61 of 64 TiB before the operations reserve. Each remaining host therefore goes to 24 TiB. On VVF the add-on for the same 96 TiB grows by 16 TiB as the included capacity falls with the cores; on VCF the 128 TiB included still cover it. From step 1 to step 4 below, vSAN claims 128 TiB of raw capacity, and the vSAN programme document requires all of it to be licensed.

1. Add memory and storage devices to the four hosts that stay, one host at a time in maintenance windows.
2. Change the storage policy to FTT=1 while all six hosts are in the cluster; vSAN creates the new components before it deletes the old ones (KB 326857), so check free space first.
3. Put the two hosts into maintenance mode one at a time with Full data migration. On ESA, move the second only when the Resyncing Objects view shows the RAID-5 objects converted from 4+1 to 2+1, which KB 405876 starts 24 hours after the number of hosts with available storage pools falls and which can run for several hours.
4. Watch the next month-end on four hosts, then remove the two hosts from the cluster and the software from the servers.

Until then, the two hosts can leave maintenance mode again if the month-end shows a shortfall. The result is 128 licensed cores in place of 192, more memory per host, the same raw capacity and vSAN data tolerating one failure in place of two.

Our VMware optimisation service covers host and cluster consolidation, with changes in agreed maintenance windows and a rollback plan at every stage. Send us your host list and 90 days of cluster data through the form below.

What we do

Eurokommerz holds the contract and supplies hardware and licences, with engineering by our partner Vixen.UNO. Under VMware optimisation, the Vixen.UNO team audits the estate and its licences, matches editions and subscriptions to your actual workloads and consolidates hosts and clusters. We do not promise to bring the old prices back: you see the number after the audit, before you sign the renewal, and if there is nothing to optimise, we say so. Our infrastructure audit is a separate fixed-price product. The first call is free of charge; the price of the technical assessment is fixed before work begins.

FAQ