Start here

How to read the workbook

Before opening any tab, anchor the customer on five ideas. Almost every confusing question traces back to one of these.

#

Greenfield sizing vs. brownfield converge

Concept
What it isThe workbook can size brand-new hardware (greenfield) or measure what additional appliances will consume on existing hardware (converge).
Why it’s in the workbookThe same sheet serves both, so half the inputs may not apply to a given engagement.
What to enterFor a converge, you populate component selections and read the total resource output; you can largely ignore the per-host greenfield inputs.
Say it like this“We’re not buying hosts today — we’re checking whether one of your existing clusters can absorb these management appliances. So we’ll skip the host-parameter inputs and focus on the totals.”
#

Fleet vs. Instance vs. Domain

Concept
What it isA fleet is the whole VCF estate managed centrally. An instance is one VCF deployment within it. A domain is a vCenter + NSX boundary inside an instance — either management or workload.
Why it’s in the workbookThe workbook asks you to declare the instance (First vs Additional) and then enumerate domains; fleet-level services only deploy on the first instance.
Say it like this“Fleet = the estate, instance = this deployment, domain = a vCenter boundary. Fleet services live on your first instance only.”
#

Management domain vs. Workload domain

Concept
What it isThe management domain runs the control plane (SDDC Manager, VCF Operations, Automation, plus the vCenters and NSX Managers of every domain). Workload domains run business workloads.
Why it’s in the workbookCustomers assume each appliance lives “with” its workload — it doesn’t. A workload domain’s vCenter and NSX controllers actually run in the management domain.
Watch-outA management domain is still a management domain whether it has dedicated hardware or runs workloads alongside it. The old “consolidated / standard architecture” wording from 5.x is retired in VCF 9 — don’t promise a “consolidated domain” by name.
Say it like this“Even your workload domain’s vCenter and NSX controllers run up in the management domain. That’s why adding a workload domain still adds load to management.”
#

VCF Management Services (new in 9.1)

New 9.1
What it isA unified, containerized runtime that hosts lifecycle and operational services — fleet lifecycle, SDDC lifecycle, identity broker, log management, real-time metrics, Salt, software depot, telemetry — on a VCF services runtime.
Why it’s in the workbookIt replaces the old Aria Suite Lifecycle / separate-manager sprawl and is why the sizing sheet has “control nodes” and “worker nodes” lines.
Sizing / resource impactAdding components (Automation, Operations for Networks) can auto-resize the runtime by adding worker nodes.
Say it like this“In 9.1 the management plane is one containerized runtime. When we switch components on, the runtime scales its worker nodes automatically.”
#

The high-watermark technique

Method
What it isInclude everything first to see the maximum resource ceiling, screenshot it, then back components out to find the true minimum.
Why it’s in the workbookIt answers both questions a customer has: “what’s the most this could ever need?” and “what’s the least to get started?”
Say it like this“Let’s build the worst-case version first so we know the ceiling, then trim to a bare-minimum version. You’ll end up with two saved scenarios.”
Start here

Mandatory vs optional — at a glance

What you must deploy to converge, versus optional, paid, or design-specific components.

Mandatory — always deploys
SDDC ManagerVCF OperationsCloud ProxyVCF services runtimeNSX ManagervCenter (per domain)
Optional — add Day-N
Log managementReal-time metricsOperations for NetworksIdentity Broker / Software DepotVCF Automation
Paid add-ons
vDefend / SSPAvi Load BalancervDefend & Avi License Hub
Conditional — only if designed
NSX Federation / Global ManagerSite Protection & DRCyber RecoveryRansomware RecoveryCross Cloud Mobility (HCX)Private AI Ready InfravSAN stretched cluster
ComponentClassificationDeploys whenAdd later?
SDDC ManagerMandatoryBring-upNo
VCF Operations (+ Cloud Proxy)MandatoryBring-upNo
VCF services runtimeMandatoryBring-upAuto-scales
NSX ManagerMandatoryBring-upNo — NSX is required in 9.x
vCenter (per domain)MandatoryPer domainNo
Log managementOptionalDay-NYes
Real-time metricsOptionalDay-NYes
VCF Operations for NetworksOptionalDay-NYes
VCF AutomationOptionalDay-NYes — needs Operations first
Identity Broker / Software Depot (extra)OptionalDay-NYes
vDefend / SSPPaidIf licensedYes
Avi Load BalancerPaidIf licensedYes
NSX Federation / Global ManagerConditionalMulti-site onlyYes — needs dedicated NSX
Site Protection & DRConditionalIf DR designedYes
Cyber / Ransomware RecoveryConditionalIf protection designedYes
Cross Cloud Mobility (HCX)ConditionalIf migrating to cloudYes
Private AI Ready InfraConditionalIf AI workloadsYes
Start here

Visual models

Three pictures that settle the questions customers ask most. Point at them while you talk.

1 · A workload domain’s control plane runs in the management domain
MANAGEMENT DOMAIN control plane for the whole instance SDDC Manager VCF Operations VCF Automation Services runtime WLD-A vCenterruns here WLD-A NSXruns here WLD-B vCenterruns here WLD-B NSXruns here WORKLOAD DOMAIN Aruns your business VMs WORKLOAD DOMAIN Bruns your business VMs control plane ↑ lives in management
2 · NSX Federation — active / standby Global Manager
SITE A · primary NSX Local Mgr Global MgrACTIVE SITE B · recovery NSX Local Mgr Global MgrSTANDBY policy sync · RTEP Federation needs dedicated NSX — not the shared model.
3 · From bare-minimum to high-watermark
MANDATORY CORE SDDC Mgr · Operations (+proxy) · services runtime · NSX Manager + COMMON DAY-N Log management · Operations for Networks · Real-time metrics + PAID ADD-ONS VCF Automation (24/96) · vDefend SSP · Avi — the high-watermark ~2 hosts   ~40 VMs
Workbook tab 1 of 27

Prerequisite Checklist

The gate before bring-up. It’s split into management-domain hardware, workload-domain hardware, network, storage, and stretched-cluster requirements. Treat it as the “did we satisfy the entry conditions” list.

#

Server Type / CPU / Memory (Management Domain)

Required
What it isMinimum supported server, CPU and memory configuration for the hosts that will run the management domain.
Why it’s in the workbookBring-up validation will fail if hosts aren’t on the Broadcom Compatibility Guide or are under-spec.
What to enterConfirm models against the Compatibility Guide; capture per-host cores and RAM.
Watch-out“Supported configuration” is not a number you invent — it must match the Compatibility Guide for that exact server + storage combo.
Say it like this“Two things have to be true before we deploy: the hardware is on the Compatibility Guide, and it clears the minimum CPU/RAM. Let’s verify both now.”
#

Storage — vSAN-ESA / vSAN-OSA / NFS / FC

