A VCF Automation 9.1 catalog that builds a complete nested VCF lab per request, each in its own VPC. How it differs from capturing a hand-built lab, and what building from code buys you.
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.
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.