VMware Capacity Planning After the Exit: Why the Old Forecast Overbuys

A vSAN cluster sized for 400 TB of usable capacity at FTT=1 mirroring has roughly 800 TB of raw flash sitting in it, and the capacity plan behind that number almost certainly held back another 25 to 30 percent as slack space before anyone was allowed to fill it. Take the 400 TB figure, carry it into an exit plan, hand it to a hardware vendor, and you will buy a machine that is substantially too big for the workload it is meant to hold.

This is the part of VMware® capacity planning that travels worst. Not the dashboards, which everyone expects to lose and replace. The arithmetic. The number that gets quoted in the exit business case is an output of a model whose inputs are about to change, and the model itself is rarely written down anywhere, because vCenter and Aria Operations were quietly holding all four of its terms.

Worth saying up front: plenty of people reading this are still running vSphere and will be for another year. The model below is usable now, on the current estate, and it is the same model you will need on the other side. You do not have to have left to get value out of re-deriving it.

What the vSphere capacity forecast was actually made of

The forecast everyone quotes is a single number, usually “usable TB,” sometimes paired with “months of headroom.” Both are outputs. Underneath them sit four inputs, and each one lived in a different place.

Raw capacity was the easy one: the sum of the devices claimed by the cluster, visible in vCenter, and the only term most people could recite.

The protection ratio came from the storage policy. At FTT=1 with RAID-1 mirroring, vSAN writes two copies, so the ratio is 2:1 and usable capacity is half of raw. Switch the policy to RAID-5 erasure coding and the same failure tolerance costs roughly 1.33:1 instead. This term was set per policy, not per cluster, which is exactly why it is so often remembered wrong: an estate with a mix of mirrored and erasure-coded policies has no single ratio, and the blended one was never displayed anywhere.

The slack space reserve was the term nobody owned. vSAN needs free capacity to resynchronise after a host failure, to rebalance, and to absorb the transient cost of policy changes, and the long-standing guidance was to keep roughly a quarter to a third of the cluster empty. In practice this got baked into a spreadsheet as a fudge factor years ago and was never revisited.

The growth curve is the one that actually made it a forecast rather than a snapshot. Aria Operations, and vRealize Operations before it, kept the time series: per-datastore consumption over months, the trend line through it, and the “time remaining” projection that fell out. That projection is the only part of this that required a product rather than a calculator, and it is the part most exit plans forget they are losing.

The useful way to hold all four together is as one expression:

Raw capacity required = committed workload data × protection ratio ÷ (1 − slack fraction)

Committed workload data is the only term in there that belongs to the business. The other three are properties of the platform, and all three are about to be replaced.

The three terms that change, and what each does to the number

Here is the part that has no owner by default. When the migration team asks “how much storage do we buy,” the honest answer is that three of the four inputs are now different, and two of them move the number down.

The protection ratio moves the most

This is the dominant term, and it is where a carried-over forecast goes wrong in the buyer’s favour. If the estate ran FTT=1 mirroring, the old ratio was 2:1. A Kubernetes-native storage layer that defaults to three-way replication is 3:1, which is worse, and this catches teams out badly: moving from vSAN mirroring to a replicated overlay is a 50 percent increase in raw flash for identical durability.

Erasure coding is what breaks that pattern. simplyblock uses erasure coding at roughly 1.25:1 for single-failure tolerance, against three-way replication’s 3:1 and vSAN mirroring’s 2:1. Applied to the same committed data, that is not a rounding difference. It is the difference between buying two devices and buying one.

There is an honest caveat to attach here rather than skip past. Erasure coding trades capacity efficiency for rebuild behaviour and for write path complexity, and a platform that does it badly is worse than one that replicates well. The right question to a vendor is not whether they erasure code, it is what the rebuild costs while it is running.

The forecast unit changes from datastore to pool

Under vSphere, the datastore was the object you forecast against. It had a name, a size, an alarm threshold and a row in a report, and capacity planning meant watching a list of those rows.

After the exit there is no datastore object. Capacity is a property of the pool, and growth is a property of individual PVCs. The two facts are not interchangeable. A pool that is 60 percent full tells you very little on its own, because the thing that will page someone at three in the morning is a single volume approaching its own limit while the pool sits half empty.

This is the term that changes the shape of the forecast rather than its value. One row becomes two questions: how full is the pool, and which volume is growing fastest relative to its request. Nothing in the destination platform asks those two questions for you on day one.

Overcommit has to be re-established against something new

Thin provisioning meant the sum of provisioned capacity legitimately exceeded raw capacity, and the overcommit ratio was a deliberate risk position taken at the datastore level.

That position does not carry over, because the thing it was taken against no longer exists. Kubernetes lets a PVC request capacity it never uses, and the storage layer can thin provision underneath it, so the overcommit exposure is now the gap between the sum of PVC requests and actual pool consumption. It is a real number and a legitimate risk position to take again, but it has to be re-taken explicitly, on the pool, with someone’s name against it. Inheriting the old ratio without re-deriving it is how a cluster that looked comfortable runs out of space.

The model, with your variables in it