Required
What it isPrimary storage choice for the domain. ESA is the modern vSAN architecture; OSA is legacy; NFS and FC are external options.
Why it’s in the workbookStorage type drives the minimum host count and the capacity math in the sizing sheet.
Sizing / resource impactvSAN-ESA pushes the management-domain minimum to 4 hosts; FC/NFS can go as low as 2 hosts.
Watch-outBoot from SD-card is legacy and not recommended; plan boot device accordingly.
Say it like this“Your storage choice sets your floor on host count — vSAN-ESA wants four, FC or NFS can do two.”
#

NICs per server

Required
What it isPhysical NIC requirement — at minimum one 10GbE data NIC plus a 1GbE BMC/management NIC; 25GbE recommended.
Why it’s in the workbookVCF networking (vSAN, vMotion, overlay, management) is bandwidth-sensitive.
Watch-outSingle-NIC is only supported via the API-driven path, not the standard wizard.
Say it like this“Single-NIC works but only through the API flow — for the wizard path we want redundant uplinks.”
#

Physical Network — Jumbo frames, BGP, Teaming, ECMP

Required
What it isThe fabric prerequisites: MTU 9000 for vSAN/vMotion/overlay, BGP AS numbers for dynamic routing, vDS teaming, and ECMP for multi-path.
Why it’s in the workbookNSX overlay and edge routing depend on these being in place before deployment.
What to enterCapture VLAN IDs, MTU, BGP AS numbers, and Top-of-Rack neighbor details (these reappear in the As-Built sheets).
Say it like this“The network team needs jumbo frames end-to-end and a BGP AS plan ready — if that’s not in place, NSX bring-up stalls.”
#

Stretched Network Requirements (multi-AZ)

Optional
What it isExtra routing/latency requirements when the domain stretches across availability zones.
Why it’s in the workbookStretched clusters add a witness and inter-AZ routing constraints.
Say it like this“Only relevant if you’re stretching a cluster across two AZs — then we need routing between the ESX management networks and a witness.”
Workbook tab 2 of 27

VCF & VVF Planning

A short tab that sets the deployment’s identity: product, version, instance role, and the operation being performed. It seeds defaults the rest of the workbook reads.

#

Deployment Version

Required
What it isThe target VCF build (e.g. 9.1.0.0).
Why it’s in the workbookDrives interoperability and which components/sizes are valid.
Say it like this“We lock the target version here because it governs the upgrade/interop matrix for everything else.”
#

Deployment Specification — VCF vs VVF

Required
What it isWhether you’re deploying full VMware Cloud Foundation or the lighter vSphere Foundation (vSphere + VCF Operations only).
Why it’s in the workbookVVF is essentially vSphere + Operations; it omits SDDC Manager-driven domain automation and NSX-centric pieces.
Say it like this“VCF is the full private cloud; VVF is vSphere plus Operations. Picking VVF removes a lot of the appliances we’d otherwise size.”
#

Instance to operate on — First vs Additional

Required
What it isWhether this is the first instance of a new fleet or an additional instance joining one.
Why it’s in the workbookFleet-level services deploy only on the first instance. Additional instances are lighter.
Sizing / resource impactFirst instance carries fleet lifecycle, identity broker, software depot, Salt RaaS, etc.
Say it like this“First instance carries the fleet-wide brains. Additional instances only run their local services.”
#

Operation — Deploy new / Add instance / Add cluster

Required
What it isThe action being planned, which tailors which downstream tabs you fill.
Why it’s in the workbookSame workbook, different journeys: greenfield bring-up, expanding a fleet, or just adding a cluster.
Say it like this“This dropdown reshapes the workbook to the journey we’re on — new build, new instance, or new cluster.”
Workbook tab 3 of 27

Management Domain Sizing

The engine room — assumptions and the instance profile, every appliance toggle, the per-domain rows, and the host-requirement output. The longest tab; take it top to bottom.

1 · A workload domain’s control plane runs in the management domain
MANAGEMENT DOMAIN control plane for the whole instance SDDC Manager VCF Operations VCF Automation Services runtime WLD-A vCenterruns here WLD-A NSXruns here WLD-B vCenterruns here WLD-B NSXruns here WORKLOAD DOMAIN Aruns your business VMs WORKLOAD DOMAIN Bruns your business VMs control plane ↑ lives in management
#

Host and Operations Reserve (%)

Greenfield
What it isHeadroom held back on each host for HA, vSphere overhead and operations (default 30%).
Why it’s in the workbookUsed to translate raw VM demand into a realistic host count.
What to enterLeave at default unless the customer has a standard. For converge it mainly affects the host-count read-out.
Say it like this“30% is the safety margin so we’re not sizing hosts to 100% — it covers HA and maintenance.”
#

Storage Estimated Growth (%)

Greenfield
What it isGrowth buffer added to storage demand (default 10%).
Why it’s in the workbookKeeps capacity sizing from being exactly break-even on day one.
Say it like this“A 10% storage cushion so we don’t design to the edge.”
#

Host Parameters — Cores, RAM, Oversubscription

Greenfield
What it isPer-host cores, RAM and CPU/memory oversubscription ratios (default 1:1).
Why it’s in the workbookGreenfield only — these describe the new hosts you’d buy.
Watch-outFor a brownfield converge these are informational; you’re validating existing capacity, not specifying new hosts.
Say it like this“These describe hardware you’d purchase — for your converge we can leave them; we’re reading the demand side.”
#

Instance Model — First Instance

Required
What it isMarks this as the first instance, so fleet-level services are included in the totals.
Why it’s in the workbookDetermines whether the heavy fleet components appear.
Say it like this“Because this is your first instance, the totals include the fleet-wide services.”
#

Availability Model — High Availability vs Simple

Required
What it isHigh Availability deploys 3-node clusters for the applicable appliances; Simple deploys single nodes (lab/PoC).
Why it’s in the workbookThis roughly triples node counts for NSX, Operations and the services runtime.
Sizing / resource impactHA is the production answer and the main reason the VM count climbs toward 30–40.
Say it like this“HA means three of each clustered appliance instead of one — that’s most of the VM growth you’re seeing.”
#

Size — Small / Medium / Large

Required
What it isThe t-shirt size driving per-appliance vCPU/RAM/disk.
Why it’s in the workbookBigger size = more capacity and more resource draw.
What to enterStart at the smallest that meets the object/log counts; you can scale up later.
Say it like this“Start small where we can — these scale up non-disruptively when you grow.”
#

VCF services runtime (control + worker nodes)

Required
What it isThe containerized management plane: typically 3 light control nodes and 3 heavy worker nodes.
Why it’s in the workbookHosts the fleet/SDDC lifecycle and other 9.1 services.
Sizing / resource impactWorker nodes are a large share of the total (each is sizeable); adding components can add workers.
Say it like this“This is the new 9.1 plane — control nodes are light, worker nodes carry the load and grow as we add services.”
#

Log Management + Replicas

