Deployment Plan — Agile Work Breakdown

A ready-to-use work breakdown for a VMware Cloud Foundation 9.1 deployment, structured as epics → stories → tasks so it drops straight into a scrum / agile backlog (Jira, Azure DevOps, GitLab, …). It captures what and in what order and who owns it — deliberately no dates or estimates; add those in your own tool.

▶ Open the Deployment Plan export tool — build your deployment scope and export this plan as Markdown or a CSV that imports into Jira, Azure DevOps, or GitLab.

▶ Track execution in the Deployment Tracker — the same plan as a checklist: tick stories as done, watch per-epic progress, and save/load the progress file to hand over between colleagues (it follows the scope you set in the export tool).

Every exported story links its guide. Where this site has an install or configuration guide for a story, the export adds a Guide line (Markdown) or fills the Reference column (CSV) with an absolute link to it, so the link still works inside Jira, Azure DevOps or GitLab. The build checks that each of those links reaches a real page and heading (web/scripts/check-plan-guides.mjs).

Build your scope from the blocks below: the core epics apply to every deployment, and the variants switch on independently. The management domain can be stretched or not; the Day-2 fleet is optional; and you add one or more workload domains, each independently non-stretched or stretched.

Scope building blocks

Epic ids follow execution order. Mix freely — e.g. a stretched management domain

• the Day-2 fleet + two workload domains (one stretched) = Core + E7 + E8 + two E9. Execution order runs core config → management stretch → Day-2 → workload domains → handover. The export tool assembles the exact epic/story set per scope.

Core epics (every deployment)

E1 — Network, DNS & routing plan · Owner: Network + AD/DNS/NTP

Ref: 01-network-dns-plan.md

• Story 1.1 — VLAN / subnet plan. Lock every management VLAN, subnet, MTU, gateway, and the IP carve-out.
  • Acceptance: one-page plan signed by the network owner; every VLAN/subnet/gateway/MTU recorded and no overlapping subnets.
• Story 1.2 — North-south connectivity plan (choice: Centralized or Distributed). Pick the model per domain (intake A10 for the management domain, H4 per workload domain) and plan only that model’s inputs — see 01-network-dns-plan.md §B.
  • Centralized (BGP plan). Edge AS, ToR AS, peer IPs, BFD, advertised/received routes — plus an optional MD5 password only if you enable BGP authentication.
  • Distributed (Transit Gateway plan). No BGP and no Edge uplinks: plan the external VLAN (every ESX host in the domain must attach to it) and its gateway CIDR, the routable external IP block for north-south NAT/SNAT and load-balancer VIPs, the private transit-gateway block (9.1: must be a /16 — a /24 worked in 9.0 and never completes in 9.1), the VNA appliance FQDNs + IPs (2 minimum for HA, on the ESX Management subnet), and whether default outbound NAT is enabled. Routing is the fabric’s job here — there is no Tier-0, so the physical network must route the external VLAN and advertise the external IP block.
  • Acceptance: Centralized — Edge AS, ToR AS, peer IPs, BFD, and advertised/received routes agreed and documented with the fabric team. (BGP MD5 is optional — capture a password only if authentication is enabled; VCF/NSX requires just the neighbor IP + remote AS.) Distributed — external VLAN + gateway CIDR, external IP block, private transit block (/16), and the VNA FQDNs/IPs agreed with the fabric team, with written confirmation that the fabric routes the external VLAN and advertises the external IP block — the same gate BGP gets under Centralized.
• Story 1.3 — DNS & NTP records. All A + PTR records created; NTP sources confirmed.
  • Acceptance: forward (A) + reverse (PTR) records created for every planned appliance FQDN and resolving both ways; NTP sources reachable and serving.
• Story 1.4 — Certificates. CA type (Microsoft CA or OpenSSL; external CA is CSR-based only — VCF won’t import an externally-created cert+key), template, and signing approach decided.
  • Acceptance: CA reachable; signing method and certificate template chosen, with a test issuance succeeding.

E2 — Intake & sizing · Owner: Architect + all role teams

Ref: 02-intake.md · 04-sizing.md

• Story 2.1 — Role-based intake complete. Sections A–F answered by their owners.
  • Acceptance: every intake question answered or explicitly marked N/A by its owner.
• Story 2.2 — Sizing & host fit. Run the sizing calculator; confirm the fleet fits the proposed hosts at N-1.
  • Acceptance: sizing fit-check passes at N-1 (or hosts adjusted); sizing signed off by the architect.

E3 — Workbook & deployment-JSON prep · Owner: Architect + Platform

Ref: workbook-cell-mapping.md

• Story 3.1 — Fill the P&P workbook. Transfer intake answers into the official workbook — or use Coscia’s VCF Planner for an easier fillable form (live VLAN/IP/CIDR validation) that also doubles as an as-built record, with JSON/Markdown/CSV export.
  • Acceptance: workbook complete with no red validation warnings (or the equivalent complete in Coscia’s Planner).
• Story 3.2 — Generate the deployment JSON. Produce the bring-up JSON (e.g. VCF.JSONGenerator) from the filled workbook.
  • Acceptance: deployment JSON generated, schema-valid, and reviewed against the plan.

E4 — Prerequisites & readiness gate · Owner: Architect + infrastructure teams

Ref: prerequisites.md

The final go/no-go before bring-up — it verifies everything the plan (E1–E3) called for has actually been built. Runs in parallel with E1–E3; must be all-green before E5.

• Story 4.1 — Hardware ready. Hosts on the VCG, matched spec, BOM confirmed. Ref: Preparing ESX Hosts for VCF.
  • Confirm CPU/RAM/storage per host against the sizing output (E2).
  • Principal storage (choice: vSAN ESA / vSAN OSA / NFS / VMFS-on-FC) — pick it in the export tool; it adapts these prereqs and the E5 bring-up. vSAN ESA wants all-flash NVMe + 25 GbE; NFS/FC need external storage + the storage network (no local vSAN disks).
  • Acceptance: all hosts on the Broadcom compatibility guide, identical spec; host count meets the cluster minimum (with an even per-AZ split if the cluster will be stretched).