Substitute your own numbers. The point is the ratio between the rows, not the illustrative figures.

Table 1: Re-deriving raw capacity from committed workload data.

Worked through, with W = 300 TB of committed data and a 28 percent reserve, the vSphere side needs 300 × 2.0 ÷ 0.72, which is roughly 833 TB raw. The same workload on erasure coding at 1.25:1 with a 15 percent operational reserve needs 300 × 1.25 ÷ 0.85, which is roughly 441 TB. Treat the 15 percent as an illustration and get the real figure from whoever is selling you the platform, because that term is the one most likely to be quietly different.

The direction of the error matters more than the exact figures. A forecast carried over unchanged overbuys, and it overbuys in a way that looks prudent in a business case, which is precisely why nobody catches it.

Re-deriving a capacity forecast for a platform you have not bought yet is awkward, because two of the three terms belong to the vendor. If you are sizing an exit and want the protection ratio, the operational reserve and the rebuild behaviour stated plainly before you commit to hardware, that is a short conversation. Talk to a storage architect

What rebuilding the forecast actually costs

The arithmetic above is the easy half. The harder half is that the growth curve, the one input that needed a product, does not reassemble itself.

After the exit the question “when do I run out, and what is slow” fragments across three places. Kubernetes exposes per-volume used and capacity bytes through kubelet’s volume stats, which is where per-PVC growth comes from. The CSI driver exposes its own view of provisioning and attachment. The storage layer exposes pool-level capacity, efficiency after erasure coding, and latency. Prometheus can scrape all three, and Grafana can draw them, but the correlation between them is not built, and neither is the trend projection that Aria Operations gave away for free.

Nobody tells the buyer this in advance, so it is worth naming as a line item rather than selling past it. Rebuilding the capacity-analytics plane is real integration work: deciding which of the three sources is authoritative for each question, setting alert thresholds against a pool rather than a datastore, and re-establishing a growth projection that used to be a product feature. Budget it as work, not as a checkbox. It is not enormous, and it is not free.

Two things make it cheaper than it sounds. The first is that the per-PVC half is genuinely better than what it replaces: a growth rate per volume, per namespace, per team, is a more actionable object than a datastore fill percentage ever was, and it maps onto chargeback in a way the old model did not. The second is that the pool-level half only has to be solved once, whereas the datastore list grew with the estate.

There is also a structural change worth putting in the business case explicitly. Under the old model, capacity growth eventually collided with licensing, so the capacity forecast was partly a software-cost forecast. Simplyblock is priced like the platform it runs on: by the CPU capacity of your worker nodes, counted the same way your Red Hat® OpenShift® or Kubernetes subscription counts them, and data volume does not change the price. The practical effect on this exercise is that the capacity forecast becomes a hardware question only. Growing the data does not move the software line, which removes one of the two variables the old spreadsheet was trying to balance.

What to require before signing anything: the protection ratio at your chosen failure tolerance, the operational reserve the platform actually needs, the rebuild cost while a device is being reconstructed, and a straight answer about which metrics the platform exposes for per-volume growth. Those four answers are the new forecast. Everything else is a dashboard, and dashboards are the part you were always going to replace.

Questions and Answers

How do I do VMware capacity planning if I am migrating off vSphere next year?

Re-derive the model rather than the number. Take committed workload data as the anchor, then apply the destination platform’s protection ratio and operational reserve instead of vSAN’s. For simplyblock, erasure coding at roughly 1.25:1 for single-failure tolerance replaces the 2:1 of FTT=1 mirroring, which typically means materially less raw flash for the same workload. Do this while still on vSphere, because the committed-data figure is easiest to measure on the estate you are still running.

Why does carrying over my existing usable-TB figure overbuy?

Because “usable TB” already has the old protection ratio and the old slack reserve baked into it. Quoting 400 TB usable implies roughly 800 TB raw at FTT=1 mirroring plus whatever reserve the spreadsheet held back. If the destination erasure codes, the raw requirement for the same committed data is substantially lower, so the carried-over figure sizes hardware for a protection scheme you are no longer using.

What replaces Aria Operations for storage capacity forecasting?

No single product, which is the honest answer. Per-volume growth comes from kubelet volume stats, pool capacity and efficiency come from the storage layer, and the CSI driver contributes its own view. Prometheus and Grafana can consolidate them, but the correlation and the trend projection are integration work you inherit. Treat it as a budgeted task during the migration rather than something discovered afterwards.

Is three-way replication a reasonable default for the destination?

It is durable, it is simple, and it is expensive: 3:1 raw to usable against vSAN mirroring’s 2:1, so it increases the hardware bill for identical failure tolerance. Erasure coding is the better economic answer when the platform implements it with a rebuild path you are willing to live with. Ask what the rebuild costs while it is running, not just what the steady-state ratio is.

Does growing my data change what simplyblock costs?

No. Simplyblock is priced by the CPU capacity of your worker nodes, counted the same way your OpenShift or Kubernetes subscription counts them, and data volume does not change the price. Everything is included, which means the capacity forecast after the exit is a question about hardware alone rather than a question about hardware and licences at the same time.