Day-N
What it isIntelligent logging for Operations. Sized by ingest volume (S/M/L); replicas add resilience.
Why it’s in the workbookNot required at bring-up — it’s a Day-N add on the first instance.
Sizing / resource impactOften pre-included in the offering regardless of this toggle; ingest scales with node size/count.
Watch-outThere’s no “Include” switch — only S/M/L — because the only variable is how much you ingest, not whether it exists.
Say it like this“Logging isn’t needed to converge — add it Day-N. Start Small and scale as ingest grows.”
#

VCF Operations for Networks (+ collector)

Day-N
What it isNetwork analytics for Operations; deploys a platform node plus a collector.
Why it’s in the workbookOptional visibility layer; adds VMs.
What to enterPlan at least Medium for anything past a lab.
Say it like this“This is your network analytics — great to have, but it’s extra appliances, so include only if they’ll use it.”
#

Real-time Metrics

New 9.1
What it isStreams high-frequency performance data — ~5-second intervals vs the usual 5/10/15-minute collection.
Why it’s in the workbookNew in 9.1, Day-N, on every instance.
Sizing / resource impactAdds appliance footprint for the higher fidelity.
Say it like this“New in 9.1 — five-second metrics instead of minutes. Worth it if they care about fine-grained performance; otherwise skip to save resources.”
#

Software Depot / Identity Broker (additional instance)

Optional
What it isInstance-local copies of the software depot or identity broker (both default to fleet-level on the first instance).
Why it’s in the workbookOnly needed when a site wants its own local depot or a second broker.
Say it like this“These already exist fleet-wide — only add instance-local copies if a remote site needs its own.”
#

VCF Operations

Required
What it isThe operations, licensing and lifecycle hub — effectively mandatory for the platform.
Why it’s in the workbookAutomation’s lifecycle is managed through Operations, and licensing flows through it.
Say it like this“Operations is the hub — licensing and even Automation’s lifecycle run through it, so it’s effectively mandatory.”
#

VCF Automation

Optional
What it isInfrastructure provisioning and workflow automation.
Why it’s in the workbookOptional and easily added later, but it’s the single heaviest appliance.
Sizing / resource impact~24 vCPU / 96 GB — the most impactful single toggle on the sheet.
Watch-outRequires VCF Operations first (lifecycle dependency).
Say it like this“Automation is powerful but it’s 24 vCPU / 96 GB — the biggest line item. Include it for the high-watermark, decide later if you’ll run it.”
#

Cloud Proxy

Required
What it isThe collector that ingests data from other sites/clusters back into Operations (the old “connector” appliance).
Why it’s in the workbookIt’s how remote data reaches Operations.
Say it like this“Think of cloud proxies as connectors — they pull telemetry from your other sites back into Operations.”
#

License Hub for vDefend and Avi

Paid
What it isThe licensing service required when vDefend (security) and Avi (load balancing) are in play.
Why it’s in the workbookThose paid add-ons need the hub deployed to be licensed.
Say it like this“If you’re using vDefend and Avi, we keep this in — it’s the licensing service for them.”
#

vCenter size + disk (per domain)

Required
What it isThe vCenter appliance size for that domain (e.g. Medium ≈ 8 vCPU / 30 GB) and its storage tier.
Why it’s in the workbookEvery domain has its own vCenter — and it runs in the management domain.
Watch-outA Medium vCenter supports a limited number of connected vCenters/objects; size up if the domain count is high. 9.1 adds a one-call resize API.
Say it like this“Each domain’s vCenter is sized here — remember it physically runs in management, not out in the workload cluster.”
#

NSX Model — Shared / Dedicated / HA Cluster

Required
What it isThe NSX Local Manager topology for the domain. Shared reuses management’s NSX; Dedicated stands up its own; HA Cluster = 3-node.
Why it’s in the workbookLowest footprint is shared; isolation or federation needs dedicated.
Sizing / resource impactShared NSX shows 0 net-new resources (you reuse existing) — pull the running NSX’s real usage separately.
Watch-out9.1 change: the first workload domain no longer needs a dedicated NSX — it can join management’s NSX. But shared NSX cannot run Federation.
Say it like this“Shared NSX is cheapest and now allowed for your first workload domain — but the moment you want Federation, that domain needs its own NSX.”
#

NSX Local Manager (LM) sizing

Required
What it isThe per-domain NSX manager appliance size (HA = 3 nodes, ~6 vCPU / 24 GB each).
Why it’s in the workbookDrives a big chunk of the management-domain VM count.
Say it like this“An HA NSX manager is three nodes — that’s three of the VMs in your total.”
#

Federation — Active-Active / Active-Standby / Connected

Optional
What it isEnables a multi-site NSX Global Manager. Active-Active = both author policy; Active-Standby = one authoritative + warm failover; Connected = join an existing federation.
Why it’s in the workbookFederation gives consistent policy and faster failover across sites — the usual reason customers want it for DR.
Sizing / resource impactAdds Global Manager appliances (size them equally across paired domains).
Watch-outRequires dedicated (non-shared) NSX. Don’t toggle federation on a shared-NSX domain.
Say it like this“Federation adds a Global Manager at each site. Active-Standby is the common DR pattern — one site authoritative, the other warm.”
#

Avi Load Balancer (per domain)

Paid
What it isNSX Advanced Load Balancer (Avi) footprint for the domain; toggled separately for management and workload rows.
Why it’s in the workbookIf they bought Avi, it deploys controllers that consume resources.
Watch-outSet it in both the management and workload rows if you want it in both — they’re separate columns.
Say it like this“Avi is per-domain — if you want it in management and workload, we tick both rows.”
#

Security Services Platform (SSP / vDefend)

Paid
What it isThe platform behind vDefend micro-segmentation and security services (~6 vCPU / 24 GB; appears as SSP in workload rows).
Why it’s in the workbookRequired to deliver vDefend; it’s a paid add-on.
Sizing / resource impactIf included in the management domain, you don’t run it again in the workload domain.
Watch-outLicensing scope is independent of deployment. The appliances run and consume resources regardless of how many cores you’ve licensed — a partial license does not shrink the footprint. Decide (1) deploy or not, and separately (2) which clusters to license.
Say it like this“Two separate questions: do we deploy SSP at all, and which clusters do we license it to protect? The resource cost is the appliances; the license just governs coverage.”
#

Site Protection / DR (per domain)

Optional
What it isPer-domain footprint for replication/orchestration protection of that domain’s management components.
Why it’s in the workbookReserves resources for the DR tooling tied to that domain.
Say it like this“This line reserves room for the DR tooling protecting that domain’s components.”
#

Totals — Nodes / vCPU / RAM / Disk

Output
What it isThe summed VM demand across every included component and domain (e.g. ~11 fleet VMs at 114 vCPU / 292 GB / 7.6 TB in a minimal profile, climbing to 30–40 VMs fully loaded).
Why it’s in the workbookThis is the demand side of the capacity question.
Say it like this“This total is what we test against your existing clusters — the demand these appliances place on whichever data center hosts management.”
#

