vSphere capacity planning: forecasting CPU, memory and storage for the next three years

How to plan vSphere capacity for the next three years

vSphere capacity planning for three years starts from demand, not allocation. Take the 95th percentile of the cluster totals for CPU and memory over 90 days of 5-minute samples and the used storage today, add the growth that the business plan and the project list imply year by year, and keep headroom for a host failure and for patch windows. Then line the result up with the subscription renewal and the hardware refresh, because the host count at each renewal date sets the number of licensed cores.

Allocation is what VMs were given in vCPUs, configured memory and provisioned disks, and demand is what they use. Reclaiming oversized allocations first, as our guide to waste in a vSphere estate describes, gives the plan a clean baseline. VCF Operations, formerly Aria Operations, calculates much of this up to one year ahead; years two and three need a model of your own.

Inputs for a vSphere capacity forecast

vSphere 8.0 documentation on performance chart roll-ups (16 September 2026); VCF Operations 9.1 documentation on capacity (8 October 2026); VVF programme document (June 2026).

The sample interval decides whether the peaks are still in the data. The vSphere 8.0 documentation states that hosts aggregate statistics every 5 minutes and that vCenter rolls them up into one data point every 30 minutes, then every two hours, then every day for the longer charts. A 90-day history read from those charts averages short peaks, such as a month-end batch run, into daily values, so keep 5-minute samples for the whole window, in VCF Operations or an external collector. Measure per cluster, since a spare host in one cluster does not help another.

Demand and allocation models in VCF Operations

VCF Operations sizes capacity with two models. The demand model is always used. Broadcom’s policy documentation says the allocation model “is used for capacity calculations only when you turn it on in the policy”, and its setting takes an overcommit ratio for CPU, memory or disk space. With both on, Broadcom’s KB 437777, written for VCF Operations 9.0 and Aria Operations 8.18, states that “The capacity engine will alert based on whichever model (Demand or Allocation) runs out of capacity first.”

The same KB traces critical CPU capacity alerts on clusters that look quiet in vCenter to historical spikes that the demand model includes and vCenter’s instantaneous metrics do not show, and advises against enabling the allocation model with arbitrary overcommit ratios to fix them.

Allocation still belongs in the plan as a second check, since a cluster with spare demand capacity can reach a vCPU-to-core ratio at which CPU ready per vCPU climbs. We found no Broadcom document that sets a general target for the ratio; our CPU ready guide explains how to verify it.

How VCF Operations forecasts time remaining and capacity remaining

Broadcom’s VCF 9.1 documentation, updated on 8 October 2026, says the capacity engine takes demand and usable capacity as input. Usable capacity is “the total capacity minus the resources that vSphere HA admission control reserves for failover”, and without HA it equals total capacity. A capacity buffer in the policy, zero by default, reduces usable capacity further, but Broadcom’s 9.0 policy documentation says it has been deprecated for cluster compute resources since version 8.6.

Broadcom TechDocs, VCF 9.1, How Does VCF Operations Calculate and Forecast Capacity (8 October 2026).

With the default warning threshold of 120 days, the recommended size covers the projected maximum 150 days ahead. The documentation adds that the actual sizing requirement is the recommended size plus your vSphere HA spare capacity.

The engine collects data points every five minutes and processes them once in 24 hours. It gives older data exponentially less weight, so a sustained peak that does not recur fades, while periodic peaks, such as a month-end batch run, do not decay and weigh most. Projections reach one year into the future and cover 90% of future data points between an upper and a lower bound. The conservative risk level plans on the upper bound, the aggressive level on the mean of the two.

The VCF 9.1 documentation allows up to six time periods to be excluded from the capacity calculations, an option Broadcom’s VCF blog of 6 August 2025 introduced for anomalous time ranges. Use it for a migration weekend or a stuck job that ran for days, and leave the month-end peaks in, since the plan has to carry them.

What-if analysis for new workloads and new hosts

What-if analysis in VCF Operations models a change before it happens. Workload planning adds or removes VMs, configured by vCPUs, memory, storage and expected use percentage or copied from existing VMs as templates. It reports whether the workload fits the chosen cluster and projects the time remaining. Infrastructure planning adds or removes servers of a type already in the cluster, a type approved for purchase or a custom configuration, and shows whether the time before CPU or memory runs out grows or shrinks.

Both default to a window from today to one year from today, the limit the documentation sets. Use what-if for projects dated in the next twelve months, such as a new application due to go live within the year, and carry each result into the three-year model as a step change. For expected use, take the measured use of comparable VMs rather than 100%.

A three-year forecast without VCF Operations

Without VCF Operations, or for years two and three, a spreadsheet per cluster is enough. The steps forecast the peak; turning a peak into a host count with N+1 and HA admission control is covered in our host consolidation guide.

