Prerequisites — Gate Before Any Workbook Inputs

This list mirrors the Prerequisite Checklist sheet of the official workbook. If any item is RED for your environment, fix it before spending a single meeting on the rest of the workbook — every later answer depends on these.

Authoritative source: the Broadcom VCF 9.1 Planning and Preparation doc set (the workbook’s TechDocs companion). Sections below link the specific pages where they exist.

When is each item needed?

Not everything here blocks bring-up. Every section below — and every row of the planning templates, in their When needed column — carries one of these four markers, using the same words in both places so a filled template can be checked straight against this doc:

The bring-up gate, at a glance — the subset that must be green before the Installer starts:

• Management-domain hardware — host count/spec, vSAN disks with no existing partitions, single hardware vendor
• VLANs + MTU — every traffic type, jumbo where required (overlay ≥ 1600)
• Host Overlay TEP addressing — static IP pool (recommended) or DHCP
• Principal storage decided — greenfield offers vSAN, VMFS on FC or NFS v3 only (matrix)
• NFS VMkernel + datastore mount — NFS principal storage only (below)
• FC zoning + VMFS datastore mounted on all hosts — FC principal storage only (below)
• BGP / ECMP to the ToRs — Centralized connectivity only
• DNS — forward A and reverse PTR for every bring-up FQDN, lowercase, each resolving to a unique unassigned IP
• NTP — two sources, reachable and in sync
• Binaries — depot decision made (online / offline / manual transfer), credentials in hand, SDDC Manager ISO downloaded
• Jump host — routed access + OVF Tool
• Active Directory — reachable, accounts and groups pre-created
• Public URLs / proxy allowlist — if anything is online
• Memory Tiering NVMe left out or disabled — Memory Tiering only, so vSAN can’t claim it (below)

Everything else in this document (workload-domain hardware, SMTP, the Certificate Authority, the SFTP backup target, Avi, vSphere Supervisor, fleet SSO) is Day-N: plan it now, but it will not hold up bring-up. One Day-N item has a hard clock: VCF licensing must be done inside the 90-day evaluation after bring-up.

Fillable planning templates (download)

Blank CSV sheets to capture the prereq plan, then transfer into the P&P workbook or Coscia’s planner. Each opens in Excel; the IP/DNS template’s Intake ID column maps back to workbook-cell-mapping.md (the other templates reference intake IDs in their notes where relevant).

Every template carries a When needed column using the same four markers as this document (above) — filter or sort on it to see exactly what must be ready before the Installer runs, and hand the rest to the teams that own it without holding up bring-up.

The IP/VLAN sheets hand off in a fixed order:

1. Network team fills the VLAN / subnet plan — VLANs, subnets, gateways, MTU, and the usable range inside each subnet.
2. Architect fills the IP allocation + DNS plan, assigning each FQDN + IP from those ranges (if the organization runs a central IPAM, request the addresses there instead of self-picking — the architect still compiles the sheet).
3. AD/DNS team creates the forward A and reverse PTR records from the filled IP/DNS plan.

• IP allocation + DNS (A/PTR) — per-appliance FQDN / IP, assigned by the architect from the network team’s subnets in the VLAN plan (create both forward A and reverse PTR); duplicate the block per workload domain, add AZ2 hosts if stretched
• VLAN / subnet plan — VLAN, subnet, gateway, MTU + minimum IP count per traffic type
• NTP / AD / CA — NTP sources, AD domain/accounts/groups, CA + cert template
• BGP peering — Edge/ToR AS, peer IPs, BFD (MD5 optional)
• Firewall request — deployment-critical flows (source / destination / port / purpose) for the security team; see 07-firewall-ports.md
• vSphere Supervisor prep — 9.1 · 9.0 — one combined sheet for enabling a Supervisor on a workload domain (pre-flight, VPC networking, load balancer, Supervisor settings, content libraries, VKS, ordered tasks, firewall matrix); Day-N, only if a Supervisor is in scope. See 10-supervisor-enablement.md

Data hygiene: these are blank templates. A filled copy holds real, sensitive data (IPs, DNS names, AS numbers) — store it in a secure location, not in a public or shared repository.

Hardware

Management Domain

When needed: Bring-up. The Installer validates the hosts it is given.

Single uplink, redundancy from the fabric (e.g. Cisco UCS fabric failover). If a host gets one vNIC and the fabric fails it over (UCS fabric failover, or similar on other converged / blade platforms), ESX sees one pNIC on that path. Usually it’s just the management vNIC (vmk0), with everything else on dual vNICs. Sometimes it’s the whole host. Broadcom supports both (Commission Hosts: “Hosts can have a single physical NIC or multiple physical NICs. For hosts with multiple physical NICs, only one can be connected to a standard switch”), but plan for these:

• API-only bring-up. The workbook says “Single NIC is supported with API Only”. Build the JSON spec from the start. The Installer wizard’s vDS profiles expect two uplinks on every vDS.
• No teaming at the host on that path. The single-uplink vDS (and in the whole-host case, the NSX host TEP) has one uplink, so failover happens below ESX, where vCenter and NSX can’t see it. The fabric must detect upstream failures as well. On UCS, make sure the vNIC’s network control policy takes the vNIC link down when the fabric interconnect loses its uplinks (Action on Uplink Fail = Link Down, the UCS default; don’t change it to Warning). With Link Down, “the vNIC will be instructed to go into a down state when its corresponding Uplink (logical or physical) goes down”. With Warning, “traffic could become blackholed” while the host still sees a link up (Cisco: HyperFlex and the Network Control Policy, 2019; it is written for HyperFlex, but the network control policy is the generic UCS one). That’s a fabric design check: VCF does not validate it.
• vSphere HA may warn about management network redundancy. With vSAN, HA uses the vSAN network (KB 313261), so a single-uplink management vDS alone shouldn’t trigger it; with NFS/FC, or vSAN on the single uplink, each host shows Host <xxx> currently has no management network redundancy. Broadcom says it “can be safely ignored”. To suppress it, “set the VMware HA advanced option das.ignoreRedundantNetWarning to true and reconfigure VMware HA on that host” (KB 317612). The KB’s click-paths are from older vSphere clients; only the option name carries over.
• NFS principal storage is fragile on one pNIC. Pre-validation can fail a working single-NIC NFS setup (KB 441194, since withdrawn by Broadcom; archived copy), and the Installer can leave the NFS VMkernel stranded on vSwitch0. See NFS v3. vSAN is the easier pairing.
• Later hosts must match. Workload-domain and expansion hosts need the same NIC layout. Extra vmnics on a host are unusable (KB 442933).

Recommendation: if the fabric can present two vNICs where you planned one (on UCS: one pinned to fabric A and one to fabric B, without fabric failover), use them. You get the standard 2-pNIC layout, the Installer wizard and default profiles work, the HA warning goes away, and failover happens in ESX, where vCenter and NSX can see it.

Going single-pNIC anyway? The step-by-step build, with worked layouts (management-only and whole-host), JSON specs, validation snags, post-bring-up and later hosts, is in 29-single-pnic-build.md.

Two easy-to-miss gate checks: disks intended for vSAN must have no existing partitions (the workbook repeats this on every storage row — a classic bring-up validation failure), and all management-domain hosts must come from a single hardware vendor (Preparing ESX Hosts for VCF or vSphere Foundation).

9.1 management footprint is bigger. Even with most optional fleet components excluded, the management domain runs ~12 appliances / ~120 vCPU, because 9.1 deploys a baseline VCF services runtime (3 control + 3 worker nodes) alongside vCenter, the 3-node NSX Manager cluster and SDDC Manager. It grows further with VCF Operations, VCF Automation, Log Management and the License Server. Don’t reuse a VCF 4.x/5.x host spec — resize on the Management Domain Sizing sheet against the components you’re actually deploying.

