A complete guide to the VCF Automation 9.1 blueprint designer: every palette item, the YAML behind it, every field the platform accepts, recipes and traps. Every snippet validated, dry-run or deployed.
A self-contained HTML build report, down to a Gantt chart that spots the reboots. Plus the Session 0 traps, like mangled vmtoolsd arguments and ejecting an ISO with no Explorer, that cost real hours.
One script runs at every startup until the build is done. Flag files make each step run once, a state file keeps true timings across reboots, and at the end it cleans up, reports and deletes itself.
One catalog request, one fully built, domain-joined Windows Server 2025 with its agents, a validation report, and no trace of the tooling that built it. The three-layer design, and why each seam is where it is.
Seven demo apps, Pac-Man and KubeDoom among them, on a VKS cluster that VCF Automation built in a tenant VPC, each with its own NSX virtual IP. The proper tenanted path, what you get for free, and the traps.
The whole isolated pod, nested ESXi hosts and all, as one VCF Automation blueprint in the catalog. How the blueprint is built, the order it enforces, and the three things it can’t express.
Seven ways the nested-ESXi pod blueprint failed validation before it worked, from ${input} inside flow mappings to an image-sync race. Short, specific, and each one cost me a cycle.
VCF Automation 9.1 has two provisioning models, as two kinds of organisation. I ran the same use cases through both, from Windows VMs to nested ESXi. The honest scorecard, and how each case is done.
The same VKS cluster built twice: once with kubectl, once as a VCF Automation request. The Cluster object is identical. Everything around it isn’t, and the difference is what you get for free.
How an interactive PowerShell script grew into a catalog item that builds complete nested VCF 9.1 instances from one request form. The design rules that made it survivable, and the traps behind them.