1. Export 90 days of 5-minute cluster totals for CPU usage, consumed memory and used storage, with a quarter-end inside the window.
2. Take the 95th percentile and the maximum of CPU and memory and note when they occurred; for storage, take the used capacity at the end of the window, since it rises rather than peaks.
3. Derive organic growth per year from 12 to 24 months of quarter-end figures, such as VM count and consumed memory, and check it against the business plan.
4. List decommissions and projects by quarter, each project as VM profiles with vCPU, memory, storage and expected use.
5. Apply growth year by year, add and subtract the projects, and compare each year’s peak with the cluster’s capacity minus one host at the utilisation ceiling you accept.
6. Repeat with a high case: more growth and the projects one quarter earlier.

This example is illustrative, not a client case. One cluster of 20 hosts, each with two 32-core CPUs and 1,024 GB of memory, runs 1,100 VMs. Its 95th percentiles are 420 cores of CPU demand and 12,800 GB of consumed memory, and it uses 300 TiB of storage today. The business plan gives growth of 6% a year for CPU, 8% for memory and 15% for storage. In year 1, 60 legacy VMs retire with 600 GB and 15 cores. In year 2, an ERP upgrade adds 40 VMs with 160 vCPU at 30% expected use, 2,048 GB and 40 TiB. The ceiling is 80% with one host down.

Illustrative figures, our arithmetic: hosts = memory ÷ 0.8 ÷ 1,024 GB, rounded up, plus one host for a failure; CPU alone would need 10 to 12 hosts of 64 cores.

Memory sets the host count in every year: three hosts spare today, still enough in year 1, a 21st host when the ERP project lands in year 2 and 23 hosts in year 3. With 1,536 GB per host, the same plan needs 16 hosts in year 3. Memory carries no licence, so at two 32-core CPUs per host that choice is the difference between 1,472 and 1,024 licensed cores. Storage grows faster than both and can force a purchase in a year when compute still fits. A cluster that has to tolerate a host failure during a patch window needs one more host in every row.

Our VMware optimisation assessment reviews versions, subscriptions and actual resource usage and delivers an action plan ahead of renewal. Send us your cluster exports and the project list through the form below.

Storage growth in the capacity plan

Thin disks grow towards their provisioned size, snapshots until they are deleted, and log and staging volumes with retention settings rather than with users. Track provisioned capacity next to used capacity: a datastore that is 70% used but provisioned at 150% of its size has less room than the used figure suggests.

On vSAN, used capacity is the start of the calculation. Storage policy overhead and the operations and host rebuild reserves come on top, and the raw capacity counts against the vSAN entitlement, 0.25 TiB per licensed core with VVF. Our vSAN ESA sizing guide converts used capacity into raw capacity and a host count.

Matching the plan to the renewal and refresh calendar

Match the horizon to the subscription term. The VVF programme document of June 2026 licenses VVF per core with a minimum of 16 cores per processor and requires every core on the server to be licensed, including cores deactivated by the BIOS. A three-year term is bought as a number of cores and each added host needs more, so at signing the forecast has to show the host count, and with it the cores, for each year of the term. The counting rules and the tier choice are in our renewal guide to Standard, VVF and VCF.

Three dates matter for most plans. Broadcom’s VCF blog, in a post of 1 August 2025 addressed to SAP customers, says vSphere 8 “will be supported until October 2027, with an optional two-year Extended Support period available for purchase”. Confirm the day on Broadcom’s product lifecycle page, which requires a sign-in, as our guide to vSphere 8 end of general support explains. Broadcom’s post of 16 July 2025 gives the VCF 9.x code line an estimated end of service of 17 June 2031. It expects a minor release about every nine months, with 27 months of support for the early ones and 45 for the last.

The third date is the end of warranty and support for your hosts, which decides whether the extra host in year 2 joins the old cluster or starts a refreshed one. New hosts with more memory per core change which resource sets the host count, and with it the licensed cores. Plan refresh and renewal together, and rerun the forecast every quarter.

Our VMware optimisation service delivers an action plan ahead of renewal and end of support, with dates. Tell us your renewal date and the age of your hosts in 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, including versions, subscriptions and actual resource usage, matches editions to your actual workloads and delivers an action plan ahead of renewal and end of support, with dates. Modernisation is planned with the economics calculated over 3 to 5 years, and changes run in agreed maintenance windows with a rollback plan at every stage. Our infrastructure audit, priced and delivered independently of any purchase, covers compute and virtualisation, storage, networks and licences from the documentation and exports you provide, without access to your production systems. The first call is free of charge; the price of the technical assessment is fixed before work begins.

FAQ