Workload Domain

When needed: Day-N. Workload domains are built after bring-up (deployment plan E9) — but order the hardware on the same lead time as the management hosts.

Same shape as Management Domain. Minimum 3 hosts, 4+ recommended for prod. VI workload domains support up to 64 pNICs per host.

TechDocs: Preparing ESX Hosts for VCF or vSphere Foundation covers the ESX install + basic host configuration this gate expects. The hardware minimums themselves (all pNICs ≥ 10 GbE, vSAN hosts certified on the compatibility guide) come from the workbook’s Prerequisite Checklist, not that page.

Principal storage

When needed: Bring-up (the management domain’s choice, intake A7) and Day-N (each workload domain / cluster, intake H6). Principal storage is the datastore a cluster is created on. It is picked once per cluster and shapes the host hardware, the storage network and every later cluster operation, so settle it before ordering hardware.

Options matrix (VCF 9.1)

Broadcom’s 9.1 support matrix, verbatim from Storage Models:

* “Principal Storage marked with an asterisk can be achieved by converging existing virtual infrastructure to a VMware Cloud Foundation instance for a management domain or importing an existing virtual infrastructure to a VMware Cloud Foundation for a workload domain.”

How to read it:

• A new build (the VCF Installer, or the workload-domain / cluster wizards) offers only vSAN (ESA/OSA), VMFS on FC and NFS v3 as principal storage. Everything marked with an asterisk is reachable only via converge (management domain) or import (workload domain); see the next subsection.
• Stretching (multi-AZ) works two different ways. The same page’s function matrix marks Stretched Clusters as supported for vSAN, FC and NFS (not iSCSI or NVMe), with the footnote “Fibre Channel and NFS stretched cluster can be achieved using vSphere Metro Storage Cluster (vMSC). See KB 417356”.
  • vSAN uses VCF’s own automated stretch workflow (stretch API + vSAN witness): 03-multi-az-prep.md and 22-stretch-execution.md.
  • FC / NFS stretch as a vSphere Metro Storage Cluster, built by the storage vendor. “VMware Cloud Foundation is unaware of vMSC and treats it the same as a vSphere cluster” (KB 417356). Per that KB: the storage vendor must have tested the solution with VCF 9.x (Broadcom doesn’t test vMSC internally); the management domain’s initial cluster supports only “Stretch all Layer-2 Networks”; with NFS the NFS Layer-2 network must be stretched too; ≤ 10 ms RTT between hosts (the vendor’s replication limit may be 5 ms); no Storage I/O Control on a vMSC datastore; vSphere HA/DRS settings, DRS groups and VM/host rules are configured by hand; host counts double (HA management domain: minimum 3 + 3, recommended 4 + 4).
  • iSCSI / NVMe: the matrix marks them as not supporting stretched clusters, yet KB 417356 says vMSC storage connectivity “using any other storage type is supported with VCF Import when converging or upgrading an existing vSphere environment”. The two sources disagree; confirm with Broadcom before designing a stretched iSCSI/NVMe cluster.
• Minimum hosts differ: 2 for NFS/FC, 3 for vSAN in a simple deployment (see Hardware).
• vVols is not in the 9.1 matrix. It is deprecated as of VCF/VVF 9.0; the workload-domain wizard still offers it, but don’t design new clusters on it (see the note under H6 in 02-intake.md).
• A workload domain can mix principal storage types per cluster, but every host within one cluster uses the same type.

Converge / import-only options, and their drawbacks

When needed: Bring-up (if in scope). NFS v4.1, iSCSI, FCoE and NVMe over Fabrics (TCP, FC, RDMA) have no greenfield workflow. Broadcom’s documented route (KB 416270) is to build plain vSphere first and bring it into VCF afterwards:

• Management domain: install ESX on the hosts → configure the datastore on one host → deploy vCenter 9 onto it → build the vSphere cluster with all hosts on that shared datastore → deploy the VCF Installer and run the Converge workflow.
• Workload domain: the same first four steps, then in VCF Operations Add Workload Domain → Import a vCenter to turn it into a workload domain with that datastore as principal storage.

It works, and lifecycle management (patching / upgrades) of the converged clusters is fully supported afterwards. But it trades automation for storage choice, so weigh the drawbacks before picking it:

• You build and own the storage plumbing by hand. No VCF workflow configures iSCSI port binding, NVMe-oF adapters or NFS 4.1 multipathing / Kerberos. Every host, now and every host added later, is configured manually (or with your own host-profile / script tooling).
• Every future cluster or domain on that type repeats the build-then-import route. The Add Cluster / Create Workload Domain wizards still only offer vSAN, NFS v3, VMFS on FC (and vVols). And in the management domain, iSCSI and NVMe are supplemental only for additional clusters; only the default cluster can use them as principal storage.
• Day-2 host and cluster changes happen in vCenter, not VCF. Hosts can only be added to an imported cluster through the vSphere Client, and commissioning can’t even describe these storage types (it offers only vSAN, NFS, VMFS on FC and vVol). The host has to be prepared by hand and added in vCenter; the full procedure is 25-cluster-expansion.md §5. After such a change, KB 416270 says “If this step [Sync Inventory] is not performed then lifecycle management in VCF Operations will be blocked for these hosts and clusters” on 9.0; “As of version 9.1 running ‘Sync Inventory’ in the VCF Operations console is no longer required.”
• ESX root passwords of imported hosts aren’t managed by VCF Operations. Per the converge page, “Password Management of imported ESX hosts via the Password Management Console of VCF Operations” is not available. The workaround, KB 388859, is a script (addEsxiRoot.py, run as root on SDDC Manager) that adds the ESX root credentials the import did not capture.
• Converge has its own entry bar. The existing environment must meet Supported and Not Supported Configurations to Converge to VCF: among others a vSphere Distributed Switch (no Cisco virtual switches), vLCM images rather than baselines, fully automated DRS, no vCenter HA, no dynamically allocated VMkernel IPs, and no Enhanced Linked Mode (for a converged management domain; for an import, not combined with an existing NSX registration). And all clusters in the vCenter are converged / imported; you can’t pick a subset.
• Watch the principal-datastore pick. “If the default cluster includes multiple datastore types, VCF determines the primary datastore using the following priority: vSAN, NFS v3, VMFS, NFS 4.1, iSCSI, vVols.” A leftover NFS v3 or VMFS datastore shared by the hosts can therefore win over the NFS 4.1 / iSCSI datastore you intended. Keep only the intended shared datastore common to all hosts.
• Stretching is unclear at best. VCF’s automated stretch workflow is vSAN-only, and the Storage Models matrix marks iSCSI and NVMe as not stretchable, although KB 417356 allows vMSC with other storage types via VCF Import (see the options matrix notes).

Treat converge/import-only principal storage as a deliberate exception (existing array investment, a storage team’s standard), not a default. If the array also serves NFS v3 or FC, those give you the same storage through the fully automated greenfield workflows.

NFS v3 (only if in scope)

When needed: Bring-up (if in scope). Only when the management domain’s principal storage is NFS v3 (intake A7).

The VCF Installer does not build the NFS path for you on the first host — per TechDocs, “If you plan to deploy the VCF Installer appliance on an ESX host that will form the management domain and your storage type is NFS v3, you must manually mount the NFS datastore on that host.” So if NFS is to run on its own VMkernel (rather than over the management VMkernel, vmk0), that VMkernel has to exist before the Installer runs. TechDocs describes three layouts:

What has to line up with the Installer (or pre-validation fails at “NFS Datastore Configuration” — KB 446573):

