I scoped this on 2026-05-21: get a vSphere-with-Tanzu / VKS Supervisor running on the nested vSphere lab I'd stood up on a single Proxmox workstation. Two months later I had the prerequisites — a licensed vCenter 9.1 and four ESXi hosts it could actually manage — and I still had not enabled Workload Management. This is the log of that gap, because the gap turned out to be most of the build.
The substrate was already there from the earlier vCenter post: vCenter plus two nested ESXi hosts on one ~128GB Xeon workstation running Proxmox. On paper that's enough. The plan was to add a third nested ESXi and a load balancer and land a full Supervisor cluster on top. I'd initially written the lab off as too small for VKS, which was wrong — it's small, not disqualifying.
The breakage list I wrote before touching anything
Before any build work I wrote a pre-mortem — the failures I expected, in order. That list ended up being the spine of the whole effort:
missing license (day zero), MTU mismatch, HAProxy cert trust, storage policy not tagged, Proxmox VM CPU type not host
Day zero was a single binary go/no-go: confirm I actually had a real Tanzu/VKS entitlement before spending a minute on the build. VMUG Advantage — the usual home-lab licensing route — does not cover Tanzu or VKS, so ordinary lab keys were never going to get me there. I sorted proper licensing first; everything downstream was gated on that one fact.
The rest of the plan was sizing and networking. Sizing was dictated by the host: Tiny Supervisor only (3x8GB CP VMs distributed across nested ESXi). Small (3x16GB) won't fit on 128GB host. Storage would be an NFS export from the Proxmox host to all three nested ESXi — the path of least resistance. The load balancer I picked was the free, official HAProxy OVA fling, on the logic that NSX is overkill for this lab. (A later note argues the other way — VDS plus Avi/NSX-ALB as the lighter path — and I haven't reconciled which I'd actually deploy.) Workloads would sit on a dedicated /24 on a new Proxmox bridge, subnet-routed over Tailscale so my laptop could reach them. Time estimate, optimistic: one focused weekend if the license is OK, two if a phase-3 networking issue hits.
The prerequisite that ate the first month: a newer vCenter
VKS needs Supervisor, Supervisor needs vCenter, and vCenter must be at least as new as its hosts. My old vCenter was a dead 8.0.3 that couldn't manage ESXi 9.1, so before any Kubernetes anything I had to stand up a fresh vCenter Server Appliance 9.1.0.0 on a bare-metal ESXi 9.1 node. That took the first month and hit every trap I've already written up on their own — so here I'll keep it to the short version.
The VCSA ISO silently truncated when I first extracted the 8.97 GB appliance OVA through the ISO9660 view instead of UDF (ISO9660 caps a single file at 4 GB). The bare-metal node shipped with an OEM SK hynix BC511 NVMe that ESXi flatly refuses to mount — its namespace reports an all-zero NGUID, so ESXi can't build a device identity; I swapped in a retail Lexar and it came up immediately. And Tiny vCenter's 619 GB provisioned figure nearly failed the datastore precheck until thin-disk mode (real footprint ~30-50 GB) rescued it. Each of those is its own story; none of them is the VKS story. The VKS story is what happened once the vCenter was finally up.
Licensing was the whole ballgame
On 2026-07-18 the day-zero gate closed. Both nested ESXi hosts moved to esx.vcf.cpuCoreMin — vSphere 8 Enterprise Plus for VCF — which includes the Tanzu/VKS entitlement, so Workload Management is now enable-able. I want to be precise about that phrasing: enable-able, not enabled. The entitlement existing is not the same as a Supervisor running.
Getting the four hosts into the new vCenter surfaced two more licensing failures worth writing down. Adding a spare NUC failed outright, and relicensing a free host through the API failed differently:
vmodl.fault.NotEnoughLicenses (esx.hypervisor.cpuPackageCoreLimited) # host-add blocked
vmodl.fault.NotImplemented # AddLicense on a free hostThe first is the free vSphere Hypervisor edition genuinely refusing vCenter management; it resolved the same night with new 100-core keys (part VCF-CLD-FND-VSP-5) that took the host to esx.vcf.cpuCoreMin, and all four hosts joined. The second I hit trying to relicense a free host through the API: AddLicense throws NotImplemented and UpdateLicense silently returns an empty license object without changing anything. A free-edition host has to be licensed through the host UI, and a standalone host has no licenseAssignmentManager — that manager is vCenter-only. The core math matters too: the 32-core key maxed at 32/32 because VMware bills a 16-core-per-CPU minimum across two nested single-socket hosts, so adding a third nested ESXi means eval mode or freeing cores first.
By 2026-07-27 the vCenter was live with inventory rebuilt: one datacenter (I named it Pranav Web Services) and four 1-host clusters, us-home-1 through us-home-4.
The part that matters is the part I haven't done
Here's the honest state. There's a real structural gap between vCenter-is-up and Supervisor-is-running: the clusters are 1-host, and 1-host clusters can't do HA/DRS, which Workload Management requires. The fix on the roadmap is to merge two of the hosts into one cluster with an EVC baseline, because the hosts are different CPU generations. I haven't done that merge yet.
And everything past that merge is still plan, not fact. I have no evidence in my own notes that the NFS datastore was ever mounted on the nested hosts, that any load balancer was deployed, or that the third nested ESXi was ever built. Two of my pre-mortem items — the MTU mismatch and the Proxmox CPU-type-not-host trap — never got exercised at all, because I never reached the networking phase.
Most important: I have no record of ever logging in with kubectl-vsphere, no enabled Supervisor, no running VKS cluster. The keystone step — enabling Workload Management — is exactly the one still open. The product target is clear enough on paper: VCF 9.1 / VKS, a Supervisor control plane of one, three, or five nodes. But that's TechDocs, not my lab. What the lab has actually proven so far is narrower and less glamorous: getting VKS to the start line was, in wall-clock terms, about 90% "stand up a vCenter that can actually host it" and 0% Kubernetes. The Kubernetes is the next post, if it ever earns one.