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 + optional Avi load balancer, and the optional components Log Management, Operations for Networks, and Identity Broker each in or out), 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. 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…). 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 (needs connectivity + a load balancer first; Avi is one LB option).

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: one row per epic, story, and task; Parent references the parent's Summary so the importer can rebuild the hierarchy.

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 (and any Day-2 fleet appliances: VCF Operations, Automation, Logs, Identity Broker; 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
    • 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 builds vCenter, SDDC Manager, NSX, VCF Operations, and the vSAN ESA datastore; submit the JSON. 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). Decide its cluster address up front: floating IP (default) or an external load-balancer VIP — 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.
    • Acceptance: Bring-up completes; vCenter, SDDC Manager, NSX, and VCF Operations healthy; vSAN ESA datastore online.
  • Story 5.4 — Deploy VCF Management Services, License Server & Cloud Proxy.
    • These are NOT part of the automatic bring-up. Once VCF Operations + SDDC Manager are up, deploy them via VCF Operations (its UI, or the SDDC Manager API for custom VLAN-backed placement to avoid IP exhaustion): VCF Management Services (VCF services runtime, fleet and SDDC lifecycle, software depot, telemetry), the License Server, and the Cloud Proxy collector as needed.
    • 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.4).
    • Acceptance: VCF Management Services + License Server deployed and healthy; the License Server FQDN resolves to an IP outside the services-runtime range; Cloud Proxy (if used) 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.4).
  • 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 (a Day-2 component; see E8 / 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.4.)

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 for the Day-2 components; build the network if non-shared. 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 is reachable and the fleet FQDNs resolve.
  • Story 8.2 — VCF Automation (Shared Management Network).
    • Deploy via SDDC Manager API or via VCF Operations as a single-node (no load balancer needed). 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.
    • Acceptance: VCF Automation deployed and healthy (single-node) on the Shared Management Network; services-runtime cluster CIDR set and non-overlapping.
  • Story 8.3 — Optional fleet components: Log Management, VCF Operations for Networks & Identity Broker.
    • Deploy the selected optional fleet components: Log Management, VCF Operations for Networks & Identity Broker. 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.4 — 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 (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 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 connectivity — NSX Edges / uplinks (Tier-0 + BGP).
    • Acceptance: WLD healthy in SDDC Manager; north-south 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.