Host count (based on N-1)

Output
What it isRequired hosts computed from CPU, RAM and storage demand, taking the largest of the three, with an N-1 (failure) assumption.
Why it’s in the workbookN-1 means it sizes assuming you can lose a host.
Sizing / resource impactThe minimum still applies: 2 hosts (FC/NFS) or 4 (vSAN-ESA), and N+1 for HA headroom.
Say it like this“It sizes for losing a host — so the number already includes failure headroom. With ~40 VMs you’re typically a couple of blades plus HA.”
#

vSAN-ESA capacity model

Output
What it isVM capacity ÷ dedupe ratio + swap + FTT redundancy + rebuild reserve + growth = required raw storage.
Why it’s in the workbookOnly relevant if vSAN is the primary store.
Watch-outIf the customer isn’t using vSAN, leave this block alone — only the VM/appliance counts matter for an FC/NFS converge.
Say it like this“If you’re not on vSAN we ignore this box entirely — it’s only modelling ESA capacity and protection overhead.”
#

Advanced Management Domain Sizing

Optional
What it isOverrides for appliance sizes — vCenter XL, NSX manager size/model, Operations model/size, Cloud Proxy, Automation.
Why it’s in the workbookLets you model a non-default design without changing the simple toggles.
Say it like this“If the simple sizes don’t fit your design, this is where we override individual appliance sizes.”
Workbook tab 4 of 27

Static Reference Tables

Lookup data behind the dropdowns — read-only.

#

Static Reference Tables

Internal
What it isThe source lists behind every dropdown (valid sizes, models, options).
Why it’s in the workbookEditing here breaks the dropdowns — it’s lookup data.
Say it like this“That’s the dropdown source — read-only; we don’t touch it.”
Workbook tab 5 of 27

Deploy Management Domain

A data-entry sheet feeding the VCF Installer during bring-up, ordered the way the wizard asks for it: VCF Fleet, VCF Operations, VCF Automation, then the VCF Instance. The teaching point is categories and prerequisites, not every cell.

Reference values
Where you enter thisInstaller UI FQDNs & networks · API-only passwords & per-appliance sizing
NetworkVLANMTUGateway (CIDR)IP pool / rangeNotes
ESX Management1111150010.11.11.1/24hosts .101–.116routable
VM Management1110150010.11.10.1/24appliance IPsroutable
VCF Management1199150010.11.99.1/24svcs .31–.45routable
vMotion1112900010.11.12.1/24.101–.116L2 ok
vSAN1113900010.11.13.1/24.101–.116L2 ok
NFS1115900010.11.15.1/24.101–.116if NFS
Host overlay TEP1114900010.11.14.1/24pool .101–.132inherits VDS MTU
VPC uplink119810.11.98.1/24must route
Deploy the management domain (9.1) ↗
#

VCF Fleet block

Required
What it isTop-level fleet identifiers and the SDDC Manager / SSO details bring-up needs.
Why it’s in the workbookEstablishes the fleet the first instance creates.
What to enterFQDNs (DNS-resolvable in advance), SSO admin credentials, CEIP choice.
Watch-outEvery FQDN here must be pre-registered in DNS (forward + reverse) or bring-up fails.
Say it like this“Every name on this sheet has to resolve in DNS before we start — that’s the number-one cause of failed bring-ups.”
#

VCF Operations / Automation blocks

Required
What it isAppliance FQDNs, sizes and networking for Operations (and Automation if included).
Why it’s in the workbookThese are deployed during/after bring-up as the management plane.
What to enterNode FQDNs/IPs, sizes, passwords, management port group and gateway.
Say it like this“We pre-stage the Operations and Automation names, sizes and IPs here so the installer just consumes them.”
#

VCF Instance block

Required
What it isThe instance-level specification: network, storage and cluster details for the management domain itself.
Why it’s in the workbookDefines the first cluster the installer builds.
What to enterManagement VLAN/subnet/gateway, storage selection, vMotion/vSAN networks, NTP/DNS.
Say it like this“This is the actual cluster spec — the networks, storage and hosts the first domain is built on.”
#

Passwords & credentials

Caution
What it isRoot/admin/SSO passwords for the appliances.
Why it’s in the workbookThe wizard needs them, but they’re sensitive.
Watch-outTreat the populated workbook as a secret once credentials are entered — store it securely and strip before sharing.
Say it like this“Once we put passwords in, this file is sensitive — we’ll keep a clean copy for sharing and a vaulted copy for deployment.”
Workbook tab 6 of 27

Configure Management Domain

Day-0/1 hardening and integration after bring-up. Each block is independently toggled Include/Exclude.

Reference values
Where you enter thisSDDC Manager / VCF Operations each section gated by a toggle
Post-deployment configuration (9.1) ↗
#

SFTP Backups for SDDC Manager & NSX

Recommended
What it isTarget SFTP server, credentials, directory, fingerprint and encryption passphrase for configuration backups.
Why it’s in the workbookSeveral management components are protected by file-based backup, not replication — this is where that target is set.
Say it like this“This is the backup target for the management config — part of how we protect components that restore from backup rather than DR.”
#

Apply Signed Certificates (Microsoft CA)

Recommended
What it isMicrosoft Certificate Authority integration: install CA roles, configure basic auth, create a template, assign privileges, and issue CA-signed certs via Operations/SDDC Manager.
Why it’s in the workbookReplaces self-signed certs with enterprise PKI.
What to enterCA server URL, service-account credentials, template name, cert subject fields (Org, OU, Country, State).
Watch-outThe cert subject fields and CA template must match the customer’s PKI standards exactly, or issuance fails.
Say it like this“We wire VCF into your Microsoft CA here so every appliance gets an enterprise-signed cert instead of self-signed.”
#

NSX Network Connectivity

Required
What it isPost-deploy NSX routing/uplink configuration for the management domain.
Why it’s in the workbookEstablishes north-south connectivity for management.
Say it like this“This stitches management NSX into your physical routing.”
#

vSAN Stretched Cluster / Deploy Avi

Optional
What it isOptional post-deploy actions: stretch the management cluster across AZs, and/or deploy the Avi load balancer.
Why it’s in the workbookOnly when the design calls for multi-AZ or Avi.
Say it like this“These are conditional — stretched cluster only if you’re multi-AZ, Avi only if you licensed it.”
Workbook tab 7 of 27

Deploy Fleet Management Day-N

Where deferred components get specified after the platform is live — the Operations nodes, Cloud Proxy, License Server, Automation and the deferred toggles. Note several Day-N items are API-only.

Reference values
Where you enter thisVCF Installer deferred-components flow
Deploy deferred components (9.1) ↗
#

Shared Management Network + deferred toggles

Required
What it isWhether deferred components share the management network, plus Include/Exclude for each deferred piece.
Why it’s in the workbookControls what gets added after initial bring-up.
Say it like this“These are the things we deliberately deferred — we turn them on once the core platform is stable.”
#

