// Guide · Pre-deployment & planning

VCF Host Sizing Calculator

Calculate exactly how many ESXi hosts you need for a VCF cluster. Models your workload (vCPU, memory, storage), VCF management overhead, vSAN FTT replication, CPU and memory overcommit, then returns three numbers: minimum, N+1, and N+2 host counts so you can pick the right HA posture.

CPU / RAM / StorageVCF overheadN+1 / N+2 HAvSAN FTTOvercommit ratiosWorkload presets

Open the tool Jump to walkthrough

Quick start

Pick a workload preset — Small VCF / Medium VCF / Large VCF / Database / VDI — or enter custom values.
Set your host spec — physical CPU cores, RAM, vSAN raw capacity per host.
Choose VCF overhead — 10% for labs, 15% (recommended), 20% conservative, 25% for large management plane.
Pick overcommit ratios — CPU (1:1 to 8:1) and memory (1:1 best practice).
Read the result — minimum / N+1 / N+2 host counts plus per-resource utilisation breakdown.

On this page

When to use this tool
How it works
Step-by-step walkthrough
Examples
Common mistakes
Related tools
FAQ

When to use this tool

Use this tool when you need to:

Decide how many hosts to buy for a new VCF deployment based on actual workload sizing.
Validate an existing design — does your proposed 6-host cluster actually fit the workload with HA?
Compare host SKUs — does it cost less to buy more smaller hosts or fewer big ones for the same workload?
Quote VCF deployments for clients with specific workload requirements.
Plan cluster expansion — how many hosts do I add to absorb 30% growth?

How it works

The math is straightforward but easy to get wrong by hand:

Workload demand: vCPU × cores ÷ overcommit, RAM, storage
Plus VCF overhead: management appliances eat 10-25% of capacity (vCenter, SDDC Manager, NSX Managers, Operations)
Plus vSAN replication overhead: FTT=1 doubles storage need, RAID-5 adds 1.33×, RAID-6 adds 1.5×
Divided by per-host capacity = minimum hosts
Plus HA buffer: N+1 = one host can fail, N+2 = two hosts can fail (recommended for production)

The tool runs all of this and returns three numbers so you can see the trade-off between cost and resilience.

Step-by-step walkthrough

1. Pick or define your workload

Use a preset to start fast:

Small VCF — typical entry deployment
Medium VCF — mid-sized enterprise
Large VCF — large enterprise / consolidated workload
Database — high-CPU/memory, latency-sensitive (uses 1:1 overcommit)
VDI — many small VMs, high vCPU density

Or enter custom:

VM count — how many VMs in total
vCPU per VM — average
RAM per VM (GB) — average
Storage per VM (GB) — average usable per VM

2. Set host specification

Per-host capacity:

Physical cores — sockets × cores per socket. Typical: 2 sockets × 32 cores = 64 cores.
RAM per host — GB. Typical: 512 GB or 1 TB for VCF.
vSAN capacity per host — TB raw. Typical: 15-30 TB on modern NVMe hosts.

3. Set VCF overhead

Management appliances run on the same cluster. Overhead percentage reservations:

10% — minimal / lab. Tight, but works for PoC.
15% — recommended for production. Covers vCenter + SDDC + NSX + room to grow.
20% — conservative. Choose if you're running VCF Operations, Automation, plus other management VMs.
25% — large management plane. Multi-WLD, full Operations stack, monitoring/backup VMs co-located.

4. Set overcommit ratios

CPU overcommit — vCPU per physical core ratio:

1:1 — no overcommit (DB, latency-sensitive). Most expensive.
2:1 — conservative
4:1 — VCF recommended general-purpose
6:1 — typical mixed workload
8:1 — dev/test only

Memory overcommit — VCF best practice is 1:1. Memory overcommit causes ballooning/swapping that destroys performance. Don't go above 1.25:1 unless you're in a tight lab.