• Story 4.2 — Physical network ready. VLANs, MTU, and the north-south fabric provisioned — which fabric work depends on the connectivity model chosen in story 1.2.
  • Trunk the required VLANs to host uplinks; set MTU 9000 on jumbo networks.
  • Centralized: configure the ToR BGP fabric (AS numbers, peer IPs) for the NSX edges.
  • Distributed: trunk the external VLAN to every ESX host in the domain (not just to an edge pair — there are no Edge VMs), configure its gateway SVI on the ToRs, and advertise the external IP block upstream. Because there is no Tier-0, the physical fabric performs the routing NSX would otherwise do — so this is a hard gate, not a follow-up.
  • Acceptance: required VLANs trunked with MTU 9000 on the jumbo networks; Centralized — ToR BGP fabric up; Distributed — the external VLAN reaches every host in the domain, its gateway answers, and the external IP block is reachable from upstream. All verified against the network plan (E1).
• Story 4.3 — Core services ready. AD, DNS, NTP, CA, depot reachable (open the firewall flows — see 07-firewall-ports.md).
  • Acceptance: forward (A) and reverse (PTR) DNS resolves both ways for every management/fleet FQDN — ESXi hosts, vCenter, SDDC Manager, NSX Manager VIP + the 3 nodes, the NSX Edge nodes (Centralized) or the VNA appliances (Distributed) — a domain has one or the other, VCF Operations nodes (+ optional external LB VIP), Cloud Proxy, License Server, and the VCF Management Services FQDNs (fleet components, instance components, identity broker, services runtime — all deployed at bring-up), and any Day-2 fleet appliances (Automation, Log Management; plus the Avi controller nodes + VIP if the Avi LB is in scope); NTP in sync; CA reachable; depot/binaries staged.
• Story 4.4 — Access & final readiness. A jump/bastion host reaches the management network, and out-of-band (iDRAC / iLO / BMC) access to the hosts is available.
  • Acceptance: the build team can reach the management network and host consoles; and the full prerequisites checklist (prerequisites.md — hardware, network, AD, DNS, NTP, CA, depot) is green before bring-up starts.

E5 — Management domain bring-up · Owner: Platform

• Story 5.1 — Install & configure the management hosts. Image each host with the supported ESXi ISO (see the VCFHostPreparation repo to prep + commission hosts quickly); set the management VMkernel (IP / gateway / VLAN), DNS, NTP, and root password; confirm the ESXi build matches the BOM. Ref: Preparing ESX Hosts for VCF.
  • Guide: 11-esx-coredump.md
  • Acceptance: every host reachable on the management network with the matched ESXi build; DNS + NTP correct.
• Story 5.2 — Stage the VCF Installer. Deploy the Installer on a management-domain host using the IP + FQDN planned for SDDC Manager (it switches into SDDC Manager at bring-up — not a throwaway IP); verify it reaches the ESXi management network. Ref: Deploy the VCF Installer Appliance.
  • Guide: 09-binary-depot.md
  • Running the Installer outside the management domain is also supported — the wizard then deploys a separate, new SDDC Manager appliance and asks for its FQDN (“The VCF Installer appliance is not deployed on one of the hosts in the management domain. During the deployment process, a new SDDC Manager appliance will be deployed.”). Plan the extra FQDN + IP if you take that route; on the host-resident route the SDDC Manager FQDN is not asked again.
  • On that host, put the Installer on a port group carrying the VM Management VLAN. A fresh ESXi host’s default VM Network port group is untagged (VLAN 0), so if VM Management is a tagged VLAN, set the VLAN ID on it (or use a tagged port group) first — otherwise the appliance has no management connectivity.
  • Acceptance: VCF Installer deployed on the VM-Management VLAN, resolves in DNS on the planned SDDC Manager FQDN, and reaches the ESXi management network.
• Story 5.3 — Deploy the management domain. Run bring-up: the Installer validates the prepared hosts, then works through its milestones — deploy vCenter → deploy SDDC Manager → configure the vSphere cluster → deploy & configure NSX → VCF Management Platform (VCF Operations) → operations appliance → VCF Management Services. Plan ~4–6 hours for the run. On the Review page, download the JSON spec — it can be edited and re-uploaded from the Installer homepage for repeatable/automated runs. Ref: Start a New VCF Fleet Deployment by Using the VCF Installer Deployment Wizard.
  • VCF Operations is deployed at bring-up in VCF 9.1 — not Day-2. Only VCF Automation can be deferred indefinitely (Existing Component screen: “I have an existing VCF Automation instance, or I will deploy later”). VCF Operations can be deferred only short-term for custom network placement: the Management Components Custom Networking toggle (Network Options → Customize) defers VCF Operations + Automation — along with their cloud proxy and license server — until you run the wizard’s third deployment path, Deploy deferred components, onto the prepared vDS / NSX segment.
  • Decide up front whether an external load-balancer VIP fronts the cluster (optional — without one you reach the cluster via the node FQDNs; there is no built-in cluster/floating IP) — VCF never provides the LB for Operations, so provision an external LB and add its FQDN to the cert SAN first if you want a VIP.
  • The Installer warns (soft-stop) when the hosts leave less than 20% resource headroom over the deployment’s requirement, and it auto-generates all component passwords — capture them via Review Passwords during/after the deploy.
  • Acceptance: bring-up completes; vCenter, SDDC Manager, NSX, and VCF Operations healthy; vSAN datastore online; auto-generated component passwords captured in the password vault.
