VCF 9.1.1 Lab Rebuild
A follow-along guide to rebuilding my VCF lab on 9.1.1, published page by page as the build happens.
📘 Official documentation. This is a lab walkthrough, not a replacement for the vendor docs. For the authoritative, supported procedures, follow Broadcom’s VMware Cloud Foundation 9.1 documentation. Where this guide and the official docs differ, the official docs win.
I am rebuilding my VCF lab on 9.1.1. This guide follows that build, step by step, so you can follow along with your own.
This guide is published live
The guide is not finished, and it is not written after the fact. Each page goes up as the build reaches that stage. Pages will be added, reordered and corrected while the build is running. If a page is not in the list below, the build has not got there yet.
When the build is complete, this guide becomes the 9.1.1 rebuild guide and replaces the VCF 9.1 lab series.
Who writes it
The build, the design choices and the screenshots are mine. Most of the writing is done by Claude, Anthropic’s AI model. It works from my build notes, my screenshots and my direction, and it checks the steps against the product documentation. I am stating that here so it is clear how the guide is produced.
How to read it
- Every step says where you are. Which system, and which part of it — for example the stage of the VCF Installer wizard, or the application a setting lives in.
- Lab services are named by what they are. The lab runs services that are not part of VCF, such as an identity provider, a secrets store, NetBox and a NAS. Each one is introduced with what it is and what it does in the lab. You will need your own equivalent; the guide says what it has to provide.
- References are cited. Each section points to the design decision, recommendation or requirement it rests on, with the document, version and page. Where the lab does something different from the recommendation, the page says so and gives the reason.
- The scripts are public. Where a page uses one of my build scripts, it links to it in pgnet-vcflab, with a made-up inventory so you can run it. That repo is lab-only, unsupported, personal work, and not endorsed by Broadcom.
- Salt is described, not shown. I automate a lot of the lab with Salt. Where a step uses it, the guide explains what the automation does. The Salt code will be published separately later.
- Patterns explain the why. Where I do something a particular way across the lab, the pattern is explained once, with a diagram, and linked from the steps that use it.
- No passwords. Credentials are never shown. IP addresses, VLAN IDs and VCF component names are the real ones from the lab, so the steps and the screenshots match.
Pages
Pages are listed here as they are published.
| Page | What it covers |
|---|---|
| The Hardware | The eight ESX hosts, fleet totals, memory per host, and what the hardware rules in and out. |
| Kickstart: One USB Key, Eight Hosts | The ESX 9.1.1 install: a kickstart generated from the inventory, a root password that never sits in a kept file, and the lab-only settings for consumer AMD hardware. Includes what the first build found: a driver install that fails silently on 9.1.1, and the fix. |
| Networks, Names and Addresses | The reference page: five VLANs, three DNS zones, sixteen component names, the node ranges that must hold no names, and how it was proven. Keep it open in another tab. |
| The VCF Installer: Drive It from JSON, Check It in the Wizard | From first login to pressing Deploy: the Plan choices that make the build distributed, two validation runs, and the one network a green validation does not test. |
| Bring-Up: Five and a Half Hours, 320 Subtasks | What happens after Deploy is pressed: eight milestones, nothing failed, the interruption that is not a failure, and what the instance could not yet do. |
| Distributed Connectivity: What the Physical Network Owes the Instance | The half of distributed VPC connectivity that lives on the gateway and the switch: six requirements the Installer never checks, and a check for each. |
| The VNA Cluster: Where Stateful Services Live When There Is No Edge | A distributed transit gateway holds no state, so NAT, Auto-SNAT, DHCP relay and the load balancer move to a VNA cluster. The dependencies, the deployment, and a VPC used to measure the data path. |
| The Second Cluster, As Built | Four Intel hosts on NFS, built directly in the management vCenter and not managed by SDDC Manager — what exists, what that limits, why SDDC Manager could not build it, and the plan to rebuild it. |
| Attaching the Second Cluster to NSX | NSX host preparation from vCenter, with the five inputs SDDC Manager would have supplied entered by hand. A second tunnel endpoint on an uplink with no NIC, and packet loss from one host traced to a switch-port setting. |
| Avi Load Balancer: One Controller, NSX Cloud in VPC Mode | Deploying Avi and finishing its NSX cloud, so a Supervisor activated afterwards gets it automatically. Do this before the Supervisor. |
| Two Supervisors on VPC Networking | One Supervisor per cluster, each API answering on a DNS name through Avi, with every external address allocated by NSX. |