VCF Operations cluster — Primary / Replica / Data nodes

Required
What it isFQDNs and IPs for the Operations primary, replica and data nodes, plus the load balancer.
Why it’s in the workbookDefines the Operations cluster topology.
What to enterOne FQDN + IP per node, on the management network.
Say it like this“An HA Operations cluster is primary + replica + data nodes behind a load balancer — each needs a name and IP.”
#

Cloud Proxy / License Server

Required
What it isFQDN/IP for the cloud proxy collector and the license server.
Why it’s in the workbookCloud proxy ingests remote data; license server centralizes licensing.
Say it like this“Cloud proxy is your remote-site collector; the license server is the single licensing point.”
#

VCF Automation + services runtime

Optional
What it isAutomation FQDN/IP and the services-runtime FQDN that backs it.
Why it’s in the workbookAutomation rides on the services runtime; adding it may grow worker nodes.
Say it like this“Turning Automation on here can auto-add a worker node to the runtime — expected behaviour.”
#

Deferred components (API-only)

Caution
What it isCustomize-password / proxy-portgroup / sizing options that are only available through the API, not the UI.
Why it’s in the workbookSome advanced Day-N customizations aren’t exposed in the wizard.
Say it like this“A few of these knobs are API-only — worth flagging so the delivery team scripts them rather than hunting in the UI.”
Workbook tab 8 of 27

Deploy Workload Domain

Defines a VI workload domain — either deploy a new one or import an existing vCenter. Each vCenter is typically its own workload domain.

Reference values
Where you enter thisVCF Operations workload-domain workflow
NetworkVLANMTUGateway (CIDR)IP pool / rangeNotes
ESX Management1311150010.13.11.1/24hosts .101+routable
vMotion13129000.101–.116pool
vSAN13139000.101–.116pool
vSAN storage client13159000.101–.116if disaggregated
Create a workload domain (9.1) ↗
#

Deploy vs Import Workload Domain

Required
What it isBuild a brand-new domain or import an existing vCenter as a domain.
Why it’s in the workbookConverge engagements usually import; greenfield deploys.
Watch-outThe only real difference is the process — deploy vs import; the end construct is the same.
Say it like this“For your existing clusters we import the vCenter as a workload domain rather than build new.”
#

Workload Domain Name + vCenter details

Required
What it isDomain name and the vCenter FQDN, root password, SSO user/password; whether it’s already attached to NSX.
Why it’s in the workbookIdentifies the domain and its vCenter.
Say it like this“Name the domain and point at its vCenter — and tell the workbook if that vCenter already has NSX.”
#

NSX Manager instance + size

Required
What it isWhether to deploy/join NSX and at what size, with appliance FQDNs.
Why it’s in the workbookShared vs dedicated decision made concrete here.
Watch-outIn 9.1 the first workload domain can join management’s NSX instead of getting its own.
Say it like this“Here’s where shared-vs-dedicated NSX becomes real — join management’s NSX or stand up a dedicated one.”
#

Network Pool + vSAN-ESA

Required
What it isCreate/select the VCF network pool and the storage architecture for the domain.
Why it’s in the workbookThe pool supplies vMotion/vSAN IPs; storage type sets host minimums.
Watch-outNetwork pools must not have overlapping IP ranges.
Say it like this“Each domain needs a non-overlapping network pool for vMotion/vSAN, and a storage choice that sets its host floor.”
Workbook tab 9 of 27

Configure Workload Domain

Hardening and NSX edge/routing for the workload domain, including federation if this domain participates.

Reference values
Where you enter thisvCenter / NSX centralized connectivity only
Workload domain connectivity (9.1) ↗
2 · NSX Federation — active / standby Global Manager
SITE A · primary NSX Local Mgr Global MgrACTIVE SITE B · recovery NSX Local Mgr Global MgrSTANDBY policy sync · RTEP Federation needs dedicated NSX — not the shared model.
#

Apply Signed Certificates

Recommended
What it isCA-signed certs for the workload domain via SDDC Manager (algorithm, key size, subject fields).
Why it’s in the workbookSame PKI hygiene as management.
Say it like this“Same cert story as management — enterprise-signed instead of self-signed.”
#

Create NSX Edge Cluster

Required
What it isEdge cluster spec: span, gateway types, edge form factor, TEP MTU, and per-edge-node details.
Why it’s in the workbookEdges provide north-south routing and stateful services (LB, NAT, DHCP) for the domain.
What to enterEdge node FQDNs, form factor (Medium/Large), Tunnel Endpoint MTU.
Say it like this“The edge cluster is what gives this domain north-south routing and services — size the edge form factor to the throughput.”
#

BGP / Top-of-Rack peering

Required
What it isEdge node AS ID and Top-of-Rack neighbor IPs, AS IDs and BGP passwords.
Why it’s in the workbookDynamic routing between NSX edges and the physical fabric.
Watch-outThese must match the network team’s fabric config exactly — they also land in the As-Built sheet.
Say it like this“The BGP details have to mirror your ToR config — we’ll confirm AS numbers with the network team.”
#

NSX Federation for Workload Domain

Optional
What it isFederation participation for this domain (Global Manager linkage).
Why it’s in the workbookExtends multi-site policy to the workload domain.
Say it like this“If this domain takes part in federation, we link its NSX to the Global Manager here.”
Workbook tab 10 of 27

Deploy Cluster

Add a single- or multi-rack Layer-2 cluster into an existing domain.

Reference values
Where you enter thisVCF Operations / SDDC Manager add-cluster workflow
NetworkVLANMTUGateway (CIDR)IP pool / rangeNotes
ESX Management1311150010.13.11.1host IPsroutable
vMotion13129000.101–.116pool
vSAN13139000.101–.116pool
vSAN storage cluster13169000.101–.116separate vSAN cluster
Add a cluster (9.1) ↗
#

Deploy Cluster

Optional
What it isParameters to add a new single-rack or multi-rack Layer-2 cluster into a selected workload (or management) domain — ESX management network (VLAN/gateway/CIDR/MTU), per-host details, storage and an optional new network pool.
Why it’s in the workbookDomains grow by adding clusters; this captures each one.
Say it like this“When a domain needs more capacity we add a cluster — this tab captures that cluster’s spec.”
Workbook tab 11 of 27

Change Control

Internal version plumbing — you don’t edit it.

#

Change Control

Reference
What it isA mapping of old field IDs to new ones between workbook revisions.
Why it’s in the workbookWhen the workbook is updated, field names change; this keeps references and any automation from breaking.
Say it like this“This is internal version plumbing — it maps old field names to new so an upgraded workbook still lines up.”
Workbook tab 12 of 27

Arkham

Internal store for cross-instance infrastructure values.

#

Arkham

