ITQ VCF 9.1 Deployment Planning

Export tool

Deployment Plan Export

Build your deployment scope below: pick NSX connectivity (Centralized/Distributed) and storage (vSAN ESA/OSA, NFS, FC), stretch the management domain or not, add the Day-2 fleet (with VCF Automation's network placement + an optional Avi load balancer in front as its own story, the optional components Log Management and Operations for Networks each in or out, and fleet SSO via the Identity Broker on or off — the broker itself deploys at bring-up), and optionally add workload domains (zero for a management-only scope), each independently non-stretched or stretched (a stretched domain gets its own hosts and its own vSAN witness). The plan filters to the exact epics and stories, then export it: Copy as Markdown for a wiki or PR, or download a CSV that imports into Jira, Azure DevOps, or GitLab. To tick off stories as you execute, use the separate Deployment Tracker; it follows the scope you set here. Mirrors the Deployment Plan page; everything runs in your browser.

Scope

Core epics (E1–E6, E10) always apply. Add the variants you need. Stretching requires vSAN principal storage (an NFS / FC cluster cannot be vSAN-stretched).

Workload domains

Workload domains are optional: remove them all for a management-only scope. Each one is its own epic (E9…) and picks its own NSX connectivity, independent of the management domain's (intake H4). Tick Stretched for per-AZ host prep + a dedicated witness; it requires the management domain stretched first, so ticking it adds E7 automatically. Tick Supervisor to add the vSphere Supervisor enablement story. Activation requires that domain's north-south connectivity to be in place first, so its connectivity story becomes an explicit prerequisite (Centralized: Edge cluster + Tier-0 + BGP, plus the Supervisor ingress/egress CIDRs; Distributed: Distributed Transit Gateway + VNA, plus the external IP block and the /16 private transit-gateway block). Then pick the Supervisor load balancer: the built-in NSX/VPC LB (default, no extra appliance), the Foundation Load Balancer (platform-packaged L4 pair for VDS networking), or Avi (adds its own story: controller cluster into the domain + cloud connector + Service Engine/VIP networks, all before activation).

Scope: management + Day-2 fleet + 1 workload domain
Epics included: E1–E6, E8, E9, E10

CSV columns: Issue Type, Summary, Parent, Owner, Acceptance Criteria, Reference, Status, Done On: one row per epic, story, and task; Parent references the parent's Summary so the importer can rebuild the hierarchy. From this page every story exports as Open; the Deployment Tracker's exports fill Status/Done On from its checkboxes.

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 — BGP plan.
    • Edge AS, ToR AS, peer IPs, BFD, advertised/received routes — plus an optional MD5 password only if you enable BGP authentication.
    • Acceptance: 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.)
  • 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 will not 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 (https://vcfplanning.lcoscia.fr/) for an easier fillable form with live validation that also doubles as an as-built record (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

  • Story 4.1 — Hardware ready.
    • Hosts on the VCG, matched spec, BOM confirmed. TechDocs: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/deployment/deploying-a-new-vmware-cloud-foundation-or-vmware-vsphere-foundation-private-cloud-/preparing-your-environment/preparing-esx-hosts-for-vmware-cloud-foundation-or-vmware-vsphere-foundation.html
    • Confirm CPU/RAM/storage per host against the sizing output (E2).
    • Storage — vSAN ESA: all-flash NVMe (TLC) capacity, single storage pool; 25 GbE NICs recommended.
    • 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.
    • Trunk the required VLANs to host uplinks; set MTU 9000 on jumbo networks.
    • Configure the ToR BGP fabric (AS numbers, peer IPs) for the NSX edges.
    • Acceptance: Required VLANs trunked with MTU 9000 on the jumbo networks; ToR BGP fabric up; 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, NSX Edge nodes, 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 — https://github.com/pauldiee/VCFHostPreparation — to prep + commission hosts quickly); set the management VMkernel (IP / gateway / VLAN), DNS, NTP, and root password; confirm the ESXi build matches the BOM. TechDocs: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/deployment/deploying-a-new-vmware-cloud-foundation-or-vmware-vsphere-foundation-private-cloud-/preparing-your-environment/preparing-esx-hosts-for-vmware-cloud-foundation-or-vmware-vsphere-foundation.html
    • 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. TechDocs: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/deployment/deploying-a-new-vmware-cloud-foundation-or-vmware-vsphere-foundation-private-cloud-/preparing-your-environment/deploy-the-vmware-cloud-foundation-installer-appliance.html
    • 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. 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 (vSAN ESA datastore), deploy and 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. TechDocs: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/deployment/deploying-a-new-vmware-cloud-foundation-or-vmware-vsphere-foundation-private-cloud-/deploy-a-new-vcf-fleet-or-a-new-vcf-instance.html
    • 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 ESA 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 and 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". 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.)
    • 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). 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 (Centralized connectivity).
    • 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 connectivity — see 03-multi-az-prep.md section D.) TechDocs: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/advanced-network-management/administration-guide/setting-up-network-connectivity/setting-up-centralized-connectivity-with-edge-clusters.html
    • Acceptance: Edge cluster + Tier-0 deployed; BGP peering to the ToRs established; north-south routes advertised and reachable.
  • Story 6.2 — Certificates (optional / partial here).
    • Optional here: you can replace certificates for the components deployed so far, 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 here).
    • Optional and not recommended at this stage: you can bind vCenter SSO directly to AD/LDAP for early management access, but the recommended approach 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, then map admin/operator/viewer groups.
  • 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. 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). TechDocs: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/fleet-management/backup-and-restore-of-cloud-foundation/file-based-backups-for-sddc-manager-and-vcenter-server.html
    • 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.)