5. Set vSAN policy

Pick the FTT (Failures To Tolerate) policy and RAID level. FTT=1 RAID-1 (mirror) doubles storage need; FTT=1 RAID-5 (4+1) adds 1.33×; FTT=2 RAID-6 (4+2) adds 1.5×. Most production deployments use FTT=1 RAID-1 or RAID-5.

6. Read the result

The tool shows three host counts:

Minimum — fits the workload exactly. No HA buffer. Don't actually deploy this.
N+1 recommended — one host can fail without impact. Production minimum.
N+2 robust — two hosts can fail. Use for critical workloads or large clusters.

Plus the per-resource breakdown — does CPU bind first, or memory, or storage? Tells you whether to buy bigger CPU hosts or memory-heavy hosts.

Examples

Example · Mid-size VCF cluster

200 VMs, 4 vCPU avg, 16 GB RAM avg, 200 GB storage avg. Hosts: 64 cores, 512 GB, 20 TB. Overhead 15%, CPU 4:1, Mem 1:1, FTT=1 RAID-1.

Demand: 800 vCPU ÷ 4 = 200 cores; 3.2 TB RAM × 1.15 overhead = 3.7 TB; 80 TB ÷ FTT (×2) = 160 TB raw
Minimum: 8 hosts (memory-bound)
N+1: 9 hosts
N+2: 10 hosts

Example · Database cluster (no overcommit)

20 SQL VMs, 16 vCPU avg, 128 GB RAM, 1 TB storage. Hosts: 64 cores, 1 TB, 30 TB. Overhead 15%, CPU 1:1, Mem 1:1, FTT=1 RAID-1.

Demand: 320 vCPU ÷ 1 = 320 cores; 2.5 TB RAM; 40 TB raw needed
Minimum: 6 hosts (CPU-bound)
N+1: 7 hosts
N+2: 8 hosts

Common mistakes

🚨

Memory overcommit > 1:1 in production Memory overcommit causes ballooning, then swapping, then crippled VMs. VCF best practice is strict 1:1. The tool defaults this correctly — only override if you genuinely understand the consequences.

⚠

Forgetting vSAN replication overhead A 100 GB VM with FTT=1 RAID-1 actually uses 200 GB on disk. The tool handles this automatically — but if you're sizing manually elsewhere, don't forget the multiplier.

⚠

Sizing for "just the workload" VCF management appliances (vCenter, SDDC Manager, NSX Managers ×3, Operations) eat real capacity. Always include overhead. The default 15% is a reasonable floor.

🚨

N+0 in production Minimum host count means a single host failure causes capacity exhaustion. Even labs should run N+1. Production should run N+2 if the workload value justifies it.

⚠

CPU overcommit on stretched cluster Stretched clusters across two sites mean half your hosts run normal load. If you overcommit 4:1 on the active half, a site failure forces 8:1 on the survivor — usually unacceptable. Size with effective overcommit doubling in mind.

Tools that pair well with VCF Host Sizing Calculator:

FAQ

Does the tool account for vSphere HA admission control?

Indirectly — N+1 and N+2 results give you the host counts that satisfy basic admission control. You still need to enable and configure HA admission control in vCenter.

Why does the tool sometimes show storage as the binding resource?

When workload storage demand exceeds CPU and memory needs (typical for archival or backup workloads). In that case, adding more disk per host is cheaper than adding hosts.

Can I size a stretched cluster with this?

Use the tool to size for the active site, then double the host count for stretched (since each site needs full capacity). Stretched cluster math gets complex; use this as a starting point.

What about hot-add CPU/memory?

The calculator uses configured (not active) vCPU and RAM. Hot-add affects how you allocate resources later, not the cluster capacity needed.

Does it handle different host SKUs in the same cluster?

Not directly — assumes homogeneous hosts (best practice for vSAN clusters). For mixed clusters, run the calculator twice with the smaller SKU and use that count.