• Story 5.4 — Verify VCF Management Services, License Server & Cloud Proxy. These are part of the automatic bring-up in VCF 9.1 — the Installer deploys VCF Management Services (VCF services runtime, identity broker, fleet & SDDC lifecycle, software depot, telemetry) with the instance, a unified Cloud Proxy is “configured by default by the VCF Installer”, and a License Server is “automatically deployed as part of the installation”. So plan their FQDNs/IPs before bring-up, and after bring-up verify them in VCF Operations. (The manual “deploy VCF Management Services and License Server” TechDocs procedure applies to the 9.0 → 9.1 upgrade path only.) Refs: Cloud Proxies in VCF Operations, License Server Overview.
  • The License Server needs a unique FQDN resolving to an IP outside the VCF services-runtime range (IPv4 only). The Cloud Proxy stays on the VM-Management network and needs ports 443 / 4505 / 4506 to VCF Operations (see 07-firewall-ports.md §E). Licenses are applied fleet-wide later (E8 8.5) — within the 90-day evaluation period that starts at bring-up.
  • Acceptance: VCF Management Services + License Server up and healthy after bring-up; the License Server FQDN resolves to an IP outside the services-runtime range; the Cloud Proxy is collecting.

E6 — Management domain configuration · Owner: Platform + Network + Security

• Story 6.1 — NSX north-south connectivity (choice: Centralized or Distributed). Pick the model in the export tool; it writes the right steps.
  • Centralized — deploy the NSX Edge cluster + Tier-0 gateway; establish BGP peering to the ToRs; verify north-south routes. (A stretched Edge is only possible under Centralized — see 03-multi-az-prep.md §D.) Ref: Set up Centralized Connectivity with Edge Clusters.
  • Distributed — the Distributed Transit Gateway (DTGW) distributes routing to the hypervisors (no centralized Edge cluster, no Tier-0, no BGP). Attach the DTGW to the external VLAN planned in 1.2 — the VLAN every ESX host in the domain reaches — with its gateway CIDR routed by the physical fabric, and the routable external IP block advertised upstream. Configure the private transit-gateway block (/16 in 9.1). Then deploy the Virtual Network Appliance (VNA) cluster — 2 appliances minimum for HA, each with an FQDN + static IP on the ESX Management subnet — which is what gives the DTGW its stateful services (NAT/SNAT); enable default outbound NAT against it if planned. A VNA cluster is not a small Edge cluster: no Tier-0 or Tier-1 runs on it. Ref: Set up Distributed Network Connectivity.
  • Acceptance: the chosen model is up — Centralized: Edge cluster + Tier-0 + BGP routes reachable. Distributed: the DTGW is up on the external VLAN, the fabric routes its gateway CIDR and advertises the external IP block, the VNA cluster is healthy on 2+ nodes, and north-south including stateful services (NAT/SNAT) is reachable end to end.
• Story 6.2 — Certificates (optional / partial here). You can replace certificates for the components deployed so far now, but the full CA-signed replacement is usually done once all components exist — after the Day-2 fleet — so the whole fleet is certified in one pass (see E8 story 8.5).
• Story 6.3 — Identity & roles (optional, not recommended at this stage). You can bind vCenter SSO directly to AD/LDAP now for early management access, but the recommended path is fleet-wide SSO via the VCF Identity Broker — already deployed at bring-up with the management services, configured Day-2 (see E8 8.5 / 05-day2-deployments.md). Prefer deferring identity to Day-2; only bind vCenter SSO here if you genuinely need AD admin access before the fleet is up, and map admin/operator/viewer groups if you do.
• Story 6.4 — Backup & lifecycle. Configure SFTP backups — including each vCenter’s file-based backup, set manually in that vCenter’s management interface (VAMI); VCF does not configure it for you (see 08-backup-target.md). Connect the depot for fleet lifecycle (SDDC Manager already has its own depot from bring-up — this is the fleet-wide LCM depot, not a re-do). Ref: File-Based Backups for SDDC Manager, NSX Manager and vCenter.
  • Guide: 08-backup-target.md · 09-binary-depot.md · 13-shutdown-startup.md
  • Acceptance: a test SFTP backup completes — for SDDC Manager and for every vCenter (VAMI schedule set); fleet-lifecycle depot connected. (North-south routing is verified in 6.1; certificates, identity & licensing are finalized Day-2 — see E8 8.5.)

Variant epics (add per scope)

Order runs core config → management stretch (E7) → Day-2 (E8) → workload domains (E9, one per WLD) → handover (E10).

E7 — Stretch the management domain · Owner: Network + Architect + Storage

Ref: 03-multi-az-prep.md · step-by-step runbook: 22-stretch-execution.md

Stretch sequence: inter-AZ fabric → commission second-AZ hosts → witness → stretch (the same order a stretched workload domain follows in E9).

Edge cluster before or after the stretch? Either works — it’s a choice, not a constraint. Stretching a cluster that already hosts the Edge cluster is a first-class path (the stretch spec carries isEdgeClusterConfiguredForMultiAZ for exactly this), and deploying an Edge cluster onto an already-stretched cluster is equally supported — “VMware Cloud Foundation 4.5 and later support deploying an NSX Edge cluster on a vSphere cluster that is stretched”, with new edge nodes placed on AZ1 hosts. This plan’s default order (E6 edges → E7 stretch) simply verifies north-south while the environment is still single-AZ. Either way the stretched Edge Overlay + Uplink networks must exist first (03-multi-az-prep.md §D — Centralized connectivity only).

• Story 7.1 — Inter-AZ fabric. Verify <5 ms RTT, ≥10 Gbps, MTU 9000, HA L3 gateway between AZs.
  • Acceptance: inter-AZ link measured under 5 ms RTT, at least 10 Gbps, MTU 9000 end-to-end; HA L3 gateway between AZs verified.
