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.
Part 0 of the Pod Papers: an NSX VPC explained with a running game of Pac-Man. Private by default, one deliberate door out, and a self-inflicted outage where five green layers hid one wrong integer.
Plain VPC subnets silently blackhole a nested ESXi host. Why, and the trunk subnet and binding map design that makes nested labs work as an ordinary NSX VPC tenant.
Addresses pending for ever, a retryable error that never stops retrying, and an ordering rule the docs don’t tell you: in a self-service NSX VPC, the load balancer must exist before the namespace that uses it.
Three nested-ESXi pods with byte-identical addressing, down to the MACs, and no route between them. How overlapping VPC address ranges turn cookie-cutter environments into a feature.
Three pods with identical addressing all need the same repo, WSUS and AD. One shared-services VPC serves them all through the transit gateway, and can’t reach back into any of them.
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.
A second vNIC on a nested host adds no physical redundancy, so why add it? We expected bringup to want one, and pulling vmnic0 mid-SSH proved the trunk copes: 0% loss, session intact.
The nested ESXi appliance sat at ‘waiting for DHCP’ for ever. VPC subnets don’t hand out addresses: the VM Service does, through cloud-init, sysprep or OVF guestinfo, depending on the guest.