ITQ VCF 9.1 Deployment Planning

Tracker

Deployment Tracker

The execution side of the Deployment Plan Export: the same plan, as a checklist. Tick a story when it is done and the per-epic and overall progress update. The scope follows what you set in the export tool; adjust it there and this page picks it up. Progress is remembered by this browser; use Save progress to keep the tracking file with the engagement (it is customer data: store it with the customer's files, not in a repo) and Load progress to continue on another machine or hand over to a colleague. The saved file carries the scope too, so loading it restores the exact plan. Everything runs in your browser.

Scope: (loading)

Adjust scope in the export tool

Exports here carry the tracking state: the Markdown is a GitHub-flavored task list (- [x] with done dates), and the CSV's Status/Done On columns come from the checkboxes below.

E1 — Network, DNS & routing plan Owner: Network + AD/DNS/NTP 0/4 done

  • 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 0/2 done

  • 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 0/2 done

  • 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 0/4 done

  • 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 0/4 done

  • 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 0/4 done

  • 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 0/4 done

  • 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 0/4 done

  • 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 0/3 done

  • 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. Build the scope and export the backlog on the Deployment Plan Export page.