• Story 7.2 — Build the AZ2 network pool, then install, configure & commission the second-AZ hosts. Broadcom lists these as two separate, ordered prerequisites — create the network pool for AZ2 (vMotion + vSAN VMkernel networks) before commissioning, since the commission call binds each host to a pool by ID. Image the AZ2 hosts with the supported ESXi ISO (see VCFHostPreparation to prep + commission hosts quickly); configure the per-AZ management network (IP / VLAN / gateway), DNS, NTP, and root; then commission them into SDDC Manager, into the AZ2 network pool, ready for the stretch.
  • Acceptance: AZ2 network pool created; AZ2 hosts reachable on their per-AZ management network with the matched ESXi build; commissioned into that pool and available in SDDC Manager.
• Story 7.3 — Witness site (management). Deploy the vSAN witness appliance for the management cluster at the third site (its own — a vSAN witness serves only one stretched cluster); route it to both AZ ESX-management networks. Ref: Deploying a Witness Appliance.
  • Acceptance: management witness appliance deployed at the third site and reachable from both AZ ESX-management networks.
• Story 7.4 — Stretch the cluster. SDDC Manager does the stretch for you — submit a stretch JSON spec via the SDDC Manager API and VCF builds the fault domains (AZ1 preferred / AZ2 secondary / witness), balances hosts across the AZs, and flips the datastore storage policy to site mirroring (stretched, ~2× capacity). You just supply the inputs from 7.1–7.3: an AZ2 network pool, the commissioned AZ2 hosts (equal count per AZ), and the witness. It won’t stretch if the cluster shares a vSAN storage policy with another cluster, has DPU-backed hosts, has L3-different subnets within an AZ, or has vSphere Supervisor enabled (enable Supervisor only after the stretch). If the cluster already hosts an NSX Edge cluster (E6 6.1, Centralized), set isEdgeClusterConfiguredForMultiAZ: true in the stretch spec — wrong, and the edge-specific AZ configuration is skipped. Optionally build the clusterStretchSpec with VCFJsonSpecCreators’s New-VCFvSANStretchSpec.ps1, which assembles, validates, and PATCHes the spec and sets isEdgeClusterConfiguredForMultiAZ for you. Ref: Broadcom — Stretching vSAN Clusters · Stretch a vSAN ESA or OSA Cluster Using the SDDC Manager API · 03-multi-az-prep.md.
  • Acceptance: SDDC Manager reports the cluster stretched; vSAN healthy and storage-policy compliant (site mirroring); isolating one AZ keeps VMs running on the surviving site.

E8 — Day-2 fleet deployment · Owner: Platform

Ref: 05-day2-deployments.md

VCF Operations (+ fleet management, incl. the Identity Broker) is deployed at bring-up (E5 5.3), not here — in VCF 9.1 only VCF Automation can be deferred to Day-N. This epic covers the components you defer or add after bring-up, plus Day-2 configuration of bring-up components (fleet SSO, certificates, licensing).

