Deep Dive of the Day Bringing up VCF 9.1.1 as code: the Installer's JSON spec, vcf_instance and the SDKs
If you rebuild labs often, or want your production bring-up to be repeatable and reviewable, the first thing to understand about VCF 9.1 is that everything starts with the VCF Installer. TechDocs lists three prerequisites before any deployment: prepare the ESX hosts, deploy the VCF Installer appliance, and download the component binaries to it, ideally the latest ones. Every automation route, whether it's the wizard, a JSON file, Terraform or an SDK, ends up handing the Installer the same description of your instance.
That description is the JSON specification, and the easiest way to get a correct one is to let the wizard write it. Per the deployment wizard page, you can download a JSON template once you've chosen components, the deployment model, network and storage, and again at the review step. You can then edit the file and upload it from the Installer's home page. Even if you never click Deploy in the wizard, it's a reliable way to see the schema for exactly the topology you've picked.
Two details on that page matter for anyone keeping specs in Git. First, "The JSON specification file does not include passwords": either let the Installer generate them (Autogenerate passwords is new in 9.1) and collect them with Review Passwords after deployment starts, or supply your own through a secret store. Second, you can download the JSON for a completed deployment, which makes a good as-built record to commit next to your change ticket.
Validation is your friend here. The Installer checks what you've provided and reports errors and warnings; warnings can be acknowledged, but errors have to be fixed, either in the wizard or by editing and re-uploading the JSON. In practice that makes a generate, validate, fix and re-upload loop the fastest way to iterate on a spec without burning hours on failed bring-ups.
Terraform enters through the vmware/vcf provider's vcf_instance resource. The provider README lists VCF 9.1.1 as needing v0.19.0 or later, and v0.19.0 (7 Oct) updated r/instance for 9.1.1. The pull request behind it, #445, adapts the resource to the new 9.1 API schema, adds a vsp_cluster attribute, follows an earlier change that removed the fleet appliance sub-resource, and flags a breaking change in its description: it can't perform bring-up for VCF 9.0.0 and earlier, even though the release notes list no breaking changes. So pin the provider to the VCF version you're building, and keep a separate root module, or at least a separate lock file, for a 9.0 lab.
Secrets need care in Terraform too. v0.18.2 (14 Sep) marked previously exposed password attributes as sensitive so they no longer show in plain text in terraform plan or terraform show. That's welcome, but sensitive only hides values from the output, so treat the state file as a secret and keep it in an encrypted backend rather than on a laptop.
Terraform isn't the only way to drive the Installer. AWS's write-up of an end-to-end VCF 9.1 deployment on Amazon EVS uses Terraform only for the AWS prerequisites, then the VMware VCF Python SDK to build a typed SddcSpec, set the depot token, sync the catalogue, submit the bring-up and watch it, with NSX Edges configured through the NSX and vCenter APIs afterwards. The author's point is that a typed model saves you hand-building REST payloads, and the same thinking applies to vcf-sdk-go, which the Terraform provider itself is built on (0.8.1 in v0.19.0).
That post is also a good list of field gotchas. Decide FQDNs, CIDRs and hostnames before the hosts are built, because changing them later means a teardown; give the Installer outbound HTTPS to the Broadcom depot and watch for expired depot tokens, which it calls a common cause of failure; make every step safe to rerun; and when something fails, the Installer UI shows per-task errors while domainmanager.log on the appliance has the stack traces.
For nested labs, William Lam's PowerShell project for automated VCF 9.x fleet deployment takes the same approach: it deploys nested ESX and the Installer, generates a vcf-mgmt JSON spec and submits it, and setting $startVCFBringup to 0 lets you edit the spec before it goes. Budget for it properly: the README asks for up to 24 vCPUs, 275 GB of RAM, 1.25 TB of storage and 17 IP addresses for VCF. His companion workarounds post covers the Installer properties labs often need, such as bringup.mgmt.cluster.minimum.size = 1 for a single-host management domain, and now notes that 9.1.1 handles HTTP offline depots and the vSAN ESA HCL check natively.
One last caveat from that post: for Day-N single or dual host instances and workload domains, VCF Operations applies its own host calculation, so you'll need the SDDC Manager API rather than the UI. A sensible pattern is to keep the JSON spec as the source of truth, generate it from the wizard once, template the parts that change between sites, and let Terraform or a script submit it, so that the as-built JSON you download afterwards should match what's in Git.
Based on Deploying a New VCF or vSphere Foundation Platform (Broadcom TechDocs) Official Start a New VCF Fleet or a New VCF Instance Deployment by Using the VCF Installer Deployment Wizard (Broadcom TechDocs) Official terraform-provider-vcf PR #445: update r/vcf_instance for VCF 9.1.1 Official terraform-provider-vcf v0.19.0 release Official Deploying VCF 9.1 on Amazon EVS with End-to-End Automation (AWS Blogs) vcf-fleet-automated-lab-deployment (William Lam) VCF 9.1 Installer and SDDC Manager lab workarounds (William Lam)
