Deployment Plan Export

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

Guides: Network / DNS / NTP / AD plan

• 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.
  • Guide: Network plan: VLAN / subnet
• 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.)
  • Guide: Network plan: north-south connectivity
• 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.
  • Guide: Network plan: DNS · Network plan: NTP
• 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.
  • Guide: Network plan: certificates · Prerequisites: certificate authority

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

Guides: Intake questionnaire · Sizing

• 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.
  • Guide: Intake questionnaire
• 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.
  • Guide: Management domain sizer · Sizing

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

Guides: Workbook cell mapping

• 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).
  • Guide: Workbook cell mapping
• 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

Guides: Prerequisites gate

• 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).
  • Guide: Prerequisites: hardware · Prerequisites: principal storage · Management domain sizer
• 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).
  • Guide: Prerequisites: network · Network plan: north-south connectivity
• 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.
  • Guide: Firewall ports · Network plan: DNS · Prerequisites: certificate authority · SFTP backup target · Binary depot
• 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.
  • Guide: Prerequisites: jump host · Prerequisites: sign-off

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.
  • Guide: ESX coredump / Dump Collector
• 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.
  • Guide: Binary depot
• 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.
  • Guide: Workbook cell mapping
• 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.
  • Guide: Prerequisites: VCF licensing (License Server) · Firewall ports

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.
  • Guide: Network plan: north-south connectivity
• 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).
  • Guide: Prerequisites: certificate authority
• 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.
  • Guide: Prerequisites: Active Directory · Fleet SSO (VCF Identity Broker)
• 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.)
  • Guide: SFTP backup target · Binary depot · Shutdown and startup runbook

E8 — Day-2 fleet deployment Owner: Platform

Guides: Day-2 deployments

• 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.
  • Guide: Day-2: network placement
• 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.
  • Guide: Day-2: VCF Automation deployment method · VCF Automation first-time tenant configuration · Securing external-facing VCF Automation
• 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).
  • Forward SDDC Manager's own logs to Log Management: this is not 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 Broadcom KB 396643 as root on SDDC Manager, checking the certificate it asks you to trust (see 05-day2-deployments.md section B.6). Re-run it after Story 8.5 replaces the Log Management certificate. KB: https://knowledge.broadcom.com/external/article/396643/deploy-and-configure-vcf-operations-for.html
  • Acceptance: Each selected Day-2 component healthy; the fleet-management health (synthetic) check passes. SDDC Manager logs arrive in Log Management (vcf_component tags such as lcm and domainmanager).
  • Guide: Day-2: the deployable set · Log Management: getting logs in
• 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 run it in staggered batches: each rotation triggers automated retrust across dependent components, and the UI makes you acknowledge that one batch must finish before the next starts — budget settling time between batches. The replace step reuses the LAST generated CSRs, so regenerate if a SAN or FQDN changed. 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: 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, with each rotation batch completed and settled before the next was started; AD/LDAP SSO via the Identity Broker works; licensing applied.
  • Guide: Prerequisites: certificate authority · Fleet SSO (VCF Identity Broker)

E9 — Workload domain: wld01 — Centralized Owner: Platform + Network

Guides: Intake: workload domain / cluster · Workload domain creation runbook

• 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.
  • Guide: WLD runbook: network prep
• 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.
  • Guide: WLD runbook: commission the hosts
• 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.
  • Guide: WLD runbook: create the domain
• 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.
  • Guide: Network plan: north-south connectivity

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).
  • Guide: Test plan
• 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.
  • Guide: Capturing configuration artifacts
• 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.
  • Guide: Shutdown and startup runbook