Dora NodaTwenty-five days before KubeCon, the highest-leverage VM session on the schedule is not a keynote. It is a 2:35 p.m. expo-floor theater talk by Broadcom about a project that was renamed three days ago, approved for CNCF Sandbox over live objections, and whose second provider exists mostly as a demo recording.
That is exactly why it matters: Salt Lake City is where declarative VMs either graduate from vendor roadmap to community contract, or get politely filed under "check back in a year." This preview gives you the verdicts up front, then the evidence behind them.
KubeCon + CloudNativeCon North America 2026 runs November 9–12 at the Salt Palace Convention Center in Salt Lake City, with co-located events on Monday the 9th and the main program Tuesday through Thursday. The CNCF published the full schedule in August, and this year's program adds a new AI Inference + Agentic track alongside the established platform-engineering and security programming.
If you operate a small, self-hosted, Cluster-API-managed fleet — the CAPH-on-Hetzner shape, say — most of that program is noise. Here is the signal.
The watch list, up front
| # | Development | Where to catch it | Verdict | First action |
|---|---|---|---|---|
| 1 | VM API (ex-KubeVM) Sandbox debut | Expo Theater, Tue Nov 10, 2:35 p.m. MST | Track the contract, don't adopt the code — not yet a bring-your-own-hypervisor path | Read the provider contract in the sandbox proposal, then decide if your roadmap needs it |
| 2 | VMware's Cluster API-as-product commitment | Booth #129 CAPI contributor 1:1s; CAPI maintainer-track sessions | Enterprise legitimacy for the API your fleet already runs on | Audit your manifests for v1beta1 — it goes unserved in CAPI v1.16 |
| 3 | In-place machine updates (update extensions) | CAPI maintainer track; ask at Booth #129 | Changes the node-rollout runbook: updates without delete-and-recreate | Plan one pilot MachineDeployment on the new extension |
| 4 | Velero 1.19 under CNCF stewardship | Broadcom booth demos | Multi-vendor backup is now safe to standardize on | Evaluate Velero 1.19 for fleet backup and migration |
| 5 | VMware's open-sourced etcd diagnostics | Booth #129; upstream sessions | Free operational tooling from the EU donation wave | Trial the tooling against your management cluster |
| 6 | Cloud Native AI + Inference Day | Mon Nov 9 (co-located) | Worth one day if agent sandboxes are on your roadmap; otherwise watch recordings | Send one person, or none — see the skip list below |
VM API: one Kubernetes API for VMs, and the sandbox saga behind it
The headline session is "One Kubernetes API for VMs, without rebuilding the infrastructure beneath it" (Tuesday, November 10, 2:35 p.m., Demo Theater on the expo floor). Broadcom's pitch: VM API, an open-source CNCF Sandbox project, brings Kubernetes' declarative simplicity to virtual machines through a platform-agnostic VirtualMachine resource and a status contract modeled after Cluster API.
The session promises the core architecture, the provider interface, a cross-platform portability demo across two distinct environments, and advanced capabilities like replicas, rolling replacements, and warm pools of pre-provisioned VMs. That is an ambitious agenda for a project at this maturity stage — which is precisely what makes it unmissable.
The design genuinely is Cluster API's core-plus-providers split, applied to VM lifecycle rather than cluster lifecycle. The sandbox proposal introduces a portable VirtualMachine custom resource in a kube-vm.io API group carrying the intent common to every platform — power state, sizing, boot image, storage, networking, guest bootstrap — bound to a platform through a reference to a provider-owned object. The generic controller observes backends through a duck-typed status contract so it imports no provider code.
Power state is modeled as desired state; destruction is object deletion. Layered primitives (VirtualMachineReplicaSet, VirtualMachineDeployment) plus cloud-init/Sysprep bootstrap, snapshots, and recovery round out the familiar shape. If you already think in CAPI's core/provider vocabulary, the learning curve is close to zero.
The first provider is VM Operator (vmware-tanzu), open source for six years, shipping as the control plane for VMware's VM Service, and validated at 25,000 real VMs on a single Kubernetes cluster. That production history is the project's strongest card — and also the source of the controversy you should know about before Salt Lake City.
The application went in as "KubeVM"; on September 22 the TOC approved moving to a vote on the conditions that the project move out of VMware repositories and demonstrate pluggability with at least two providers. The generic controller was "not yet written" when the application opened (it has since been added), and the vSphere integration initially supported only limited capabilities like boot disks, a storage class, and power-state changes. The second provider is an EC2 prototype shown in a demo recording plus a sample container provider.
On October 12 the project was renamed from KubeVM to vm-api because the CNCF discourages "kube" in project names. And on October 11–13, the authors of adjacent projects (VirtRigaud/KubeSwift, banlieue) objected on the record: unmet TOC conditions, inaccurate prior-art statements, overlap with KubeVirt and others, and a single-vendor maintainer base. The TOC's October 13 response held the line — the project was already voted on and approved, the Contribution Agreement is being prepared, repos move during onboarding, and multi-org maintainers are not required at Sandbox.
So here is the verdict on the question this post owes you: VM API is not yet the bring-your-own-hypervisor path. A sandbox-stage API with single-vendor maintainers, one production provider that is also the donor's commercial control plane, and a second provider that exists as a prototype is something you track, not something you build a fleet on.
What makes it worth tracking — and worth that expo-theater seat — is the shape of the contract: if the provider interface and duck-typed status contract survive community contact, every future hypervisor provider (libvirt, Proxmox, bare-metal-adjacent) plugs into one neutral API instead of each shipping its own CRDs. Go to judge the contract's maturity, not to plan an adoption. Ask the presenters two questions: which provider beyond vSphere will be more than a demo by KubeCon EU 2027, and when the code actually leaves the vendor repo.
VMware's CAPI-as-product bet is the enterprise-legitimacy signal
The deeper story for a CAPI fleet is the arc from Amsterdam to Salt Lake City. At KubeCon EU 2026, Broadcom donated Velero to the CNCF Sandbox and unveiled VKS updates with F5, Kong, and Tigera integrations plus Kubernetes 1.35 support. And — in the words of the RedMonk "Chopping Wood, Carrying Water" interview — the company committed to exposing Cluster API directly as a product surface, open-sourced etcd diagnostic tooling for the whole community, and set Velero on a path to multi-vendor stewardship with Red Hat and Microsoft maintainers.
For Salt Lake City, Broadcom returns as a Platinum sponsor at Booth #129, demoing Velero 1.19, VKS 3.8, Kubernetes 1.37, and automated chained upgrades. Engineers from Velero, Cluster API, etcd, containerd, Harbor, and Contour will be available for 1:1 conversations — the hallway track, formalized.
Why should a fleet that will never buy a VMware license care? Because "runs on Cluster API" just got a second, enterprise-shaped proof point, and that legitimacy lands as two concrete consequences for your manifests.
First, the v1beta1 sunset is now scheduled, not hypothetical: core CAPI has the v1beta1 API on track to be unserved in CAPI v1.16, with the v1.14.0 release notes telling every consumer to migrate to v1beta2 ASAP. If your fleet manifests, CI pipelines, or tenant-facing tooling still read v1beta1 objects, Salt Lake City is your deadline warning — audit them before the version you depend on stops being served.
Second, CAPI v1.12's update extensions let KCP and MachineDeployments change existing machines in place instead of deleting and re-creating them, with declaratively aggregated updates across clusters. That is a direct change to the node-rollout runbook, and exactly the kind of thing to interrogate a maintainer about face to face. (Broadcom's Fabrizio Pandini is the CAPI SIG's tech lead, which tells you how seriously the company is taking the "expose CAPI directly" commitment.)
The status check to run in Salt Lake City, then: confirm Velero's multi-vendor maintainer reality and kick the tires on 1.19, pick up the open-sourced etcd diagnostics, and press a CAPI maintainer on the v1beta2 migration path and in-place update semantics. Legitimacy you can't use is marketing; legitimacy that ships as a migration deadline and a rollout primitive is an operations input.
Sessions worth your time, and the noise to skip
All times MST. The full program is on the KubeCon NA schedule; these are the entries that survive the CAPH-on-Hetzner filter.
Monday, November 9 (co-located day). Cloud Native AI + Inference Day is the day's anchor, with Broadcom's keynote "Path to Resilient App Delivery: AI is Hard, Production is Harder" at 10:10 a.m. in Room 254. Go if agent sandboxes or inference workloads are on your twelve-month roadmap; otherwise this is the easiest day to skip and watch recordings — nothing on it changes a fleet without GPUs.
Tuesday, November 10. The VM API expo session at 2:35 p.m. (Demo Theater, expo floor) is the week's single must-attend for this watch list. Pair it with "Why Quotas Are Hard in Kubernetes: Lessons from Building a Production-Grade Quota System" at 3:40 p.m. (Room 255 BC) — quota design is the unglamorous core of multi-tenant fleet economics, and production-grade lessons transfer directly to any platform metering tenant workloads. "Cloud Native Infrastructure in the AI Era: A TAG Infrastructure Panel" at 5:30 p.m. (Room 251 D-F) is your infrastructure-roadmap panel. And somewhere in the day, do the unscheduled thing that matters most: a Booth #129 1:1 with a CAPI contributor about v1beta2 migration and in-place updates, plus whatever CAPI maintainer-track sessions the schedule shows — the upgrade-path conversation is worth more than any single talk.
Wednesday, November 11. Work the hallway track. Broadcom, Canonical, and PlatformEngineering.org host an executive roundtable ("Scaling Secure and Governed AI Platforms," 4–6 p.m.) and a reception panel ("Building The Agentic Future," 6–9 p.m.), both off-site and registration-gated — useful for roadmap sensing, skippable for operations.
Thursday, November 12. "SIG Storage Intro and Deep Dive" at 11:00 a.m. (Room 250 D-F) is the storage-roadmap session for anyone backing tenant volumes with owned block storage. "Explore TAG Workloads Foundation: Core Runtime, Batch Scheduling, and Moar" at 1:45 p.m. (Room 251 A-C) covers the batch-scheduling primitives that matter the day your git-push flow meets its first gang-scheduled workload.
The skip list. Hyperscaler AI-conformance keynotes: DRA support is the Kubernetes AI Conformance program's first mandatory requirement and all three major clouds ship DRA, but conformance theater tells an owned-hardware fleet nothing its own scheduler gap analysis won't — check the requirement list, skip the keynote. "Securing the Agentic Future: Distributing LLM Weights and Sandboxed AI Agents via Harbor" (Thu 1:45 p.m.) goes here too: LLM-weight distribution only matters once you self-host models rather than calling APIs, so watch the recording and spend the slot in the TAG Workloads session instead. Vendor keynotes in general: your fleet's constraints are node count and operator hours, not cloud SKU coverage.
Monday morning after KubeCon: three actions
Conferences produce notes; fleets need diffs. Three actions, in priority order:
- Audit every manifest, pipeline, and tool for v1beta1. The v1.16 unserving deadline is the one Salt Lake City takeaway with a calendar attached. List every CAPI object your fleet and CI touch, convert new manifests to v1beta2 immediately, and schedule the migration of existing ones. This is a grep-and-convert task, not a research project — start it the Monday you get back.
- Read the VM API provider contract; adopt nothing. Pull up the sandbox proposal's contract definition and the generic controller code, and answer one question for your roadmap: if a libvirt or Proxmox provider existed, would your fleet use declarative VMs? If yes, follow the repo and show up to community meetings. If no, set a calendar reminder for KubeCon EU 2027 and move on. Either way you have spent an hour, not a quarter.
- Trial the etcd diagnostics and evaluate Velero 1.19. Both are concrete, free artifacts of the EU donation wave with NA demos to learn from. Run the etcd tooling against a staging management cluster, and scope what Velero 1.19 would replace in your backup-and-migration story. These are bounded pilots with clear abort criteria — the right shape for post-conference energy.
The through-line of Salt Lake City for a self-hosted operator is declarative surface area: VMs through a CAPI-shaped API, clusters through CAPI itself, backups through a neutrally-governed Velero. None of it is turnkey yet. All of it is pointed in the direction your fleet is already walking.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
