The Nested Lab

Three VPC pods with byte-identical addressing and no route between them

Three datacenters, one IP plan: identical isolated pods with NSX VPCs

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.

Hub-and-spoke: three private pods reach one shared-services VPC over the transit gateway; the service cannot reach back

Shared services for isolated tenants: PrivateTGW subnets

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.

One blueprint: namespace, trunk topology, two nested hosts, two VIPs — requested as a catalog item

A datacenter in a catalog tile: nested ESXi pods via VCF Automation All Apps

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.

Dual-NIC nested hosts: what redundancy means when the fabric is virtual

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.

Three bootstrap paths into a VPC subnet: cloud-init, sysprep, vAppConfig

Our VPC subnets have no DHCP — and that's fine

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.

ContentValid: False — and the seven reasons why

Blueprinting the supervisor: seven CCI blueprint gotchas

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.

Two provisioning paths side by side: IaaS engine to vCenter, vs blueprint to supervisor reconciliation

VM Apps vs All Apps: a field comparison of VCF Automation's two provisioning models

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 Cluster manifest applied by kubectl and requested through the catalog — and what the second path adds for free

One VKS cluster, two ways: kubectl vs VCF Automation All Apps

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.

The lab factory: stage 1 nested hosts, stage 2 bringup, day-N items, one wrapper form

One catalog item, one VCF instance: building a lab factory

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.

One checkbox on every form: validateOnly. Tick everything, plan the whole stack, change nothing.

validateOnly everywhere: plan mode for infrastructure

Terraform has plan. Kubernetes has –dry-run. Your vRO workflows have nothing, unless you give them a validateOnly input and pass it down. The most valuable checkbox in the lab factory.