On VCF 9.1, the supported route installs Telegraf in new VKS clusters for you. Underneath sits a dependency the README never mentions, two secrets from the Supervisor Management Proxy, and without them every Telegraf pod is stuck.
A self-contained HTML build report, down to a Gantt chart that spots the reboots. Plus the Session 0 traps, like mangled vmtoolsd arguments and ejecting an ISO with no Explorer, that cost real hours.
One script runs at every startup until the build is done. Flag files make each step run once, a state file keeps true timings across reboots, and at the end it cleans up, reports and deletes itself.
One catalog request, one fully built, domain-joined Windows Server 2025 with its agents, a validation report, and no trace of the tooling that built it. The three-layer design, and why each seam is where it is.
The VCF Operations agent matrix doesn’t list Windows Server 2025. Add one missing Windows component, WMIC, and the normal install just works. What ‘unsupported’ really means, and what to watch.
One log pipeline, two very different worlds: fluent-bit as a VKS package and as a Windows Server 2025 service, both shipping to the same VCF Operations for Logs. One backend, two configs, lessons from both.
Seven demo apps, Pac-Man and KubeDoom among them, on a VKS cluster that VCF Automation built in a tenant VPC, each with its own NSX virtual IP. The proper tenanted path, what you get for free, and the traps.
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.