• Port group name — the pre-created port group must use exactly the name you give the NFS vDS port group in the Installer (default SDDC-DPortGroup-NFS, or the portgroupKey in a JSON spec). TechDocs: “During the deployment workflows in VCF Installer, you must use the same port group name for the NFS vDS port group …”
• First-host NFS VMkernel IP — give the hand-built VMkernel an address in the NFS subnet but outside the Installer’s NFS IP range (the workbook’s NFS IP Address Range / includeIpAddressRanges in a JSON spec). The Installer hands out that whole range to the hosts’ NFS VMkernels; an address taken from it on the first host risks an IP conflict or a validation failure. This is field-verified (VCF 9.1, separate NFS vDS): bring-up completed with an out-of-range address — Hands-On Guide: How to install VCF 9.1 on NFS Principal Storage. Note that TechDocs says the opposite: assign the IP “from the NFS network spec IP range” and “define an NFS pool that includes the assigned IP address” (Mount NFS Datastore to an ESX Host; that sentence also mislabels its own placeholders). KB 446573 doesn’t cover the IP at all. The out-of-range address is the one known to work.
• Dedicated VLAN — with a dedicated NFS VMkernel, the NFS network must be its own VLAN, not shared with ESX management (William Lam, linked below; see 01-network-dns-plan.md, NFS row).
• MTU 9000 end to end — ToR, pNIC, switch and VMkernel. Test from the host before starting: vmkping -I <vmkX> -s 8972 -d <nfs-server-ip>.
• Export ACL / policy — the NFS array must allow the whole NFS VMkernel subnet (every management host), not just the first host’s IP.

Single-pNIC hosts: William Lam documents (VCF 9.0) that the Installer can migrate the only uplink to the vDS while leaving the NFS VMkernel and its port group behind on vSwitch0 — which then has no connectivity, so NFS drops. The workaround is migrating the NFS VMkernel to the vDS port group by hand in vCenter: Workaround for single NIC using NFS storage with VCF 9.0. The normal 2-pNIC layout (see Hardware) avoids it.

TechDocs: Mount NFS Datastore to an ESX Host (9.1). Principal-storage support overview: KB 416270. TechDocs-sourced — not yet field-verified in this repo.

VMFS on Fibre Channel (only if in scope)

When needed: Bring-up (if in scope). Only when the management domain’s principal storage is VMFS on FC (intake A7).

FC needs more up-front work than NFS: the VCF Installer’s storage page asks only for the datastore name, and states “The datastore must already be created and mounted on all ESX hosts.” Nothing is zoned, masked or formatted for you, and unlike NFS, Broadcom’s host-preparation section has no FC page. So this is the checklist, from the 9.1 Fibre Channel Storage Model:

• HBAs: on the Broadcom compatibility list, with identical firmware and drivers on every host. One per host is the minimum; two or more is recommended for failover and bandwidth.
• SAN zoning: every management host zoned to the array (single- or multi-initiator zoning, per your fabric standard).
• Array side: host registration and LUN masking, so every host sees the same LUN(s).
• VMFS 6 datastore: created on the shared LUN and mounted on every management host before the Installer runs, with the exact name you will enter in the Installer (its pre-populated name, or yours). Broadcom recommends provisioning VM disks thick eager-zeroed.
• Multipathing: Round Robin path selection policy recommended; check every host shows all expected paths before bring-up.
• Hosts: minimum 2 per cluster, 4 recommended.
• Stretch only as vMSC: an FC cluster can’t use VCF’s automated (vSAN) stretch workflow, but it can be stretched as a vSphere Metro Storage Cluster built by the storage vendor (KB 417356; see the options matrix notes). If you plan that, the zoning and the VMFS datastore above span both sites.

Check all hosts in one go before starting the Installer. The hosts are still standalone at this point, so this PowerCLI snippet connects to each one directly and prints one row per host. You compare the rows, not each host’s output separately:

Warning: not tested yet. This snippet has not been run against real hosts. It is read-only (it changes nothing on the hosts), but check the output makes sense before relying on it, and report anything that breaks.

# VCF PowerCLI. Pre-bring-up: hosts are standalone, so connect to each directly.
$esxHosts  = 'sfo01-m01-esx01.sfo.rainpole.io','sfo01-m01-esx02.sfo.rainpole.io'  # all mgmt hosts
$datastore = 'sfo-m01-cl01-ds-vmfs01'   # exactly the name you will enter in the VCF Installer
$cred      = Get-Credential root
Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Scope Session -Confirm:$false | Out-Null

$esxHosts | ForEach-Object {
    $vi    = Connect-VIServer -Server $_ -Credential $cred -NotDefault
    $esx   = Get-VMHost -Server $vi
    $cli   = Get-EsxCli -VMHost $esx -V2
    $ds    = Get-Datastore -Name $datastore -Server $vi -ErrorAction SilentlyContinue
    $naa   = if ($ds) { $ds.ExtensionData.Info.Vmfs.Extent[0].DiskName }
    $vmfs  = if ($ds) { $ds.FileSystemVersion }
    $nmp   = if ($naa) { $cli.storage.nmp.device.list.Invoke(@{device = $naa}) }
    $paths = if ($naa) { @($cli.storage.core.path.list.Invoke(@{device = $naa})) } else { @() }
    $fc    = @($cli.storage.san.fc.list.Invoke())
    [pscustomobject]@{
        Host      = $_
        Datastore = [bool]$ds
        Device    = $naa
        VMFS      = $vmfs
        PSP       = $nmp.PathSelectionPolicy
        Active    = @($paths | Where-Object State -eq 'active').Count
        Dead      = @($paths | Where-Object State -eq 'dead').Count
        HBA       = ($fc.ModelDescription | Sort-Object -Unique) -join ','
        Firmware  = ($fc.FirmwareVersion  | Sort-Object -Unique) -join ','
        Driver    = ($fc | ForEach-Object { "$($_.DriverName) $($_.DriverVersion)" } | Sort-Object -Unique) -join ','
    }
    Disconnect-VIServer -Server $vi -Confirm:$false
} | Format-Table -AutoSize

What a pass looks like: Datastore is True everywhere, the same Device (naa ID) on every row, VMFS 6.x, PSP = VMW_PSP_RR, the same Active count on every host with Dead = 0, and identical HBA / Firmware / Driver on every row. If any row differs, fix that host before bring-up.

