VCF Host Sizing Calculator

Short answer: for VCF host sizing, enter your workload profile (VMs, vCPU, RAM and storage per VM, or totals), the host you plan to buy (physical cores, RAM, raw vSAN capacity), the VCF management overhead and the vSAN policy. As a result, the calculator returns the minimum host count, the recommended N+1 and the resilient N+2 for the cluster, with the utilisation of every tier.

In addition, the calculator builds the management overhead from the real VCF 9.1 appliance list (vCenter, NSX Managers and Edges, SDDC Manager, VCF Operations nodes, collector, Management Services runtime, Identity Broker, License Server, VCF Automation nodes) or from a flat percentage.

Storage protection defaults to vSAN ESA Auto-RAID as VCF 9.1 / 9.1.1 configures it (RAID-5 2+1 up to five hosts, RAID-6 4+2 from six hosts). However, OSA, manual ESA policies and external storage remain available. Nothing leaves your browser.

Prefer a full window? Open the calculator full screen →

How the VCF host sizing is computed

  1. CPU. Workload vCPU with the growth reserve, divided by the vCPU-to-core overcommit (4:1 is typical for VCF production, 1:1 for databases, 8:1 for VDI). After that, the calculator adds the management vCPUs at their own ratio. Hosts are sized on physical cores minus a headroom. However, hyper-threading is not counted.
  2. Memory. Workload RAM with growth, divided by the memory overcommit (1:1 is VCF best practice). Then the calculator adds a per-VM overhead and the management RAM and compares the total with host RAM minus the ESX, vSAN and NSX system reserve and a headroom. In practice, memory is usually the first bottleneck.
  3. Storage. Usable TB times the protection factor (RAID-5 and RAID-6 cost 1.5×, RAID-1 2×, ESA 4+1 1.25×, OSA 3+1 1.33×), divided by the compression ratio and the slack. In addition, one host of raw capacity stays free when Host Rebuild Reserve is on. Because ESA Auto-RAID picks the layout from the host count, the storage host count is solved iteratively.
  4. Tiers. N is the largest of the CPU, memory, storage and policy minimums. N+1 covers one host failure or one host in maintenance. In contrast, N+2 keeps full protection when a host fails during maintenance. Finally, the findings tab adds the design-guide rules: start ESA clusters with four hosts, seven hosts for RAID-6 plus a spare, no Host Rebuild Reserve on four-host Auto-RAID clusters, admission control percentages, stretched-cluster notes.

Management overhead profiles

  • VCF 9.1 management domain, High Availability: three NSX Managers, two Edges, three VCF Operations nodes (master, replica, data), the collector, the Management Services runtime with three control plane and three large worker nodes, three Identity Broker nodes, the License Server, three VCF Automation nodes, SDDC Manager and vCenter. Roughly 240 vCPU and 900 GB of appliance memory.
  • Simple model (single NSX Manager, Operations and Automation node, one control plane node), the VCF 9.0 layout with the fleet management appliance, and two workload domain profiles (dedicated NSX with the domain vCenter and managers counted in, or shared NSX with only the Edges in the cluster). Every count and size is editable. Alternatively, you can use a flat 10 to 30 % overhead.
  • Appliance sizes follow the Broadcom documentation and the VCF 9.x courses. However, rows marked approx (Management Services nodes, License Server, Automation disk) are best-known figures to confirm in the Planning and Preparation Workbook.

Sources