Internal
What it isAn internal store for cross-instance infrastructure values — fleet deployment CIDR/network/gateway/MTU/VLAN, plus DNS, NTP, SMTP and domain-controller entries shared across instances, and subnet allocations.
Why it’s in the workbookHolds the global/cross-instance values the workbook reuses; the name is just a developer label.
Say it like this“Don’t be thrown by the name — it’s a behind-the-scenes store for fleet-wide network, DNS and NTP values.”
Workbook tab 13 of 27

Value Reference Tables - MR

The multi-rack variant of the working IP/FQDN reference tables.

#

Value Reference Tables (+ MR)

Internal
What it isWorking tables holding the per-component IP-address lists for the management and workload domains, sample FQDNs, and the PnP version — the source the entry tabs and As-Built sheets read from.
Why it’s in the workbookWhere “Value Missing” IP placeholders live until you fill the real values.
Say it like this“These feed the IP and FQDN entries you see elsewhere — you don’t edit them directly.”
Workbook tab 14 of 27

Value Reference Tables

Working tables holding per-component IP and FQDN values the entry tabs read from.

#

Value Reference Tables (+ MR)

Internal
What it isWorking tables holding the per-component IP-address lists for the management and workload domains, sample FQDNs, and the PnP version — the source the entry tabs and As-Built sheets read from.
Why it’s in the workbookWhere “Value Missing” IP placeholders live until you fill the real values.
Say it like this“These feed the IP and FQDN entries you see elsewhere — you don’t edit them directly.”
Workbook tab 15 of 27

Dumping Ground

Reference scratch area backing the DR tabs.

#

Dumping Ground

Internal
What it isA reference scratch area for Site Protection & DR — reference hostnames and IPs for vSphere Replication, Site Recovery Manager and recovery NSX Tier-1 objects, for management and workload domains.
Why it’s in the workbookBacks the DR tabs with sample/reference values.
Say it like this“Another working sheet — it backs the DR planning with reference hostnames and IPs.”
Workbook tab 16 of 27

Additional Racks

Per-rack host and network-pool blocks for multi-rack growth.

#

Additional Racks

Optional
What it isPer-rack host blocks (up to ~16 hosts per rack) and a per-rack network pool for multi-rack expansions — Rack 2, Rack 3, and so on.
Why it’s in the workbookLarger deployments span racks with their own VLANs/uplinks.
Say it like this“For multi-rack growth each rack gets its own networking block here.”
Workbook tab 17 of 27

Site Protection & DR

The protection blueprint. Much of it is reconfiguring DNS/NTP on the fleet and Operations nodes so they survive a site move, plus the DR appliance specifics.

#

Reconfigure DNS / Domain Search (fleet & Operations nodes)

Required
What it isPer-node DNS and search-domain settings for the Operations fleet manager, primary/replica/data nodes, logs nodes and network platform nodes.
Why it’s in the workbookA DR move changes name resolution context; nodes must be reconfigured to remain reachable.
Say it like this“For a clean failover, each management node needs DR-aware DNS and search domains — that’s most of this tab.”
#

Reconfigure NTP (cluster nodes)

Required
What it isNTP server addresses for the fleet and Operations cluster nodes at the protected/recovery site.
Why it’s in the workbookTime sync must hold across the move.
Say it like this“Time drift breaks certs and clustering — we pin NTP for every node so DR stays consistent.”
#

Protection Blueprint scope

Concept
What it isDefines which components are protected and how (backup-restore vs DR-tool).
Why it’s in the workbookNot every appliance is replicated — Automation and Operations restore from backup; others follow documented fleet-recovery procedures.
Watch-outDon’t design “replicate all 30 VMs.” Map each component to its supported protection method first.
Say it like this“We protect by method, not by blanket replication — Automation and Operations come back from backup, others via documented recovery.”
Workbook tab 18 of 27

Cyber Recovery

Deploys the Protection & Recovery appliance and wires up the SSO users it needs. Field families are appliance placement, networking, credentials and vCenter SSO registration.

#

Protection & Recovery Appliance deployment

Required
What it isWhere and how the appliance lands: management vCenter, cluster, VM name, datastore, network, hostname, root/admin passwords, NTP, gateway, DNS, IP/prefix.
Why it’s in the workbookIt’s the engine for cyber-recovery operations.
Say it like this“This is the recovery appliance — we place it in management and give it identity, network and credentials.”
#

vCenter SSO user for replication

Required
What it isCreate and role-assign an SSO user (vSphere Replication user) on the protected vCenter.
Why it’s in the workbookThe appliance authenticates to the protected vCenter through this account.
Watch-outThe user needs the correct group role or registration silently fails.
Say it like this“The appliance needs a dedicated SSO replication user with the right role — we create it on the protected vCenter.”
Workbook tab 19 of 27

On-Premises Ransomware Recovery

Deploy VMware Live Recovery on-prem, certificate, and SSO registration.

#

Deploy VMware Live Recovery appliance

Required
What it isAppliance placement and networking (management vCenter, cluster, VM name, datastore, hostname, passwords, NTP, gateway, DNS, IP/prefix).
Why it’s in the workbookThe isolated-recovery engine for ransomware scenarios.
Say it like this“Live Recovery is the ransomware-specific engine — we deploy it the same way as the cyber-recovery appliance.”
#

Replace appliance certificate

Recommended
What it isCert subject details (Org, OU, Locality, State, Country, FQDN, IPs, cert file).
Why it’s in the workbookEnterprise-trusted cert for the recovery UI/API.
Say it like this“We swap in a trusted cert so the recovery console isn’t throwing warnings during an incident.”
#

SSO registration user

Required
What it isvCenter SSO user to register Live Recovery against the protected vCenter.
Why it’s in the workbookAuthentication for the recovery workflows.
Say it like this“Same pattern — a dedicated SSO user registers Live Recovery to the protected vCenter.”
Workbook tab 20 of 27

Management Domain As Built

The authoritative network record for the management domain — VLANs, routing, BGP and FQDNs produced from your inputs.

#

BGP Requirements (As-Built)

Reference
What it isEdge AS IDs and Top-of-Rack neighbor IPs / AS IDs / BGP passwords per domain.
Why it’s in the workbookMirrors what the fabric must be configured with.
Say it like this“These BGP rows are exactly what your network team programs on the ToR switches.”
#

FQDN tables

Reference
What it isConsolidated FQDN list for the domain’s components.
Why it’s in the workbookDNS pre-staging checklist.
Watch-out“Value Missing” entries are a fast way to spot incomplete inputs before deployment.
Say it like this“Scan for ‘Value Missing’ — that’s the workbook telling you a required input isn’t filled yet.”
Workbook tab 21 of 27

Workload Domain As Built

The same network record, for each workload domain.

#

BGP Requirements (As-Built)

Reference
What it isEdge AS IDs and Top-of-Rack neighbor IPs / AS IDs / BGP passwords per domain.
Why it’s in the workbookMirrors what the fabric must be configured with.
Say it like this“These BGP rows are exactly what your network team programs on the ToR switches.”
#

FQDN tables