Interim snippet. A full cross-host storage-readiness check (FC, NFS v3, and the converge-only types) is being built into VCFHostPreparation (#10); this snippet will be replaced by a pointer to it once that lands. The esxcli options are checked against the ESX 9.1 esxcli reference; the snippet itself is not yet lab-tested.

The same “zoned, masked, formatted and mounted first” rule applies later to every host you commission for an FC workload domain or cluster, and to cluster expansion; see 25-cluster-expansion.md. TechDocs: Deploy a New VCF Fleet or VCF Instance (storage page). TechDocs-sourced — not yet field-verified in this repo.

Memory Tiering over NVMe (only if in scope)

When needed: Day-N (if in scope) — but the hardware is ordered with the hosts, and the device has to survive bring-up unclaimed. Memory Tiering uses a local NVMe device as extra (slower) host memory. It is enabled per cluster after the cluster exists; the full guide is 28-memory-tiering.md.

• It fits the workload: memory consumption high, active memory below 50 % of DRAM, CPU headroom left, and no memory overcommit planned on those clusters.
• A dedicated NVMe device per host (two for a software mirror), from the compatibility guide’s vSAN SSD list: NVMe, endurance class D (≥ 7300 TBW), performance class F or G, ≥ 3 DWPD. Local only, never shared with vSAN, boot or a datastore. This is often a different drive than the vSAN ReadyNode’s.
• Sized at least as large as host DRAM (default 1:1 ratio, 4 TB maximum tier); a mirror device the same size or larger.
• No existing partitions on the device.
• No Intel Optane PMem or NVDIMM-N in the hosts.
• Kept out of vSAN at bring-up / workload-domain creation. VCF’s vSAN deployment may auto-claim every eligible disk (documented for 9.0, not verified for 9.1). Leave the tiering device out or disabled until the cluster is built, then add it — see 28-memory-tiering.md §3.

TechDocs: Memory Tiering over NVMe (requirements) and Capacity Planning Considerations. The official P&P workbook has no Memory Tiering fields. TechDocs-sourced — not yet field-verified in this repo.

GPU hosts (only if in scope)

When needed: Day-N (if in scope) — but the GPUs are ordered with the hosts, and the GPU image must exist before the workload domain or cluster is created. NVIDIA GPUs for vGPU or passthrough; the full guide is 32-gpu-hosts.md.

• GPU mode chosen per cluster: passthrough (Fixed / Dynamic DirectPath), vGPU time-slicing, or vGPU MIG. MIG can’t serve NVIDIA NIMs.
• Card supported on both lists, matched on its PCI VID / DID / SVID / SSID: the Broadcom Compatibility Guide for ESXi 9.1 in that mode, and (vGPU) NVIDIA’s vGPU support matrix for a release with a VCF 9.1 package (19.4+ or 20.x). The two lists disagree on older cards — see 32-gpu-hosts.md §3.4.
• Licences owned: NVAIE (or another NVIDIA vGPU licence) for vGPU — passthrough doesn’t need one; the Private AI Foundation add-on only if its features are used. NVIDIA entitlements can take 24 business hours to appear in the portal.
• NVIDIA Enterprise account with download access, and the vGPU host driver offline bundle (ZIP) downloaded for the chosen release.
• SR-IOV enabled in the BIOS of every vGPU host.
• A vSphere Lifecycle Manager image with the NVIDIA host driver built in vCenter and imported into the VCF Instance (VCF Operations → Build → Lifecycle → Image Management) before the domain or cluster is created.
• NVIDIA License System instance planned (vGPU): owner, placement, and how guests receive the client configuration token.
• At least 3 GPU hosts in the initial cluster if it’s for Private AI Foundation.

TechDocs: VMware Private AI Foundation with NVIDIA 9.1 (PDF) (requirements) and Import a vSphere Lifecycle Manager Image to a VCF Instance. The visible sheets of the official P&P workbook have no GPU fields (the 9.1 workbook keeps a hidden, legacy Private AI Ready Infrastructure sheet; the 9.1.1 workbook has none). TechDocs-sourced — not yet field-verified in this repo.

Private AI Foundation (only if in scope)

When needed: Day-N (if in scope) — after the GPU hosts above; the dark-site items below take the longest, so start them with the hardware order. The full guide is 33-private-ai-foundation.md.

Always:

• Scope decided: deep learning VMs / VKS with GPU / Private AI Services; connected or disconnected; Private AI Services 2.1 or 3.0. The Quickstart needs both deep learning VMs and VKS prepared.
• VCF Automation deployed (catalog path; Private AI Services 2.1 UI), with an All Apps organization on VPC networking (public, transit gateway and VPC private IP ranges) — see 17-vcfa-tenant-config.md.
• Supervisor on the GPU workload domain; storage classes with the same names on every vCenter in the VCF Automation region.
• NVIDIA: client configuration token and an NGC API key (vGPU).
• Harbor capacity planned — model galleries (Private AI Services), and on 9.1.1 a public project for deep-learning-container.
• Private AI Services only: Data Services Manager in the management domain (always for 2.1; for 3.0 with knowledge bases and agents), an OIDC provider (not VCF SSO — different networks), and a Broadcom registry token if installing from Broadcom’s registry.
• GPU capacity left unreserved for one host’s failover.

Disconnected (dark site) additionally:

• Bastion host (internet side: Docker, Helm, VCF Consumption CLI) and admin host (inside: Docker, VCF Consumption CLI, kubectl, ORAS), same Linux image — or one combined DMZ host — and a way to carry .tar bundles across.
• NVIDIA DLS appliance (workload domain or management domain), registered on the NVIDIA Licensing Portal: IP, FQDN, owner, backup.
• Platform Harbor (VCF Automation’s Harbor service on 9.1; otherwise the Harbor Supervisor Service), with projects and a robot account, and ~40 GB for Private AI Services on top of the GPU Operator, DL containers and models.
• Web server reachable from the VKS clusters: an Ubuntu package mirror (≥ 800 GB) and the vGPU guest / data center drivers with an index file.
• VCF software depot holding the Ubuntu VKr images (VCF Download Tool) — see 09-binary-depot.md.
• Deep learning VM .ova downloaded from the Broadcom Support Portal.
• Bastion allowlist: at least the endpoints the Private AI Services artifact mirroring tool pulls from — pais-docker.packages.broadcom.com, packages.broadcom.com, helm.ngc.nvidia.com, nvcr.io, archive.ubuntu.com — plus the NGC catalog, the Broadcom Support Portal and the NVIDIA Licensing Portal for the manual downloads.
• Outside staging storage and a transfer path, sized and tested. Getting the images inside is the hard part: everything is prepared and hosted outside first, and it’s a lot of data (Ubuntu mirror ≥ 800 GB alone). Measure the full set on the bastion and time a test transfer — see 33-private-ai-foundation.md §4.2a.
• An owner and refresh routine per artifact — nothing updates by itself on a dark site.

TechDocs: VMware Private AI Foundation with NVIDIA 9.1 (PDF) (setup workflows, deployment artifacts for disconnected environments). The P&P workbook has no visible PAIF fields. TechDocs-sourced — not yet field-verified in this repo.

Network

Source: the workbook’s Prerequisite Checklist → Network Requirements block — every row above mirrors it except the VLAN and load-balancer rows, which are this guide’s additions. TechDocs 9.1 links inline where a page exists; the ECMP and stretched wording has no standalone TechDocs page and is anchored on the workbook itself.

Avi Load Balancer (only if in scope)

When needed: Day-N (if in scope). Nothing here blocks bring-up.

Needed when Avi is the chosen load balancer for any of these: vSphere Supervisor on a workload domain (then the controller cluster must exist before activation — but Supervisor also runs without Avi, via the NSX / VPC networking paths’ built-in load balancer or the Foundation Load Balancer), optionally in front of VCF Automation (never required — both the single-node and HA models ship a built-in L4 load balancer that serves the cluster VIP; Avi in front is a post-deployment addition for SSL termination / keeping user access off the management network), or tenant/workload load balancing. Deployed Day-2 from VCF Operations (lifecycle-managed), with the served domain’s vCenter and NSX already configured. Per the Avi-for-VCF 9.1 requirements, for Supervisor use the controller cluster must be deployed before Supervisor activation.

Controllers are central, Service Engines are local. The Avi controllers always run in the management domain — whichever domain they serve, including a Supervisor on a workload domain. That is the same pattern as a workload domain’s vCenter and NSX Managers, which also run in the management domain (04-sizing.md’s workload-domain repeater). Only the Service Engine VMs are distributed: they run per cluster, in the workload domain.

A controller set is scoped to the NSX instance, not the workload domain: workload domains that share an NSX instance share one controller set; a workload domain with its own NSX instance gets its own set. Count controller sets by NSX instance, and Service Engines by cluster.

Prepare up front:

• 4 IPs on the management domain’s VM Management network, per controller set (so per NSX instance — multiply if the fleet runs more than one): 3 controller nodes + the cluster VIP.
• One DNS record per set — the cluster FQDN, with A + PTR, resolving to the cluster VIP, and it must exist before you start the deploy (field-confirmed 2026-07-22). Reserve four addresses but expect to type three: the wizard takes Node 1/2/3 IP Address, then under “Enter the VIP for cluster access” offers only Cluster FQDN and Cluster Name — the VIP address itself is not entered here. The VIP is reached through the FQDN, which is why the A record has to exist up front. Keep the VIP in the IP plan regardless: it is a real address that must be reserved and excluded from DHCP, it just is not typed into this wizard. The 3 controller nodes are IP-only: the workbook’s Avi section asks for them as plain IP fields and nothing resolves them by name, so don’t ask the AD/DNS team for records that nothing consumes (01-network-dns-plan.md DNS table, intake E16, and workbook-cell-mapping.md all say the same).
• A Cluster Name as well as the cluster FQDN — a separate field, and the two are not interchangeable. Decide both up front rather than inventing one at the wizard.
• Controller size: Small / Large / XLarge (the deploy wizard’s tiers). Size it in 04-sizing.md — note the workbook’s Avi disk figures diverge from the NSX ALB controller ladder.
• Two strong passwords (password manager, owners in intake F11): the controller admin and the VCF Ops admin accounts — the wizard asks for both, on the same screen, so the VCF Operations admin credential has to be to hand at Avi deploy time, not just the new Avi one. Avi’s rule, verbatim from the field tooltip: at least one lowercase, one uppercase, one digit, one special character (!@#$%^&*()~) and at least 15 characters.
• Avi binaries in the depot — 32.1.1 or higher must be available from the (online or offline) depot before VCF Operations can deploy the controller (see 09-binary-depot.md).
• A local content library in the target vCenter for the Service Engine images, and a Service Engine management network (dedicated VLAN or overlay segment; SE management IPs via DHCP or a static IP pool in the controller). Service Engines are always present per cluster — every cluster Avi serves runs its own, with a minimum of 2 for HA, so budget their footprint and management IPs per cluster in the workload domain, not once per fleet. The VIP source depends on the networking path (VDS: VIP/data network + IPAM profile; VPC: the VPC external IP blocks).
• Firewall: admin access to the controller UI/API (443) and the Service Engine ↔ controller secure channel — see 07-firewall-ports.md §E.
• A passphrase for the controller’s configuration backups (separate from the admin/VCF Ops admin passwords) — treat it like the SFTP backup encryption passphrase: chosen up front, stored in a password manager, with a named owner. It is required to restore, and nothing on the VCF side asks for it.
• A License Hub decision — the controller must be pointed at either Cloud Licensing or an on-prem License Hub before it reports usable licences; see 15-license-hub.md.

For the deploy wizard fields, the controller’s own first-login setup, the full licensing chain, and known gotchas, see 14-avi-load-balancer.md.

VCF licensing (License Server and registration)

When needed: Day-N — but with a hard deadline: within the 90-day evaluation period after bring-up. Nothing here blocks the Installer, but missing the deadline is worse than missing a bring-up item.

The License Server is deployed at bring-up (deployment plan story 5.4). To license the fleet, VCF Operations and the License Server are registered with the VCF Business Services console (vcf.broadcom.com), licenses are assigned from VCF Operations, and license usage is reported back on a schedule. What the registration and usage files actually contain, field by field, is in the upgrade guide’s Licensing: what is sent to Broadcom.

Decide up front: connected or disconnected mode.

Either mode can be switched later, but after more than 180 days disconnected, switching to connected “might fail, and you must generate a new activation code” (Switch from Disconnected to Connected Mode).

The evaluation clock starts at bring-up — license the fleet inside it. Each ESX host (from first boot), vCenter and VCF Operations instance runs up to 90 days in evaluation. Per Broadcom: “If you fail to license your VCF fleet before the evaluation period expires, you must reinstall the software because you cannot license a fleet with an expired evaluation period.” [documented] (Licensing Model). Hosts added later without free license capacity also run on their own evaluation clock, counted from install.

The 180-day rule and what happens if it slips [documented] (Licensing Overview, KB 391605):

• No usage report and license update for 180 days → the license expires (notifications appear beforehand).
• Then 90 days to update it. Workloads keep running.
• After that: ESX hosts disconnect from vCenter, and nothing powered off can be powered on again — running VMs carry on, but HA restarts, maintenance shutdowns and patch reboots stay down. Recovery is an updated license file.

Keep the License Server up and watched. If it or VCF Operations is down, running workloads are not affected, but licenses can’t be assigned and usage reports can’t be generated — a long outage still runs into the 180 days. Put the License Server on a cluster with vSphere HA, and alert on the vSphere Client banner “One or more vCenter instances are not connected to a license server” (KB 443240; the KB says it “should remain powered on at all times”).

Optional: keep the FQDN out of registration. By default the registration uses the VCF Operations FQDN and License Server hostname as display names. Broadcom documents a setting to switch that off, run before registering — see the upgrade guide’s registration file section (untested there).

Prepare up front: the mode decision, internet / proxy path (connected) or a named owner and calendar slot (disconnected), the Broadcom account that can sign in to the VCF Business Services console, and the license entitlement for the host core count.

License Hub (only for vDefend, or Avi on on-prem licensing)

When needed: Day-N (if in scope). Nothing here blocks bring-up.

License Hub provides “centralized license management and reporting for VMware vDefend and VMware Avi subscription license files” — it replaces the traditional 25-character license keys with digitally signed subscription license files. Relevant only when vDefend or Avi is in scope; plain VCF without either does not need it. For Avi it is optional: the Avi Controller can use Cloud Licensing (register directly with the Avi Cloud Console) instead — “Avi Controllers that cannot run a License Hub can connect and register directly to the Avi Cloud Console” [documented]. The hub is the route for disconnected sites, or by choice for on-prem control (#374).

License Hub is not the License Server — and both exist. The License Server is deployed automatically at bring-up, is tied to VCF Operations, and licenses the VCF fleet (deployment plan story 5.4). License Hub is a separate appliance, deployed Day-N, licensing vDefend + Avi. They coexist — a fleet with vDefend, or with Avi on on-prem licensing, has both. Two similar names, two unrelated appliances: don’t plan one and assume it covers the other.

Prepare up front:

• Decide the deploy path by version — the mechanics differ. License Hub 2.0 (current, GA 2026-08-05) deploys as one standalone OVA (~11 GB, downloaded from the VMware Avi Load Balancer product page, not vDefend SSP); 5.1.2 deploys from the separate SSP Installer plus a .tar package as a 3-VM instance. Confirm which version applies before planning IPs/FQDNs, since the pool/FQDN shapes are not the same between them.
• IP/FQDN plan, immutable after deployment either way. 2.0 needs an appliance FQDN/IP plus a 2-address Kafka pool and a non-routable internal cluster CIDR (≥512 addresses); 5.1.2 needs ~9 IPs across node + service pools plus two FQDNs (Instance, Messaging). See 15-license-hub.md for the exact field-by-field shape.
• Registration mode — Connected or Disconnected, decided at first login, tied to the depot decision (intake G1). Connected needs the endpoint portal.pulse.broadcom.com (Avi Cloud Console — not on the Public URLs list) reachable from an administrator’s browser; disconnected is a recurring manual file-exchange loop, including a six-monthly licence re-import, forever, for air-gapped sites.
• A Broadcom customer account holder identified — an entitlement question, not the same person as the vCenter administrator. Either mode needs someone who can act on it.
• NSX firewall exclusion planning — if License Hub VMs sit in an NSX overlay/VLAN segment with security enabled, they need a firewall exclusion entry; raise this with whoever owns DFW policy before deploying.

For the full deploy-wizard field tables (both 2.0 and 5.1.2), the post-deploy registration/licensing chain, and field-verified gotchas (including a firstboot failure mode in 2.0), see 15-license-hub.md.

vSphere Supervisor (only if in scope)

When needed: Day-N (if in scope).

Nothing here is needed at bring-up — the Supervisor is enabled per workload domain, Day-N (intake H5, deployment plan E9). But activation asks for all of it at once, and the workbook carries only three Supervisor fields (name, Service CIDR, control-plane IP range), so collect the rest up front — the combined Supervisor prep template (9.0) groups every field below to match 10-supervisor-enablement.md:

• 5 consecutive static IPs for the Supervisor control plane on the management network — 3 control-plane VMs + 1 floating IP + 1 reserved for rolling updates. The workbook’s “Control Plane IP Range” is this block.
• Supervisor API FQDN + DNS record — logging in by FQDN is required to avoid certificate issues; point the record at the floating IP (no load balancer) or the load-balancer VIP. Add it to the Step 1 DNS table.
• Service CIDR — private, unique per Supervisor (the default usually works; it must not overlap other Supervisors or the fleet networks).
• Load balancer — Supervisor activation requires one; pick per WLD (intake H5): the built-in NSX/VPC LB (no extra appliance), the Foundation Load Balancer (platform-packaged L4 active/passive pair, for VDS networking), or Avi — then the whole Avi section above applies and must be complete before activation.
• North-south connectivity — the hard prerequisite. The workload domain’s own NSX connectivity model (intake H4, chosen per WLD, independent of the management domain’s) must be built and up before activation, along with its Supervisor-specific reservations:
  • VCF Networking with VPC (Distributed connectivity): the Distributed Transit Gateway + VNA cluster, a routable external IP block (north-south NAT / load-balancer VIPs, advertised upstream via BGP) and a private transit gateway IP block — in 9.1 this block must be a /16 (9.0 accepted a /24; with a /24 in 9.1 the deployment never completes — see the references below).
  • NSX segment networking (Centralized connectivity): the Edge cluster + Tier-0 first, plus ingress and egress CIDRs for the Supervisor.
  • VDS networking: distributed port groups for the workload network(s) (one designated primary), on a different subnet than the Supervisor management network, plus the FLB or Avi from the LB bullet (a VDS-networking Supervisor has no built-in NSX load balancer).
• Cluster readiness — vSphere DRS (fully automated) and HA enabled on the target cluster(s); storage policies chosen for the control-plane VMs, ephemeral disks, and image cache.
• Kubernetes content — Supervisor services / VKS release binaries come from projects.packages.broadcom.com (already in the Public URLs table below); air-gapped sites must plan the offline content-library path.
• Routing — the Supervisor management network must reach vCenter and the ESX hosts’ management vmkernel (Spherelet), and the workload network must reach the load-balancer VIPs.
• Zones — vSphere Zones must be created in vCenter before activation (vCenter → vSphere Zones → Add New vSphere Zone), one cluster per zone: three zones for a multi-zone Supervisor, one compatible cluster for single-zone. The activation wizard selects zones, it does not create them, and the single- vs multi-zone choice cannot be reversed afterwards. All clusters in a zone must sit on the same vDS. A three-zone Supervisor also needs ≤ 100 ms latency between the zone clusters (see 03-multi-az-prep.md for the stretch/AZ groundwork, and 10-supervisor-enablement.md §1.3 for the procedure).

TechDocs: vSphere Supervisor Platform (per-networking-path requirements pages) and Requirements for Simplified Supervisor Deployment (routing + FQDN-login requirements). The 9.1 /16 transit-gateway change is lab-documented in VCF 9.1 Home Lab Series Part 9 — Deploy Supervisor and the VCF 9.1.x Ultimate Deployment Guide.

Active Directory

When needed: Bring-up. The domain must be reachable and the accounts and groups must exist before the deployment starts (deployment plan E4 story 4.3). Using them for fleet SSO is Day-N — see the next section.

• Supported OS: Windows Server 2019 or 2022.
• Parent domain (forest root) reachable from SDDC components.
• Bind / service accounts and admin groups pre-created before install: the AD bind accounts you plan for vSphere / NSX, the Identity Broker bind account (see below), and the admin groups you will map to VCF roles — capture them in the intake (section C, e.g. C5).
• Decide the bind account’s password-expiry policy, and write down every system that uses it. Creating the account is the easy part; what breaks later is its rotation. The same bind account typically backs vCenter’s identity source, NSX’s LDAP configuration, VCF Operations, Log Management and the Identity Broker — each caches the credential independently, so one password change breaks all of them at once and each fails silently until somebody tries to log in. Either exempt the account from expiry deliberately, or own a rotation runbook that walks a maintained list of consumers. Doing neither means the domain’s normal expiry schedule decides when your fleet loses authentication.
• AD DCs reachable from every management component.

When every AD login fails at once: recognise the signature before you start debugging. Field-verified 2026-07-22 — an expired/changed bind password took down all AD authentication to the Identity Broker, and the symptoms actively mislead:

• The service’s own health endpoint reports healthy. The broker’s /acs/health returned true throughout, and its OIDC discovery, signing keys and configuration were all fine — none of that touches the directory binding. A green health check does not mean people can log in.
• The error message is deliberately uninformative. “Authentication was unsuccessful. Verify your credentials or contact your administrator if the issue persists” is the same string for a wrong password, a user outside the search base, a failed service-account bind, and a missing role mapping — it is anti-enumeration, so read nothing into it.

The signature to recognise: all AD users failing simultaneously + the service reporting healthy = bind credential or LDAPS trust, essentially always. Two cheap confirmations, in order: does a local account still log in (if yes, it is the directory side), and does a direct bind with the configured credential succeed:

$e=New-Object System.DirectoryServices.DirectoryEntry("LDAP://<dc-fqdn>:636/DC=example,DC=com","<bindDN>","<password>"); $e.NativeObject; "bind OK"

If the bind fails it is the account or the LDAPS path; if it succeeds the problem is base DN / search filter / group-role mapping instead. Also check the LDAPS certificate expiry on the DCs — the other cause of every AD login dying at once, with the same misleading symptoms.

Workbook gotcha: the Active Directory Inputs tab that the workbook’s own prereq row points at is hidden in the 9.1 workbook (v1.9.1.001) and still carries VCF 4.x/5.x-era content — Workspace ONE Access and Aria Suite Lifecycle groups, old Aria product names, HCX/HRM service accounts, VMw@re1! reference passwords. Unhide it for the svc-* / gg-* naming convention only; the actual 9.1 account set is the short list above.

Identity source for the VCF Identity Broker

When needed: Day-N. The broker ships at bring-up but is configured Day-2 (deployment plan E8 story 8.5) — collect these inputs early so that day isn’t spent chasing AD.

VCF 9 federates fleet-wide SSO through the VCF Identity Broker. The broker itself is deployed at bring-up with the VCF Management Services (no opt-in; its FQDN + services-runtime IP are part of the Step 1 plan) — what happens Day-2 is its configuration (deployment plan E8, story 8.5 fleet SSO). Prepare the AD-over-LDAP identity source up front; it has specific inputs and well-known gotchas.

What to prepare:

• Bind / service account — a dedicated AD account with read access to the base DN. If you use the Global Catalog, it must also have read on the TGGAU (Token-Groups-Global-And-Universal) attribute.
• Base DN (e.g. dc=example,dc=com), a Base Group DN (required to sync groups), and optionally a Base User DN.
• LDAPS root CA certificate in PEM format (with the BEGIN CERTIFICATE / END CERTIFICATE lines) if you use an encrypted connection (recommended).
• Domain controllers — a primary (and a secondary for failover), or DNS auto-discovery via SRV records; reachable on 389/636 (see 07-firewall-ports.md).
• Groups to sync, including the group you will map to the admin role.

Common gotchas:

• Login is the domain UPN (user@domain.com), not the email address — even when the email is synced, users must sign in with the domain UPN (Broadcom KB 393150). Trips up organisations where the email suffix differs from the UPN suffix.
• Global Catalog syncs only universal groups — local/global groups won’t appear until converted to universal, and the bind account needs the TGGAU read permission.
• The LDAPS certificate must be PEM (with BEGIN/END CERTIFICATE lines) — a missing or wrong-format root CA breaks the encrypted connection.
• Single Base Group DN — to sync groups spread across OUs, set the base group DN high enough to cover them all; a too-narrow DN silently misses the admin group.
• Nested groups — enable Sync Nested Group if admin membership comes via nested groups, or those members won’t sync.
• Sync runs weekly by default — a service-account password expiry or lockout will quietly stop group updates.

Other supported identity sources: OpenLDAP, and external IdPs — Microsoft Entra ID (OIDC / SAML) and AD FS. Those need different prep; see Broadcom’s Configure an Identity Provider (per-IdP sub-pages) and Configure Active Directory as an Identity Provider Using AD/LDAP on TechDocs. These are deliberately the 9.0 pages — the 9.1 doc set does not republish the SSO setup section, so 9.0 is the newest published version.

Once this prep is done, the actual configuration — the identity-provider wizard, federating vCenter/NSX/VCF Operations/VCF Automation/Supervisor/Log Management, and role assignment per product — is 12-sso-configuration.md.

Host Overlay TEP addressing (static IP pool recommended)

When needed: Bring-up. The Installer asks for the pool (or expects DHCP) while deploying the management domain.

How each host gets its GENEVE tunnel-endpoint (TEP) IPs on the ESX Host Overlay VLAN. Either way, size for at least nodes × pNICs IPs plus growth — e.g. a 4-node cluster × 2 pNICs = 8 IPs minimum.

• Recommended: static IP pool — entered directly in the VCF Installer at bring-up (and per cluster in the workload-domain wizard). No external DHCP service to build, monitor, or keep alive; and in stretched (multi-AZ) designs no per-AZ DHCP scope per TEP subnet. The P&P workbook’s own Deploy Management Domain sample uses IP Pool for the IP Assignment (TEP) field.
• Alternative: DHCP scope on the ESX Host Overlay VLAN — fully supported, same sizing rule; use it when the network team already operates DHCP on that VLAN and prefers central address management.

Broadcom TechDocs accepts either for the prerequisite — “a static IP pool or a DHCP server configured and advertising IP addresses on the … NSX host overlay (Host TEP) VLAN” (Create a New Workload Domain). TEP IP pools can also be created per cluster after bring-up (Create an IP Pool for Tunnel Endpoint IP Addresses).

DNS

When needed: Bring-up. The single most common cause of a failed bring-up — A and PTR must both resolve before the Installer runs.

• Forward + reverse zones for every FQDN in the Deploy Management Domain, Deploy Workload Domain and Deploy Cluster sheets. All A and PTR records present before deploy.
• Every FQDN and IP unique — each FQDN must resolve to a unique, currently unassigned IP address (workbook + the FQDN inventory page below).
• Create every FQDN lowercase — TechDocs requires it for the fleet-services family (“Do not use capital letters in the FQDN”), and creating all records lowercase avoids the trap entirely — see the Step 1 plan (01-network-dns-plan.md §C).
• Dynamic updates: Nonsecure and secure.
• Replication scope: all DNS servers in the forest.
• Two DNS servers configured on every appliance.
• One CNAME wrapping the two NTP A-records for round-robin (see below).
• The authoritative per-component FQDN/IP inventory is in Broadcom TechDocs: VCF Components FQDNs and IP addresses (9.1 Planning and Preparation).

NTP

When needed: Bring-up. Hosts and appliances must be in sync before deployment — skew breaks certificate validation and cluster formation.

• Two external time sources per site (radio/GPS, upstream NTP, or NTP served by the ToR switches / physical routers).
• Two A-records pointing at the two sources.
• One CNAME (e.g. ntp.sfo.rainpole.io) → A-record name for round-robin HA.
• The two external servers themselves synced to different upstreams (healthy NTP dispersion).
• Optional: per-server A-records (e.g. ntp0 / ntp1) for direct management of the individual sources.
• AD domain controllers synced to the same external NTP.
• Different time sources for different fault domains / sites.

Source: the workbook’s Prerequisite Checklist → NTP block (incl. the A-record/CNAME construction). Host-side setup: TechDocs Configure NTP on the ESX Hosts.

SMTP

When needed: Day-N. Alerting is configured in VCF Operations after bring-up.

• Mail relay reachable from each SDDC component (alerting).
• Restrict relay to SDDC management IP range(s).
• The consumer is VCF Operations’ outbound Standard Email plug-in (alert notifications), configured Day-2 with exactly these values — TechDocs: Configure Email Alert Plug-in Settings.

Certificate Authority

When needed: Day-N. Bring-up runs on self-signed certificates; the CA-signed replacement is done once the fleet exists (deployment plan E6 6.2 partial / E8 8.5 full). Have the CA reachable and its template validated before bring-up anyway — the environment gate (E4 story 4.3) checks it, and a missing template blocks the entire Day-2 certificate pass.

• VCF 9.1 fleet certificate management (VCF Operations → Fleet Management → Certificates → Configure CA for Fleet) offers two CA types: Microsoft CA or OpenSSL. It’s a single fleet-level setting — there is no separate Microsoft-only restriction for “management” vs “instance” components.
• External / third-party CA is CSR-based only: VCF generates the CSR, you sign it on your CA, and import the signed certificate. The private key never leaves VCF — you cannot import a certificate that was created entirely outside VCF (VCF does not accept an externally-generated private key).
• Microsoft CA: must support Basic authentication; recommended Windows Server 2019/2022 with the Certificate Authority + Certificate Authority Web Enrollment roles (Web Enrollment on the same host as the CA role). The full four-step prep (roles, basic auth, certificate template, least-privilege service account) is TechDocs Prepare Your Microsoft Certificate Authority to Allow VMware Cloud Foundation to Manage Certificates.
• Have ready for the Configure-CA wizard (Microsoft CA): the CA server URL (https://<ca-fqdn>/certsrv), the least-privileged service account + password, and the issuing certificate template name.
• OpenSSL: configured on the appliance with the org details (Common Name, Country, Locality, Organization, OU, State) — no external prerequisites.
• The certificate pass is a bulk operation — but it must be staggered. Field-verified 2026-07-22 on a real deployment. In VCF Operations → Fleet Management → Certificates you tick multiple components in the list and act on them together: Generate CSRs, Download CSRs, Replace With Configured CA Certificate, Import Certificates (plus Renew Certificates and Replace With Imported Certificates). Progress is reported per batch as an n/total counter, and the UI notes changes may take some time to appear after the task reports success. Three planning consequences:
  • Generate before replace. The Replace With Configured CA Certificate dialog states “Last generated Certificate Signing Requests (CSRs) will be used for generating certificate(s)” — the replace consumes the most recently generated CSRs rather than issuing fresh ones. Regenerate if the component’s SANs/FQDN changed since the last generate, or you will sign a stale request.
  • Do not fire batches in parallel. The dialog carries a mandatory acknowledgement behind this caution: “Each certificate rotation can trigger automated retrust operations across dependent components. To avoid system instability, wait for any current or ongoing batch operations to be completed before starting the next.” So the change window budgets fewer, larger batches with a settling wait between them — not one sweeping fleet-wide action, and not many small ones fired concurrently.
  • The CA burst is real. A batch submits every selected CSR at once. On a Microsoft CA, confirm the issuing template does not require manual approval — an approval-gated template turns a bulk generate into a stalled queue rather than an error.
  • A failure does not stop the batch. Field-verified 2026-07-22: when one component’s replacement failed, the remaining ones kept progressing. A batch is therefore partial-success by design — it will not halt and wait for you. The n/total counter is the only signal that something did not land (5/6 means one failed), so read the final count and open the task list, rather than treating “the batch finished” as “the fleet is certified”. Re-run the failed components as their own small batch once the current one has settled, and verify per component at the end of the pass.
  • The CSR dialog ships with Broadcom’s placeholders — replace them. Field-observed 2026-07-22: Generate CSR pre-fills Organization Broadcom, Organizational Unit vcfms, Country United States of America, State CA, Locality Palo Alto, and defaults Key Size to 2048. Easy to click straight past — and then wrong in every certificate you issue. Agree the subject fields with whoever owns the CA (they may be enforced by the template anyway) and confirm 2048 meets the site’s crypto policy before generating in bulk.
  • DNS/FQDN SAN is a required field. Even for components deployed IP-only — VCF Operations for Networks is the example (see 05-day2-deployments.md §B.2) — so every component you intend to certify needs a resolvable name planned in Step 1. For a multi-node/clustered appliance the dialog requires “FQDNs and IPs of all nodes”.
  • NSX Manager: watch for a backup running concurrently. Field-observed 2026-07-22 — the one failure in a batch was an NSX Manager, with an NSX backup in progress at the time. The working theory (not confirmed) is that the rotation triggers a backup itself and does not wait long enough for it to finish before proceeding. Either way the mitigation is the same: check that no NSX backup is running or scheduled in the window, and give NSX Manager its own batch rather than bundling it with a long run of ESX hosts. If it fails, re-run it alone once the backup has completed.
• The certificate list also carries an Auto-renewal Status column. In a freshly deployed 9.1 fleet the entries observed were Deactivated — treat auto-renewal as something you opt into, and check expiry ownership rather than assuming the fleet renews itself.
• TechDocs walk-throughs: Configure a Certificate Authority for VMware Cloud Foundation and the umbrella Managing Certificates in VMware Cloud Foundation section.

SFTP backup target

When needed: Day-N. The fleet-wide backup target is configured in VCF Operations right after bring-up (deployment plan E6 story 6.3) — build it in parallel with the deployment, not after go-live.

• SFTP target (TCP 22) reachable from the VCF management network — SDDC Manager, NSX Manager, vCenter and the fleet components — VCF Automation plus the VCF management services (Log Management, Identity Broker, Software Depot, fleet/SDDC lifecycle, real-time metrics, Salt) — all back up to it.
• Service account + write path pre-created (e.g. svc-vcf-bck → /backups/).
• The external SFTP server must support 256-bit ECDSA and 2048-bit RSA SSH keys, with host key algorithms including one of rsa-sha2-512 / rsa-sha2-256 and one of ecdsa-sha2-nistp256 / nistp384 / nistp521.
• FIPS is on by default in 9.x SDDC Manager and cannot be turned off, so the FIPS-mode SSH requirements always apply: the server must also offer a KEX from diffie-hellman-group-exchange-sha256 / ecdh-sha2-nistp256 / nistp384 / nistp521, and the MAC hmac-sha2-256 (not only the -etm@openssh.com variant — a common hardening trap). Verify the handshake before registering the target: 08-backup-target.md §4.
• A backup encryption passphrase chosen and stored in a password manager with a named owner — it is required during restore; a lost passphrase makes every backup on the target useless.
• Placed outside the management domain it protects — a backup target that dies with the platform is not a backup.

Build guidance (what backs up and how often, placement, a hardened chrooted OpenSSH worked example, gotchas) + references: 08-backup-target.md. TechDocs: File-Based Backups for SDDC Manager, NSX Manager and vCenter and Configure SFTP Backup Target in VCF Operations. Note the workbook’s own SFTP row is stale here — it still says NSX + SDDC Manager “configured through SDDC Manager”; in 9.1 the fleet-wide target is set in VCF Operations and covers the components listed above.

Jump host

When needed: Bring-up. Nothing starts without it.

The machine the whole deployment is driven from. It must exist before day one and survive independently of the platform it deploys — don’t place it on the cluster being built (or on storage that depends on it).

• Routed access to: ESXi mgmt, VM mgmt, VCF mgmt, and the internet (binary downloads, if the online depot is used).
• Modern browser — VCF Installer UI, vCenter, NSX Manager, VCF Operations.
• OVF Tool — deploys the VCF Installer appliance OVA.
• SSH client — PuTTY, or the OpenSSH client built into Windows 10+ / Windows Server 2019+ (appliance console work on the VCF Installer, SDDC Manager, vCenter).
• SFTP/SCP client — WinSCP (or plain scp/sftp) for moving bundles, certificates, and log collections on and off appliances.
• PowerShell 7 + VCF PowerCLI — needed if you build a custom ESX ISO (vendor add-ons / async drivers), and generally useful for day-2 automation.
• Excel — for the P&P workbook itself.
• Verification tools — nslookup / Resolve-DnsName for the DNS gate and w32tm (Windows) / ntpdate -q (Linux) for the NTP gate, run from the same network vantage point the appliances will use.

Binaries

When needed: Bring-up. The depot decision (G1) drives infrastructure — an offline depot is a web server you have to build, so decide it early.

Everything else comes through the depot — decide online, offline, or manual transfer early (intake G1), because the offline path means building infrastructure:

• Online depot — VCF Installer and the fleet talk to the Broadcom depot directly; have the Download Service ID + Activation Code ready (intake G2/G3) and outbound 443 per the Public URLs table below. Generating the download credential requires the Product Administrator role on the Broadcom support-portal site — arrange it early (see 09-binary-depot.md). TechDocs: Connect VCF Installer to Broadcom or an Offline Depot and Download Binaries.
• Offline depot (air-gapped) — the VCF Download Tool is the only supported method in 9.1; you also need a web server (≥ 1 TB disk, HTTPS) to serve the downloaded depot store. TechDocs: Download Binaries to an Offline Depot by Using the VCF Download Tool.
• Manual transfer (one-off installs) — VCF Download Tool on any internet-connected machine, then copy + import the depot store on the VCF Installer appliance itself; no depot server, but Day-N patching needs repeat side-loads into the fleet Depot Service. TechDocs: Manually Transfer Binaries to VCF Installer.

Build guidance (depot web server setup, Download Tool commands, transfer + connect steps, using the tool standalone to pre-stage binaries) + references: 09-binary-depot.md.

Public URLs (online functionality)

When needed: Bring-up (if in scope). Only if something goes online — the platform, or (air-gapped) the machine running the VCF Download Tool.

Everything online in VCF 9.1 — depot downloads, licensing, compatibility / vSAN HCL data, CEIP — talks to a short list of public URLs, all outbound TCP 443. Hand this table to the firewall team as-is, and if egress goes through a proxy (intake G5), have these allowlisted on it. Source: Public URLs Required for Online Functionalities (earlier versions: KB 327186).

Proxying these? The proxy must be reachable from the whole services-runtime node block, not just the depot/Ops IPs. Allowlisting these URLs on the proxy is only half of it: the fleet also has to reach the proxy, and a fleet-side proxy precheck does a plain TCP (netcat) connect from a pod that can land on any VCF services-runtime node. Broadcom’s documented access doesn’t call this out, so the proxy port often gets opened only for the depot + VCF Operations IPs and the proxy config then fails to apply. Firewall the whole node block to the proxy port. Full writeup + how to read the precheck logs: 09-binary-depot.md §5.

Air-gapped? The platform itself then needs none of these — but the machine running the VCF Download Tool still does, from wherever it runs. Plan that host’s outbound access (or proxy allowlist) as part of this gate.

Two notes on the newer rows. The three CEIP endpoints (vcsa.vmware.com, vcsa.telemetry.broadcom.com, scapi.telemetry.broadcom.com) are distinct destinations, not alternatives — allowlist all three if telemetry is on. The api.prod.nsxti.vmware.com row applies only when vDefend IDS/IPS is in scope (it is not part of the base VCF SKU); a fleet without vDefend threat-prevention can drop it.

Sign-off

Confirm in writing that all items above are green before the intake meeting (Step 2) — the Bring-up ones because they stop the deployment, the Day-N ones because a gap found on the day you need them costs the same time, just later. If anything is amber/red, capture the owner, target date, and risk before starting the workbook.