Nested ESXi inside an NSX VPC: the trunk-subnet design
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.
vSphere and vSAN
vSphere, ESXi and vSAN underneath it all: nested ESXi as VM Service VMs, dual-NIC hosts, vSAN networking in nested clusters, and the Supervisor’s own rules.
The load balancer that must exist before the namespace
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.
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.
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.