Reference
What it isConsolidated FQDN list for the domain’s components.
Why it’s in the workbookDNS pre-staging checklist.
Watch-out“Value Missing” entries are a fast way to spot incomplete inputs before deployment.
Say it like this“Scan for ‘Value Missing’ — that’s the workbook telling you a required input isn’t filled yet.”
Workbook tab 22 of 27

Public Reference Sheet

The shareable VLAN / IP / BGP master across both availability zones.

#

Public Reference Sheet

Reference
What it isThe consolidated VLAN & IP-subnet master for the management domain across both availability zones — Management VM, ESXi management, vMotion, vSAN, NSX Host Overlay, vSphere Replication, Edge Uplink 1/2, Edge Overlay and RTEP Overlay — plus the BGP requirements (edge AS, ToR IPs/AS/passwords) per AZ.
Why it’s in the workbookIt’s the single network record the fabric and DNS teams work from; safe to share because it carries no credentials.
Watch-outThis is a planning requirements sheet, not just a summary — if a row is blank, that network hasn’t been designed yet.
Say it like this“This is the network team’s master sheet — every VLAN, subnet and BGP value for both AZs in one place, no passwords, safe to hand over.”
Workbook tab 23 of 27

Version History

Which revision — and which calculation logic — you’re on.

#

Version History

Reference
What it isThe workbook’s version lineage. This guide maps to v1.9.1.004 (Jun 15 2026); recent revisions added API-only deployment options and a vCenter resize, and fixed sizing calculations.
Why it’s in the workbookTells you which revision — and therefore which calculation logic — you’re working with.
Watch-outAlways download a fresh workbook before a new design; the logic changes between versions.
Say it like this“We always start from a freshly downloaded workbook — an old copy can size things wrong because the logic changes.”
Workbook tab 24 of 27

Private AI Ready Infrastructure

Inputs for the Private AI validated solution — GPU enablement, Kubernetes/Supervisor, and the developer-ready infrastructure objects. Relevant when the customer is running AI workloads on VCF.

#

Private AI inputs — GPU & licensing

Optional
What it isPrivate AI license, GPU VM class, GPU Operator and Network Operator namespaces.
Why it’s in the workbookDefines how GPUs are exposed to Kubernetes workloads.
Say it like this“This block is only for AI workloads — it sets the GPU classes and operator namespaces.”
#

Kubernetes / Supervisor objects

Optional
What it isSupervisor namespace, cluster name, NSX segments/prefix-lists/route-maps, vCenter tags/categories, storage policy, content library, kubectl path, initial VM class.
Why it’s in the workbookStands up the developer-ready Kubernetes platform on VCF.
Say it like this“These are the Supervisor and NSX/vCenter objects that make the cluster developer-ready for AI.”
#

vMotion for vGPU VMs / GPU driver install

Optional
What it isEnable vMotion for vGPU-enabled VMs and install the vendor GPU driver on ESX hosts.
Why it’s in the workbookOperational enablement for GPU workloads.
Say it like this“Final steps make vGPU VMs mobile and load the vendor driver on the hosts.”
Workbook tab 25 of 27

Cloud-Based Ransomware Recovery

Recovery into a cloud SDDC on demand via VMware Cloud DR.

#

Cloud-Based variant — VMware Cloud DR / DRaaS

Optional
What it isThe cloud-hosted recovery path: a DRaaS connector appliance, a recovery SDDC in AWS (region, host type, VPC, subnets), a Cloud File System, service account and firewall rules.
Why it’s in the workbookRecovers to a cloud SDDC instead of a second on-prem site — capacity is spun up on demand at failover.
Watch-outIt’s a different product (VMware Cloud Disaster Recovery) from the on-prem Live Recovery appliance — don’t conflate the two tabs.
Say it like this“This is recovery into cloud on demand — a connector replicates to a cloud file system, and the recovery SDDC is created when you actually fail over.”
Workbook tab 26 of 27

Cross Cloud Mobility

The HCX-based validated solution for migrating workloads to a cloud SDDC (e.g. VMware Cloud on AWS). Inputs cover the HCX appliance, its network profiles, the vSphere role it needs, and the target cloud SDDC.

#

HCX appliance + network profiles

Optional
What it isThe HCX connector/appliance plus management and vMotion network profiles, a vSphere custom role, and VM folders/resource pool for the HCX appliances.
Why it’s in the workbookHCX is the migration fabric — it pairs your on-prem vCenter with the cloud SDDC and extends networks.
Watch-outNetwork Extension HA needs at least two extension appliances per switch / transport zone to form an HA group — don’t plan for one.
Say it like this“HCX is the mover — we register it with a vSphere role and set its management and vMotion profiles before any migration.”
#

Target cloud SDDC details

Optional
What it isCloud SDDC name, AWS region, host type and count, VPC, subnets, management subnet, firewall rules, access groups, and the HCX license key.
Why it’s in the workbookDefines the destination environment workloads migrate into.
Watch-outThe firewall rule names and access groups must align with the cloud provider’s networking, or the HCX tunnels won’t establish.
Say it like this“This half is the cloud side — region, VPC, subnets and firewall openings HCX needs to reach the SDDC.”
Workbook tab 27 of 27

Active Directory Inputs

A tab handed to the customer’s AD team. It collects the directory structure and the service accounts every component needs to bind to AD. Often the long pole — start it early.

Reference values
Where you enter thisActive Directory created by the customer AD team — not a VCF UI
svc-<role>-<target> · gg-<product>-<role>
AD prerequisites (9.1) ↗
#

Active Directory Details

Required
What it isParent/child FQDN & NetBIOS names and the User/Group OUs.
Why it’s in the workbookComponents bind into these OUs for identity.
Say it like this“This goes to your AD team — we need the domains, NetBIOS names and the OUs we’ll bind into.”
#

Service Accounts (app-to-external)

Required
What it isBind accounts for vSphere and NSX into AD, plus identity/access-management accounts.
Why it’s in the workbookEach integration authenticates with its own service account.
Watch-outProvision these early — AD change control is usually slower than the VCF build.
Say it like this“These service accounts are often the long pole — let’s get the AD request in now so it isn’t blocking go-live.”
#

Service Accounts (app-to-app)

Required
What it isAccounts wiring Operations, Operations for Logs, Operations for Networks, and Automation to each other and to vCenter.
Why it’s in the workbookInternal integrations also need credentials.
Say it like this“Beyond AD, the components authenticate to each other — these rows capture those internal accounts.”
Tools & reference

Sizing estimator

Toggle components to see a live ballpark of the management-domain footprint. Illustrative only — confirm against the live workbook.

0VMs
0vCPU
0GB RAM
Tools & reference

Collect before the call

Every input to gather, by owner and the tab that uses it. Tick as you confirm (resets on reload).

Identity & Active DirectoryCustomer AD team
DNS & namesDNS / platform team
IP & networkingNetwork team
Routing / fabricNetwork team
StorageStorage / platform team
Certificates & credentialsSecurity / PKI team
Resilience & cloudBackup / cloud team
Tools & reference

