TL;DR · Key Takeaways
- Capacity is never a single number. Read it as the time remaining on your most constrained resource, measured against usable capacity rather than raw.
- Two things decide the answer: whether you run the demand model, the allocation model, or both.
- HA admission control quietly reserves headroom. A cluster at 40 percent CPU and 55 percent memory still failed an HA restart because nothing was reserved.
- Read the capacity page against the model you actually chose, or you panic early or run out with no warning.
A cluster showed 40 percent CPU and 55 percent memory used. Comfortable, on paper. Then one host failed, HA tried to restart its VMs, and admission control refused because there was not enough reserved headroom. The dashboard said plenty of capacity. The cluster said otherwise. That gap, between what looks free and what is actually usable, is the whole subject of this part, written for the administrator who has to answer when do we buy more hosts and be right.
Reading time remaining correctly
VCF Operations expresses capacity as time remaining: how long until a resource is projected to run out, how much capacity is left, how many more VMs would fit, and how much is reclaimable. The trap is that time remaining is reported per resource and you only care about the worst one. A cluster with two years of CPU headroom and three weeks of memory headroom does not have two years. It has three weeks, because memory is the most constrained component. Always read the constrained resource, not the average.
The second correction is usable versus raw. Raw capacity is every core and every GB you bought. Usable capacity is what is left after you set aside what HA needs to restart workloads when a host dies. The headroom you can actually fill is smaller than the sticker number, and the difference is not rounding.
Demand model or allocation model?
VCF Operations can judge capacity two ways, and they can disagree sharply. The demand model looks at what workloads actually consume. The allocation model looks at what you promised them through overcommit ratios, the compute, memory and storage you allow per object type in policy. Here is the setting that surprises people: by default only the demand model is on. The allocation model is off until you enable it in the active policy.
| Model | What it measures | Default | Misses |
|---|---|---|---|
| Demand | Actual consumption and trend | On | Overcommit limits you set |
| Allocation | Promised resources via overcommit ratios | Off (enable in policy) | Whether workloads actually use it |
Why this matters in practice: a VDI or test estate is often allocation-bound long before it is demand-bound. People reserve far more than they use, so demand says months remain while you have already run out of room to place new VMs under your own overcommit rules. If you provision against promises, run the allocation model too. If you run lean and let workloads burst, demand alone is closer to reality.
One resource hides in both models more than the others: storage. CPU and memory pressure announce themselves with contention and ballooning, but datastore capacity creeps until it slams into a wall, and thin provisioning makes it worse because allocated never equals consumed until it suddenly does. When a cluster reports comfortable CPU and memory but short time remaining, check storage first; it is the constraint people forget to read because it does not page them the way a busy CPU does. The most constrained resource is frequently the one nobody was watching, and on a mature cluster that is usually disk.
Where capacity lives in the UI
The Capacity page is the single place that pulls this together. It shows time remaining, remaining capacity, how many more VMs would fit, and the reclaimable resources that could push those numbers back out. Cluster utilization is an interactive view: you can explore the demand percentage over time by CPU, memory or disk, or let it show you the most constrained component directly. That last option is the one to live in, because it answers the only question that matters without you averaging anything in your head.
The allocation model is a policy setting
Switching on the allocation model is not a global toggle you flip once and forget. It lives in policy, which means you can run it where it fits and leave it off where it does not. The allocation values, the overcommit ratios for compute, memory and storage, are defined per object type in the policy applied to those objects. Raise the CPU overcommit ratio and you are telling VCF Operations you intend to pack more virtual cores per physical core; the allocation-based capacity recomputes against that promise. This is flexible and easy to misuse: an overcommit ratio set for a lab should never be applied to a latency-sensitive production cluster. Scope the policy, set the ratios deliberately, and the allocation model becomes an honest mirror of how you actually provision rather than a number someone guessed.
Trend is the part people skip
Time remaining is a forecast, and a forecast is only as good as the trend behind it. A cluster that has been flat for a year and a cluster that grew 4 percent a month for the last quarter can show the same usage today and wildly different time remaining, because the projection reads the slope. This is why a sudden onboarding, a migration wave, or a new application changes your capacity picture overnight even though nothing about the hardware moved. Treat a steep change in time remaining as a signal to ask what changed in demand, not just as a number to escalate. The capacity page is telling you about the future, and the future is mostly made of the trend you are currently feeding it.
Is the warning real?
When time remaining drops, do not buy hardware on reflex. Walk a short chain first: which resource is constrained, whether reclaimable capacity would fix it, and whether the warning is demand or allocation driven. Reclaimable matters because VCF Operations also tells you how many VMs are idle or oversized and how much they would give back. Often the cheapest capacity is the capacity you already own and are wasting.
Worked example: usable capacity on an 8-host cluster
Take 8 identical hosts, each with 512 GB usable RAM, so 4,096 GB raw. HA admission control is set to tolerate one host failure, which reserves the equivalent of one host: 512 GB. That leaves 3,584 GB usable, not 4,096. Now suppose current memory usage is 2,600 GB. Against raw capacity you would say 1,496 GB free, roughly 36 percent. Against usable capacity the truth is 3,584 minus 2,600, or 984 GB, about 27 percent of usable, and it shrinks fast as you add VMs. If your average new VM commits 16 GB of memory, the honest answer to how many more fit is about 984 divided by 16, near 61 VMs, before you touch the HA reserve. Read it the raw way and you would have promised 93. The 32-VM difference is exactly the host you set aside to survive a failure.
Questions I actually get
Why does the capacity page say I have plenty when placement keeps failing?
Almost always a model mismatch. Only the demand model is on by default, so the dashboard reports actual usage while your placement is limited by allocation and overcommit. Enable the allocation model in the active policy and the two will line up.
What does time remaining actually measure?
It projects how long until a resource is forecast to run out, reported per resource. Read the most constrained one, because that is when you actually run out, regardless of how much headroom the others show.
Does VCF Operations account for HA when it reports capacity?
It can, and it should. Usable capacity is raw minus what HA admission control reserves to restart VMs after a host failure. If you read raw capacity you will overcount, sometimes by a whole host, and promise space that HA is holding in reserve.
How do I get capacity back without buying hardware?
Use the reclaimable view. VCF Operations identifies idle and oversized VMs and the resources they would return. Reclaiming those is usually faster and cheaper than a purchase, and it is the subject of the next part on rightsizing and reclamation.
Read capacity per cluster
One number that looks reassuring at the fleet level can hide a cluster that is about to wall off. Capacity is consumed where workloads actually run, and a VM cannot spill across cluster boundaries to borrow headroom sitting idle three racks away. So a fleet that is 50 percent used can still have a cluster at 92 percent memory with three weeks of runway. Fleet-level capacity is useful for procurement planning and budget conversations; cluster-level capacity is what pages you. Read both, and never let a healthy fleet average talk you out of acting on a single hot cluster.
This is also where reclaimable capacity and placement meet. If one cluster is constrained while a neighbor has room, the fix may not be hardware at all; it may be moving or rightsizing workloads so demand sits where the capacity is. VCF Operations can surface both the constrained cluster and the idle resources elsewhere, which turns a buy decision into a rebalance decision. The cheapest host is still the one you already own and are not using well.
Build one capacity view scoped per production cluster, sorted by time remaining on the most constrained resource, ascending. The cluster with the least runway sits at the top, every time you open it. That single sorted view replaces a monthly capacity meeting, because the thing you need to act on is always the first row. Pair it with the reclaimable total for each cluster so the next question, buy or reclaim, is answered on the same screen.
Where this leads
Capacity is a question with two hidden settings: the model and the HA reserve. Set both to match reality and time remaining becomes a number you can budget against. My verdict: report against usable capacity, run the model that matches how you provision, and reclaim before you buy. Next we turn the reclaimable list into action, with rightsizing and reclamation, the cheapest capacity you own.
One last habit worth forming: write down, per cluster, the lead time it takes you to actually get new hosts racked and into the cluster, from purchase order to production. That number is your real capacity alarm threshold. If hardware takes ten weeks to arrive, a time-remaining warning at eight weeks is already late. Set the alert to fire with your procurement lead time plus a safety margin, and capacity stops being a fire drill and becomes a calendar entry.
By the numbers: usable capacity on an 8-host cluster
Why the honest free number is smaller than the raw one.
| Measure | Value |
|---|---|
| Hosts in cluster | 8 |
| Usable RAM per host | 512 GB |
| Raw cluster RAM | 4,096 GB |
| HA reserve, one host | 512 GB |
| Usable RAM | 3,584 GB |
| Current usage | 2,600 GB |
| Free against raw | 1,496 GB (about 36 percent) |
| Free against usable | 984 GB (about 27 percent) |
| Average new VM commit | 16 GB |
| VMs that still fit | about 61 |
« Previous: Part 5 | VCF 9 Operations Complete Guide | Next: Part 7 »
References
- Using the Capacity Page to Assess and Optimize Capacity, VCF 9.0 (Broadcom TechDocs)
- Allocation and Demand Model in Workload Optimization, VCF 9.0 (Broadcom TechDocs)
- How Capacity Optimization Works in VCF Operations, VCF 9.0 (Broadcom TechDocs)
About The Author
DrJha