Licensing can pull this epic in on its own. Ticking vDefend, or any Avi option with Avi licensing = On-prem License Hub, adds the License Hub stories 8.2a / 8.3a, and it does so even with the Day-2 fleet switched off — a Supervisor Avi load balancer on hub licensing needs the hub with no Day-2 work at all. In that case the epic narrows to “Licensing prerequisites (vDefend / Avi)” and carries the hub deployment only. With Avi licensing = Cloud Licensing there is no hub for Avi: each controller registers straight with the Avi Cloud Console instead (story 8.3b, and its E9 counterpart) — “Avi Controllers that cannot run a License Hub can connect and register directly to the Avi Cloud Console” (License Management for Avi Load Balancer). Disconnected / air-gapped sites must use the hub (#374). vDefend itself (the Security Services Platform) is deployed per 18-vdefend-ssp.md.

• Story 8.1 — Network placement. Decide Shared / Dedicated / NSX Overlay / NSX VLAN Segment for the Day-2 components; build the network if non-shared. Ref: Fleet-Level Components Networking Detailed Design · custom-networking deployment guidance.
  • Acceptance: chosen placement built (or the shared network confirmed); the segment/VLAN is reachable and the fleet FQDNs resolve.
• Story 8.2 — VCF Automation. Choices (pick them in the export tool and it writes the exact steps):
  • Guide: 05-day2-deployments.md §D · 17-vcfa-tenant-config.md · 19-securing-vcf-automation.md
  • Deploy it? — VCF Automation is the one fleet component you can defer from bring-up to Day-N.
  • Deployment model — single-node (no load balancer) or an HA cluster (three nodes behind a cluster VIP served by VCF Automation’s built-in load balancer — no external load balancer required; the built-in LB is automatically configured for both models, per the TechDocs design library’s VCF Automation Load Balancing Design).
  • Network placement — Shared Management (nodes come from the mgmt /29, intake B5; simplest, no new network), or a non-shared placement (Dedicated Management / NSX Overlay Segment / NSX VLAN Segment) that builds the network first — see 05-day2-deployments.md §C. The NSX Overlay Segment placement needs an Edge cluster + Tier-0 — under Distributed connectivity (no centralized Edge) deploy one for the fleet segment first, or pick a VLAN-backed placement.
  • Avi in front? — optional; ticking it adds Story 8.3 below.
  • Deploy via SDDC Manager API or via VCF Operations; set the services-runtime cluster CIDR.
  • Acceptance: VCF Automation deployed and healthy; the services-runtime cluster CIDR is set and non-overlapping.
• Story 8.2a — License Hub: deploy and load licences (BEFORE any Avi controller). Added when vDefend is in scope, or Avi is in scope with Avi licensing = On-prem License Hub — License Hub licenses both, and it is its own appliance, outside VCF fleet management entirely (05-day2-deployments.md §B.3). It sits here, ahead of story 8.3, because the hub must exist and hold licences before a controller is built. The steps below are for License Hub 2.0, the current standalone OVA; a site still on 5.1.2 follows the SSP Installer flow in 15-license-hub.md instead, and there is no upgrade path from 5.1.2 to 2.0.
  • Brownfield gate — do this first. If the site already runs Avi on an older version, Avi 32.1.1 deprecates 25-character and YAML licences and gives them a strict 90-day grace period from initial boot / upgrade completion that overrides existing validity dates (licences valid until 2029 still stop). Migrate the entitlement on the Broadcom Support Portal before upgrading — it is one-way. Intake E16a.
  • You download the software yourself: one file, the License Hub 2.0 OVA (~11 GB), from the Broadcom Support Portal — listed under VMware Avi Load Balancer → Primary Downloads, not under vDefend, and not depot-fed, unlike Avi.
  • Addresses and DNS first: three IPs and two FQDNs — the appliance FQDN on its management IP, and a Kafka FQDN that must resolve to the second address of a two-address contiguous IP pool — plus a non-routable internal cluster CIDR of at least 512 addresses (the default 10.10.0.0/16 is fine unless the datacenter already uses it). FQDNs and IPs cannot be changed after deployment (License Hub Appliance System Requirements).
  • Create the DNS records before powering on. The Kafka FQDN is validated at first boot; a mismatch fails vsx-license-hub-deploy.service and no License Hub instance is created (15-license-hub.md).
  • Deploy the OVA: 6 vCPU / 12 GB / 256 GB on a DRS-enabled cluster with shared storage; 15–128 character passwords; max 3 DNS servers. Confirm the deployment at https://<fqdn>:5480 → Infrastructure → License Hub Configuration, then open the License Hub service at https://<fqdn> (FQDN only).
  • Raise the NSX DFW exclusion for the License Hub VM with the vDefend policy owner — a policy carve-out, not a firewall rule (07-firewall-ports.md §E).
  • Register, then load licences — registration brings no entitlement: download the licence file from the Avi Cloud Console (portal.pulse.broadcom.com, outbound 443, not on Broadcom’s Public URLs list) and add it under Licenses. Both connected and disconnected modes need a Broadcom customer account — name who holds it.
  • Configure backup in the License Hub service (Backup and Restore): the SFTP target, its SSH public host key and an encryption passphrase, then run one. It holds endpoints, licence assignments, usage reports and platform configuration — not the licences or the Avi Cloud Console registration — and a restore goes to a new appliance of the same version deployed with the same FQDN, Kafka FQDN, management IP and IP pool (Back Up and Restore).
  • Acceptance: License Hub appliance deployed and its instance shown as deployed under License Hub Configuration; the hub registered and showing licences loaded (not an empty list); backup configured and proven by a run that shows Completed in Backup History, not by saving the configuration; the backup passphrase and the four deploy values a restore needs are recorded.
• Story 8.3 — Avi Load Balancer in front of VCF Automation (optional). Deploy the Avi controller cluster in the management domain via VCF Operations (lifecycle-managed; its IPs/FQDNs/passwords are captured up front in prerequisites.md → Avi Load Balancer and intake E16/F11), then configure the virtual service in front of VCF Automation. An external LB is an optional post-deployment addition — its pool points at the cluster VIP of Automation’s built-in load balancer, which stays the ingress. The built-in LB is L4-only, so Avi in front is what adds SSL termination and keeps user/tenant access off the management network. Ref: Deploy Avi Load Balancer from VCF Operations.
  • Guide: 14-avi-load-balancer.md
  • Licensing is its own story. Avi is licensed either through License Hub — not the License Server from bring-up (story 5.4); the two coexist — or through Cloud Licensing straight to the Avi Cloud Console. On the hub route the hub is deployed in story 8.2a above and the controller is licensed in story 8.3a below; on Cloud Licensing it is story 8.3b: prerequisites.md → License Hub, intake E16a / E17.
  • The controller’s own first-login wizard follows the deploy and asks for things nothing on the VCF side collects: a Passphrase (a third secret, restore-critical — it protects the controller’s configuration backups), the controller’s DNS resolvers + search domain, an SMTP choice that defaults to None, and the multi-tenancy model (Service Engines provider-shared vs per-tenant) — an architecture decision best made before first login.
  • Acceptance: Avi controller cluster healthy; its first-login wizard completed with the passphrase captured alongside the other credentials; the virtual service fronts VCF Automation and its published FQDN resolves to the Avi VIP.
• Story 8.3a — License Hub: onboard the Avi controller and assign licences. The controller exists now, so it can be licensed — and it does not discover the hub.
  • Onboard it in Endpoint Management → Onboard an Endpoint: type, endpoint name, connection type, the cluster IP/VIP/FQDN, plus that endpoint’s admin credential and its certificate — the hub logs in to it.
  • Assign licences to the endpoint, then switch the controller to On-prem License Hub (Administration → Licensing).
  • Verify LICENSE USAGE, not the connectivity status. Connected with a fresh refresh timestamp still reads 0 Used / 0 Available if no licence file was loaded — a green indicator is not evidence of a licensed fleet.
  • Acceptance: the controller listed as an endpoint with licences assigned; On-prem License Hub connected and a non-zero licence count under LICENSE USAGE.
• Story 8.3b — Avi Cloud Licensing: register the controller with the Avi Cloud Console (instead of 8.2a / 8.3a, when Avi licensing is Cloud Licensing and vDefend doesn’t need the hub anyway). No License Hub on this route.
  • Outbound path first: the controller (directly or through its proxy setting) reaches portal.pulse.broadcom.com on 443. It is not on Broadcom’s Public URLs list, so an allowlist built from that page misses it. A site that can’t reach it needs the hub instead.
  • Brownfield gate as in 8.2a: legacy 25-character / YAML licences get a 90-day grace on 32.1.1 — upgrade the entitlement first (intake E16a).
  • Register under Administration → Licensing → Cloud Licensing with the Broadcom customer account (name who holds it). Usage is reported while connected; licences come in 180-day increments unlocked by that usage data, so the path must stay open.
  • Acceptance: the controller on Cloud Licensing and a non-zero licence count under LICENSE USAGE; portal.pulse.broadcom.com in the firewall / proxy allowlist.
• Story 8.4 — Optional fleet components. Deploy the remaining fleet components as needed: Log Management and VCF Operations for Networks. Each is individually selectable in the export tool — the generated story lists only the selected ones. (The Identity Broker is not deployed here — it arrives at bring-up with the management services; whether to use it for fleet SSO is the 8.5 choice, and if broker-based fleet SSO is out of scope, E6 6.3 becomes the identity path.)
  • With Log Management: forward SDDC Manager’s own logs by hand. This isn’t automated in VCF 9.0/9.1. Open TCP 9543 from SDDC Manager to Log Management, then run the deploy_vcf_ops_logs_agent.sh script from KB 396643 as root on SDDC Manager, checking the certificate it asks you to trust. The agent pins that certificate, so re-run the script after 8.5 replaces the Log Management certificate. Details and caveats: 05-day2-deployments.md §B.6.
  • Guide: 05-day2-deployments.md → B. The deployable set · with Log Management: 31-log-management.md
  • Acceptance: each selected Day-2 component healthy; the fleet-management health (synthetic) check passes; with Log Management, SDDC Manager logs arrive there (vcf_component tags such as lcm and domainmanager).
• Story 8.5 — Certificates, identity & licensing (full fleet). Now that all components exist, do the full CA-signed certificate replacement across the whole fleet — select components in bulk and work through Generate CSRs → sign → Replace With Configured CA Certificate, but in staggered batches: each rotation triggers automated retrust across dependent components, and the UI requires you to acknowledge that you will let one batch finish before starting the next (see prerequisites.md → Certificate Authority). Budget settling time between batches rather than a single sweeping action. Then complete fleet SSO via the VCF Identity Broker (configuration, not deployment — the broker has been running since bring-up; this is the recommended identity path, deferred from E6 6.3 — prep the AD/LDAP identity source and its gotchas first: prerequisites.md → Identity source for the VCF Identity Broker; the actual configuration — identity provider, per-product federation, role mapping — is 12-sso-configuration.md), and apply licensing across the fleet (via VCF Operations). Ref: Configure a Certificate Authority · Configure an Identity Provider.
  • Guide: prerequisites.md → Certificate authority · 12-sso-configuration.md
  • Acceptance: every fleet endpoint presents a CA-signed cert with no trust warnings; AD/LDAP SSO via the Identity Broker works; licensing applied.

E9 — Workload domain · Owner: Platform + Network (+ Storage if stretched)

Ref: 02-intake.md section H · step-by-step runbook: 23-workload-domain-creation.md (+ 03-multi-az-prep.md and 22-stretch-execution.md if stretched)

Repeat this epic per workload domain. Each WLD is independently non-stretched or stretched — a stretched WLD gets its own second-AZ hosts and its own vSAN witness (a witness serves only one stretched cluster, so each has a dedicated one; shared-witness is 2-node-cluster only, not stretched), and follows the same hosts → witness → stretch order as the management stretch (E7). A stretched WLD also requires the management domain to be stretched first (E7).

NSX connectivity is per workload domain (intake H4) — Centralized (this domain’s Edge cluster + Tier-0 + BGP) or Distributed (Distributed Transit Gateway + VNA cluster) — and is chosen independently of the management domain’s model, so the export tool asks it per WLD. It drives the WLD connectivity story (9.4 / 9.6 below).

GPU hosts (optional, per WLD): pick the domain’s GPU use in the export tool (intake H13): No GPUs, GPU for VMs (plain vGPU or passthrough), or Private AI Foundation. Either GPU choice changes two things:

• The host story (9.2) gains a task: confirm each GPU on both the Broadcom Compatibility Guide (ESXi 9.1, in the chosen mode) and NVIDIA’s vGPU support matrix (a release with a VCF 9.1 package), enable SR-IOV in the BIOS for vGPU, and build a vSphere Lifecycle Manager image with the NVIDIA host driver in vCenter and import it into the VCF Instance (VCF Operations → Build → Lifecycle → Image Management → Import Image) before the domain is deployed (9.3), so the image can be selected there.
• A GPU hosts: configure vGPU / passthrough story is appended after the connectivity story (and ahead of any Supervisor stories): set each GPU to Shared Direct (vGPU) or Fixed / Dynamic DirectPath (passthrough) per host, enable MIG if planned, set vgpu.hotmigrate.enabled on the domain’s vCenter, stand up the NVIDIA License System and the guests’ client token, and — if Private AI Foundation is in scope — assign its add-on licence to the domain. Acceptance: every GPU host compliant with the GPU image, nvidia-smi lists all GPUs, devices in the planned mode, and a test vGPU VM powers on, gets an NVIDIA licence and vMotions between two GPU hosts. With GPU for VMs it also adds the vGPU profile / DirectPath device and the guest driver to the VM templates.

Private AI Foundation puts the 3-GPU-host minimum on the host story, switches Supervisor on for that domain (PAIF runs on it), and asks connected or disconnected (dark site). Its stories follow the Supervisor stories, in this order (guide: 33-private-ai-foundation.md):

• Private AI Foundation: licence, SSO and vCenter Linking — connect the domain’s vCenter and NSX Manager to the VCF Identity Broker, add its vCenter to the management vCenter’s vCenter Linking group (the add-on licence capacity is only allocated once they’re linked), and assign the add-on licence to the domain (to the management domain too only for the guided vSphere Client workflow). Acceptance: the domain’s vCenter + NSX on fleet SSO, vCenter linked, add-on licence assigned.
• Private AI Foundation: NVIDIA licensing and access — a cloud License Service instance (connected) or the on-site DLS appliance (dark site), the client configuration token, an NGC API key.
• Dark site only — dark-site staging infrastructure: first the outside staging (the hard part in the field: every image is prepared and hosted outside before it crosses the gap, and it’s a lot of data — size the storage and time a test transfer early), then bastion + admin hosts, a web server with the Ubuntu mirror (≥ 800 GB) and the guest drivers with their index files, the bastion allowlist, an owner and refresh routine per artifact.
• VM classes and GPU reservations — DirectPath profiles, VM classes, reserved VM classes per zone, one host of GPU capacity left free.
• Harbor and content libraries — the platform Harbor (VCF Automation’s Harbor service, or the Harbor Supervisor Service) with its projects and robot account; the Ubuntu VKr library (dark site: subscribed to your own depot) and the deep learning VM library (dark site: local, from the .ova).
• Dark site only — mirror the artifacts — the resource mirroring utility (KB 388470) for the GPU Operator and DL containers, and the Ubuntu index file into Harbor.
• VCF Automation organization and catalog items — All Apps org on VPC networking, region + region quota with the reserved VM classes, project + namespace, then the Private AI Foundation Quickstart (9.1.1 blueprint swap to deep-learning-container; GPU Operator v25.3.1 → v26.3.1, KB 439984).
• Private AI Services (if used) — Data Services Manager, an OIDC provider (not VCF SSO), the install source (dark site: separately distributed package through the artifact mirroring tool), install on the Supervisor, activate per namespace.

Guide: 32-gpu-hosts.md; prerequisites: prerequisites.md → GPU hosts. Like the Avi stories below, the GPU and Private AI Foundation stories are numbered by selection.

vSphere Supervisor (optional, per WLD): tick Supervisor in the export tool to add an Enable vSphere Supervisor story to that WLD. Activation requires that domain’s north-south connectivity to already be up, so with Supervisor enabled the WLD connectivity story becomes an explicit prerequisite and also carries the Supervisor-specific reservations — Centralized: the Edge cluster + Tier-0 plus the Supervisor ingress / egress CIDRs; Distributed: the Transit Gateway + VNA plus the routable external IP block and the /16 private transit-gateway block (9.1). Activation also needs a load balancer, chosen per WLD in the export tool:

• Built-in NSX/VPC LB (default) — the NSX / VPC networking paths bring their own load balancer; no extra appliance.

• Foundation Load Balancer — the platform-packaged lightweight L4 LB (one or two VMs in an active/passive pair) for Supervisors on VDS networking; adds a deploy step to the enablement story.

• Avi Load Balancer — the premium option on every networking stack; choosing it adds its own story ahead of the enablement: deploy the controller cluster into the management domain — controllers always live there, never in the workload domain, and a set is scoped to the NSX instance, so a WLD sharing an existing NSX instance reuses that set rather than getting a new one — via VCF Operations (lifecycle-managed; Avi 32.1.1+ binaries must be in the depot; controller IPs/FQDN/passwords per prerequisites.md → Avi Load Balancer and intake E16/F11; a local content library for the Service Engine images), then the networking integration — the cloud connector (NSX Cloud with VPC mode under Distributed/VPC: SE management on an overlay segment behind a Tier-1 with DHCP, VIPs from the VPC external IP blocks; NSX Cloud, or a vCenter cloud for VDS networking, otherwise: SE management on a VLAN or overlay segment, VIP network + IPAM profile) and the Service Engines, which run per cluster in the workload domain (minimum 2 per cluster for HA). Avi then needs licensing, by one of two routes. On-prem License Hub (separate from bring-up’s License Server, they coexist — prerequisites.md → License Hub, intake E17): the hub is deployed back in E8 story 8.2a, ahead of this controller, and this controller then gets its own onboarding story in this epic: onboard it as an endpoint (admin credential and certificate), assign licences, and switch it to On-prem License Hub, which it does not do by itself. Cloud Licensing: no hub; the controller gets a story to register directly with the Avi Cloud Console (as in 8.3b). Per the Avi-for-VCF 9.1 requirements, all of it must exist before Supervisor activation. Guides: 14-avi-load-balancer.md (deploy, Service Engine infrastructure, licensing) and 10-supervisor-enablement.md §4.

  The Avi and licensing stories in this epic are numbered by selection — they append after the fixed stories below, so their numbers shift with the variant. They are described here rather than given fixed numbers; the export tool emits them with concrete numbers for the scope you pick.

Plus a control-plane size (Small / Medium / Large). The full prerequisite checklist — 5 consecutive control-plane IPs, API FQDN + DNS, per-path IP blocks (9.1: VPC transit-gateway block must be a /16), DRS/HA, storage policies, Kubernetes content — is in prerequisites.md → vSphere Supervisor.

The Enable vSphere Supervisor story carries creating the vSphere Zones as its own task: they are built in vCenter (vCenter → vSphere Zones → Add New vSphere Zone), one cluster per zone, before activation — the wizard selects zones, it does not create them, and single- vs multi-zone cannot be reversed later. See 10-supervisor-enablement.md §1.3, and for the image registry path 20-supervisor-image-registry.md. Ref: vSphere Supervisor Platform · Requirements for Deploying Avi Load Balancer (VCF 9.1).

Non-stretched WLD:

• Story 9.1 — WLD network prep. Provision the per-WLD VLANs/subnets (Step 1) and the 5 IPs the WLD consumes on the mgmt VM-mgmt subnet.
  • Acceptance: per-WLD VLANs/subnets provisioned; the 5 mgmt-subnet IPs reserved; DNS in place.
• Story 9.2 — Prepare & commission the WLD hosts. Image the WLD hosts with the supported ESXi ISO (see VCFHostPreparation); configure the management network, DNS, NTP; then commission them into SDDC Manager.
  • Acceptance: WLD hosts reachable, matched ESXi build, commissioned in SDDC Manager.
• Story 9.3 — Deploy the WLD. vCenter + NSX (shared or dedicated) + first cluster. Optionally build the domain spec with VCFJsonSpecCreators (New-VCFWorkloadDomain.ps1; New-VCFNetworkPool.ps1 for the domain’s network pool, New-VCFClusterSpec.ps1 to add further clusters), which validates each payload against SDDC Manager before submit.
  • Acceptance: WLD deployed; its vCenter + NSX healthy; first cluster online in SDDC Manager.
• Story 9.4 — WLD connectivity (Centralized / Distributed). Build this domain’s north-south per its own connectivity model (H4) — chosen independently of the management domain’s.
  • Centralized: deploy this domain’s Edge cluster + Tier-0, peer BGP to the ToRs (Edge AS, ToR AS, peer IPs, BFD), verify north-south routes.
  • Distributed: build the Distributed Transit Gateway on this domain’s external VLAN — every ESX host in this domain must attach to it — with its gateway CIDR routed by the fabric and a routable external IP block advertised upstream; configure the private transit block (/16); deploy this domain’s VNA cluster (2+ appliances, FQDN + IP each, ESX Management subnet) for stateful services (NAT/SNAT). These are per-domain inputs — a second Distributed WLD needs its own external VLAN, IP block and VNA cluster, not a share of the management domain’s.
  • With Supervisor enabled this story is its prerequisite and also reserves the Supervisor CIDRs / IP blocks (see the Supervisor note above).
  • Acceptance: WLD healthy in SDDC Manager; north-south reachable — Centralized: Tier-0 + BGP routes; Distributed: DTGW on the external VLAN, fabric routing confirmed, VNA cluster healthy on 2+ nodes, NAT/SNAT working. Workloads can be placed (and, with Supervisor, its connectivity prerequisites are met).

Stretched WLD (multi-AZ set):

• Story 9.1 — WLD network prep (per-AZ). Provision the per-WLD VLANs/subnets across both AZs (per-AZ networks) and the 5 mgmt-subnet IPs.
  • Acceptance: per-WLD VLANs/subnets provisioned across both AZs; the 5 mgmt-subnet IPs reserved; DNS in place.
• Story 9.2 — Build the AZ2 network pool, then prepare & commission the WLD hosts (both AZs). Create the AZ2 network pool (vMotion + vSAN VMkernel networks) before commissioning — the commission call binds each host to a pool by ID. Image the WLD hosts in both AZs (see VCFHostPreparation); configure the per-AZ management networks, DNS, NTP; then commission them into SDDC Manager, into the AZ2 network pool.
  • Acceptance: AZ2 network pool created; WLD hosts in both AZs reachable, matched ESXi build, commissioned into that pool in SDDC Manager.
• Story 9.3 — Deploy the WLD. vCenter + NSX (shared or dedicated) + first cluster. Optionally build the domain spec with VCFJsonSpecCreators (New-VCFWorkloadDomain.ps1; New-VCFNetworkPool.ps1 for the domain’s network pool, New-VCFClusterSpec.ps1 to add further clusters), which validates each payload against SDDC Manager before submit.
  • Acceptance: WLD deployed; its vCenter + NSX healthy; first cluster online in SDDC Manager.
• Story 9.4 — WLD witness. Deploy a dedicated vSAN witness for this WLD at the third site. A witness serves only one stretched cluster, so each stretched WLD needs its own, separate from the management witness (the shared-witness feature is 2-node-cluster only, not stretched). Route it to both AZ ESX-management networks. Ref: Deploying a Witness Appliance.
  • Acceptance: dedicated WLD witness deployed at the third site and reachable from both AZ ESX-management networks.
• Story 9.5 — Stretch the WLD cluster. Same as the management stretch — SDDC Manager stretches it for you from a JSON spec via the API: it builds the fault domains, balances the per-AZ hosts, and sets the site-mirroring storage policy. Supply the AZ2 network pool, the commissioned WLD hosts (equal per AZ), and this WLD’s witness. The management domain must already be stretched (E7) before any workload-domain cluster can be stretched, and the WLD cluster must not have vSphere Supervisor enabled yet — stretch first, enable Supervisor after. Edge stretched only under NSX Centralized connectivity. Optionally build the spec with VCFJsonSpecCreators’s New-VCFvSANStretchSpec.ps1 (set networkProfiles[].isDefault = false for a workload domain — true is the management domain). Ref: Broadcom — Stretching vSAN Clusters.
  • Acceptance: SDDC Manager reports the WLD stretched; vSAN healthy and storage-policy compliant (site mirroring); isolating one AZ keeps VMs running on the surviving site.
• Story 9.6 — WLD connectivity (Centralized / Distributed). As story 9.4 above, for this stretched WLD: build north-south per its own connectivity model (H4), and with Supervisor enabled it is the activation prerequisite (plus the Supervisor CIDRs / IP blocks).
  • Acceptance: WLD healthy in SDDC Manager; north-south reachable; workloads can be placed (and, with Supervisor, its connectivity prerequisites are met).

Final epic (always last)

E10 — Validation & handover · Owner: Architect + all teams

A core epic that always runs after E6 and any variant epics (stretch / Day-2 / workload domains) — it validates and hands over the complete environment.

• Story 10.1 — Health check. Run a post-deploy health check of the live environment.
  • Acceptance: post-deploy health check run; no critical findings (or all triaged).
• Story 10.2 — As-built. Capture the as-built (FQDNs, IPs, VLANs, passwords in the secret store).
  • Guide: 21-config-artifacts.md
  • Acceptance: as-built captured — FQDNs, IPs, VLANs recorded; passwords stored in the secret store.
• Story 10.3 — Handover. Walk the operations team through the platform and hand over.
  • Guide: 13-shutdown-startup.md
  • Acceptance: health check clean; as-built delivered; operations sign-off received.

Using this in your backlog

• Treat E1–E10 as epics, the Story lines as stories, and the bullets under them as tasks; carry the Acceptance line into the story’s acceptance criteria.
• Add the stretch (E7) / Day-2 (E8) blocks and one E9 per workload domain you need (see the scope table up top); order runs core → management stretch → Day-2 → workload domains → handover.
• Sequence is roughly top-to-bottom; E1–E3 are planning (parallelisable across role teams), E4 is the readiness gate (must be all-green before bring-up), E5 onward is the build.
• This page is generic — replace the linked detail pages’ placeholder values with your real plan during E2/E3.