E8 — Day-2 fleet deployment Owner: Platform

Ref: 05-day2-deployments.md

  • Story 8.1 — Network placement.
    • Decide Shared / Dedicated / NSX Overlay / NSX VLAN Segment / NSX VPC subnet for the Day-2 components; build the network if non-shared. Note that at Day-N every non-shared placement is API-only — the Add VCF Automation wizard has no network picker (see 05-day2-deployments.md section C). TechDocs: design models — https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/design/design-library/fleet-level-components-networking-detailed-design.html ; deployment guidance — https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/deployment/deploying-a-new-vmware-cloud-foundation-or-vmware-vsphere-foundation-private-cloud-/deploying-vcf-operations-and-vcf-automation-on-custom-networking.html
    • Acceptance: Chosen placement built (or the shared network confirmed); the segment/VLAN/VPC subnet is visible in vCenter, reachable, and the fleet FQDNs resolve.
  • Story 8.2 — VCF Automation (Shared Management Network, small — 1 node).
    • Deploy via SDDC Manager API or via VCF Operations as a small size — single node (Simple model, no load balancer needed). Resizing to medium or large later automatically scales out to 3 nodes. Network placement: Shared Management Network — nodes come from the management /29 (intake B5); simplest, no new network to build (see 05-day2-deployments.md section C). Set the services-runtime cluster CIDR.
    • Have BOTH VCF Automation FQDNs resolving before you start: the Automation appliance FQDN AND Automation's own "VCF services runtime" FQDN (lowercase, A + PTR). This is a second, separate FQDN from the fleet VCF Management Services runtime created at bring-up — TechDocs and the workbook use the identical label for both.
    • Both of those FQDNs must resolve to discrete VM Management IPs that fall OUTSIDE the /29 you enter as the "VCF services runtime nodes CIDR" — the wizard enforces this. Budget the /29 (3 node IPs + 2 buffer, IP-only, no DNS records) PLUS 2 separate IPs for the FQDNs.
    • Acceptance: VCF Automation deployed and healthy (single-node) on the Shared Management Network; services-runtime cluster CIDR set and non-overlapping.
  • Story 8.4 — Optional fleet components: Log Management & VCF Operations for Networks.
    • Deploy the selected optional fleet components: Log Management & VCF Operations for Networks. Each needs its FQDN + reserved IP with forward/reverse DNS in place (see 05-day2-deployments.md section B).
    • Acceptance: Each selected Day-2 component healthy; the fleet-management health (synthetic) check passes.
  • Story 8.5 — Certificates, identity & licensing (full fleet).
    • Now that all components exist, do the full CA-signed certificate replacement across the whole fleet in one pass, 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: see prerequisites.md, Identity source for the VCF Identity Broker), and apply licensing across the fleet (via VCF Operations). TechDocs: configure a CA — https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/fleet-management/certificate-management-9-0/configure-a-certificate-authority_9-0.html ; configure an identity provider — https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/fleet-management/what-is/setting-up-sso/cofigure-vmware-cloud-foundation-identity-provider.html
    • 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: wld01 — Centralized Owner: Platform + Network

Ref: 02-intake.md section H

  • 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 the VCFHostPreparation repo — https://github.com/pauldiee/VCFHostPreparation — to prep + commission hosts quickly); 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.
    • Acceptance: WLD deployed; its vCenter + NSX healthy; first cluster online in SDDC Manager.
  • Story 9.4 — WLD connectivity (Centralized).
    • Centralized connectivity — deploy this domain's NSX Edge cluster + Tier-0 gateway, peer BGP to the ToRs (Edge AS, ToR AS, peer IPs, BFD), and verify north-south routes. TechDocs: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/advanced-network-management/administration-guide/setting-up-network-connectivity/setting-up-centralized-connectivity-with-edge-clusters.html
    • Acceptance: WLD healthy in SDDC Manager; north-south reachable — Tier-0 + BGP routes advertised and reachable; workloads can be placed.

E10 — Validation & handover Owner: Architect + all teams

  • 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).
    • 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.
    • Acceptance: Health check clean; as-built delivered; operations sign-off received.

Source of truth: docs/06-deployment-plan.md. Host imaging + commissioning helper: VCFHostPreparation. The CSV is a generic hierarchical import; map the columns to your tool's fields on import.