Glossary

The acronyms that come up in every workshop.

VCFVMware Cloud FoundationThe full private-cloud platform: vSphere + vSAN + NSX + Operations + Automation under unified lifecycle.
VVFvSphere FoundationThe lighter offering — vSphere + VCF Operations, without the full SDDC Manager / NSX automation stack.
SDDC ManagerSoftware-Defined Data Center ManagerDrives domain deployment, host commissioning and lifecycle within an instance.
FleetThe whole VCF estate managed centrally; fleet services live on the first instance.
InstanceOne VCF deployment within the fleet (First or Additional).
DomainA vCenter + NSX boundary — either a management domain or a workload domain.
LMNSX Local ManagerPer-domain NSX manager handling that domain's networking.
GMNSX Global ManagerFederation controller that synchronises NSX policy across sites.
SSPSecurity Services PlatformThe platform that delivers vDefend security services and its licensing.
vDefendVCF's distributed firewall / micro-segmentation security suite.
AviNSX Advanced Load BalancerSoftware load balancing (controllers + service engines).
Cloud ProxyCollector appliance that feeds remote-site data into VCF Operations (formerly 'connector').
Day-NAnything added after initial bring-up rather than during it.
ESA / OSAExpress / Original Storage ArchitectureThe modern (ESA) vs legacy (OSA) vSAN architectures; ESA needs a 4-host minimum.
FTTFailures To ToleratevSAN policy setting that drives storage overhead and host-count math.
TEP / RTEPTunnel / Remote Tunnel EndpointOverlay endpoints; RTEP carries overlay traffic between federated sites.
BGPBorder Gateway ProtocolDynamic routing between NSX edges and the physical Top-of-Rack switches.
ECMPEqual-Cost Multi-PathMulti-path routing for edge north-south throughput.
AZAvailability ZoneA fault domain / site; stretched clusters span two AZs.
N+1 / N-1Sizing with one spare host (N+1) / assuming one host lost (N-1).
HCXWorkload migration and network-extension fabric, used here for moving workloads to a cloud SDDC.
DRaaS / VCDRDisaster Recovery as a Service / VMware Cloud DROn-demand cloud recovery using a connector and a recovery SDDC.
MTUMaximum Transmission UnitFrame size; VCF wants jumbo frames (9000) for vSAN/vMotion/overlay.
CEIPCustomer Experience Improvement ProgramTelemetry opt-in toggled during deployment.
PnPPlan and PrepareThe workbook itself / its version identifier.
Tools & reference

Objection handling FAQ

The pushbacks customers raise — and a straight answer for each.

“We’re reusing our own hardware — why does converging add so many VMs?”
Because the management plane is new even when the hosts aren’t. SDDC Manager, VCF Operations, the services runtime and NSX managers don’t exist in a plain vSphere estate — converging adds them. The hosts are reused; the control-plane appliances are net-new.
“Why does a workload domain consume management-domain resources?”
A workload domain’s vCenter and NSX controllers run up in the management domain, not out on the workload cluster. So every workload domain you add increases load on management, even if its hosts are elsewhere.
“Do we really need HA / three nodes of everything?”
HA is the production answer — it’s most of the VM growth. Single-node (Simple) is supported for labs/PoC, but it puts the management plane on single points of failure. The call is availability vs footprint; size both and let the customer choose.
“Our vDefend license won’t cover the whole estate — should we still deploy SSP?”
Licensing scope and deployment are separate questions. The SSP appliances run and consume resources regardless of how many cores you license; a partial license doesn’t shrink them. Decide first whether to deploy the capability, then separately which clusters to license.
“Isn’t two management domains overkill?”
For DR it’s the recommended pattern: a management domain running at the recovery site keeps a control plane alive to manage recovered workloads if the primary is lost. Federation makes the failover faster and policy-consistent.
“Can we skip NSX?”
No — NSX is mandatory in VCF 9.x. It underpins management connectivity, VPC networking, Supervisor/Kubernetes and Identity Broker integration, even if you’re not doing overlay on day one.
“What’s the absolute minimum to get started?”
The mandatory core: SDDC Manager, VCF Operations (+ cloud proxy), the VCF services runtime, and an NSX Manager — on 2 hosts (FC/NFS) or 4 (vSAN-ESA), with N+1 for HA. Everything else is Day-N.
“Which data center should host the management domain?”
Whichever has the most available resources for these appliances — that’s the first thing the sizing totals tell you. A site that already runs NSX/Avi is a practical tiebreaker because there’s more headroom and fewer new pieces.
“Are these components patched separately?”
They’re appliances under unified lifecycle through VCF Operations / SDDC lifecycle; you can drive patch/upgrade workflows rather than touching each one. The dependency order still matters: SDDC Manager → vCenter → ESX → NSX.
Tools & reference

Cheat sheet

The numbers and traps worth memorising.

Minimums

  • Mandatory coreSDDC Manager + VCF Operations (+ cloud proxy) + services runtime + NSX Manager
  • Min hosts2 (FC / NFS) · 4 (vSAN-ESA) · N+1 for HA
  • Mgmt-domain VM ceiling~30–40 VMs fully loaded (high-watermark)

Key appliance sizes

  • VCF Automation24 vCPU / 96 GB — heaviest single toggle
  • NSX Manager (HA)3 × 6 vCPU / 24 GB
  • vCenter (Medium)8 vCPU / 30 GB
  • SDDC Manager4 vCPU / 16 GB
  • vDefend SSP6 vCPU / 24 GB (paid)

Top gotchas

  • Shared NSX can’t run Federation — federated domains need dedicated NSX.
  • SSP licensing scope ≠ appliance footprint; appliances run regardless.
  • Workload-domain vCenter/NSX run in the management domain.
  • “Consolidated/standard architecture” wording is retired in VCF 9.
  • Every FQDN must resolve in DNS before bring-up.
  • VCF Automation requires VCF Operations first.
Tools & reference

Appliance footprints & sources

Validated appliance sizes and the authoritative links.

ApplianceNodesvCPU (ea)RAM (ea)DiskNotes
SDDC Manager1416 GB~914 GBSingle size
vCenter (Medium)1830 GBResizable; 9.1 one-call API
NSX Manager (HA)3624 GB~300 GB ea3-node cluster for HA
VCF Operations (Medium)1+~8~32 GBSizing by object count
Cloud Proxy (Small)128 GBScales to 4/16, 8/32
VCF Automation12496 GB~626 GBHeaviest single appliance
vDefend SSP1624 GBPaid — security services
VCF services runtime (worker)3~24~48 GBAuto-resizes with components
Built from the VCF 9.1 Planning & Preparation Workbook (v1.9.1.004) and validated against Broadcom TechDocs — an internal enablement aid, not official Broadcom documentation. The estimator is illustrative; confirm against the live workbook, Configuration Maximums and the Compatibility Guide.
1 / 1