Dora NodaEvery containers-first platform eventually gets the ticket: a tenant who doesn't want a container, they want a machine. A legacy Windows service that will never be a Dockerfile. An untrusted-code workload where namespaces feel one CVE away from a bad day. A dev environment with a real kernel.
Yesterday's KubeCon NA 2026 preview covered the governance saga behind Broadcom's answer — VM API, the Cluster-API-modeled VirtualMachine resource now headed for CNCF Sandbox. This post answers the operator's follow-up question: what do you actually do when the ticket lands?
The short version: if you need tenant VMs this quarter, the answer is KubeVirt. If you're planning next year's roadmap, the thing to track is VM API's provider contract, not its code. And Cluster API's infrastructure providers — the Machine objects your fleet already reconciles — are for nodes, not tenants, and conflating the two is the most expensive mistake in this space. The table below makes that concrete; the rest of the post is the evidence behind each cell.
The decision table: five asks, four paths
Each row is a VM request a containers-first fleet actually receives. Each column is a path you could take. The verdict names the winner and the one-line reason.
| Tenant ask | KubeVirt | VM API | CAPI infra provider | Say no / outsource | Verdict |
|---|---|---|---|---|---|
| Legacy or odd-OS app (Windows, old libc) | Runs today: VM-in-a-pod on your nodes | No provider for your metal yet | Wrong layer: provisions nodes, not tenant machines | Viable: point at a VPS | KubeVirt — the only declarative path that runs on hardware you own today |
| Untrusted code needing kernel isolation | Strong fit: VM boundary inside your scheduler | Contract fits, code doesn't exist yet | Wrong layer | Viable for low volume | KubeVirt — the isolation boundary ships now |
| GPU-backed VM (inference, training) | Works via passthrough; v1.8 adds confidential VMs | Warm pools and suspend/resume are roadmap, not code | Node-pool story, not tenant VMs | Often cheapest per GPU-hour | KubeVirt or outsource — decide on GPU-hour math, not API shape |
| Full-OS dev environment | Works but heavy: a VM per dev on shared nodes | Replicas and rolling replacement would fit; sandbox-stage | Wrong layer | Strongest alternative: ephemeral cloud dev boxes | Outsource unless persistent — don't build a dev-cloud to avoid a vendor |
| Kubernetes node VMs (fleet growth) | Possible via nested virt, but perverse | Out of scope by design | This is what it's for | N/A | CAPI infra provider — the one row where the other columns are wrong |
Two patterns fall out of the table. First, KubeVirt wins every "this quarter" row because it is the only option whose maturity evidence describes the thing you'd actually run. Second, VM API's column is uniformly "not yet" — which is exactly why the interesting question isn't whether to adopt it, but what would have to change for a cell to flip.
KubeVirt today: the incumbent's receipt
KubeVirt is a CNCF Incubating project now actively pushing toward graduation, and its v1.8 release at KubeCon Europe 2026 was a genuine maturity step: a hypervisor abstraction layer that finally cuts the cord locking KubeVirt to KVM, plus confidential-VM support for the tenants whose threat model needs it (Rawkode Academy's v1.8 breakdown, CloudNativeNow). Architecturally it runs a hypervisor process (QEMU/KVM) inside a Pod, so the VM is a cluster workload: same scheduler, same CNI, same CSI as your containers. For a fleet that already operates Kubernetes on owned metal, there is no second infrastructure layer to buy — Cozystack's bare-metal PaaS, covered here in July, is the existence proof that KubeVirt plus Cluster API on owned hardware is a shippable combination.
The honest cost list for adopting it on a containers-first fleet is four items. Your nodes need KVM capability (true on any Hetzner dedicated box, check per cloud instance type). VM networking wants a bridge or Multus path beside your pod network. VM disks want a storage story with live-migration-capable backends if you care about maintenance windows.
And your on-call rotation inherits a second workload model — virt-controller, virt-handler, and libvirt failure modes alongside kubelet ones. None of that is disqualifying; all of it is real operator load you should price before the first tenant VM lands, not after.
What VM API actually contributes: the contract, not the code
VM API's October 12 KubeCon preview post pitches "one Kubernetes API for VMs, without rebuilding the infrastructure beneath it," and the sandbox proposal (ex-KubeVM, renamed vm-api because the CNCF discourages "kube" in project names) shows the mechanism. It is Cluster API's core-plus-providers split applied to VM lifecycle instead of cluster lifecycle: 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 of well-known field paths, so core imports no provider code and each provider evolves independently.
On top of that object sit the fleet primitives the session promises: VirtualMachineReplicaSet and VirtualMachineDeployment for replica counts with versioning and upgrade strategy, plus warm pools of pre-provisioned VMs with quick suspend/resume handled at the platform layer. Power state is modeled as desired state; destruction is object deletion. If you already think in CAPI's core/provider vocabulary, the learning curve is close to zero — that familiarity is deliberate, and it is the project's best design decision.
The one architectural sentence separating it from KubeVirt comes from the proposal's own prior-art table: KubeVirt runs the hypervisor inside a Pod, using Kubernetes as the only infrastructure layer; VM API leaves the VM as a native object of the underlying platform and uses Kubernetes as the API surface, delegating placement, migration, and storage to that platform. Kubernetes as front door to infrastructure you already have, versus Kubernetes as the infrastructure. The proposal even names KubeVirt as a future provider — "the cheapest possible second implementation" because it runs in kind with no cloud account — which makes the two projects integration candidates, not rivals, if the contract survives community contact.
The sandbox-stage caveats, quantified
Yesterday's preview covered the saga; here are the four facts that gate adoption, each with what flips it to green:
- The API is
v1alpha1and new. The six-year history and 25,000-VMs-per-cluster validation belong to VM Operator, the vSphere controller that is VM API's first provider — not to the portable API. Flips when: the generic controller and conformance suite exist and providers pass them. - Single-vendor maintainers. The core team is Broadcom, and the first provider is also the donor's commercial VM Service control plane. Sandbox doesn't require multi-org maintainers, but adoption should. Flips when: a second organization maintains core or a provider.
- The second provider is a prototype. An EC2 demo recording plus a sample container provider; the KubeVirt provider is roadmap. The TOC conditioned its vote on demonstrating pluggability with at least two providers. Flips when: two providers pass a published conformance suite in CI.
- The code still lives in the vendor repo. The October 13 TOC response says repos move during onboarding — true, and also not done yet. Flips when:
vm-apiandvm-api-provider-*repos exist under neutral governance.
None of these is a reason to dismiss the project; every CNCF project starts here. They are reasons to track the contract and adopt nothing — the same verdict as yesterday, now with falsifiable exit criteria.
Where "also runs VMs" becomes a first-class deploy target
The TODO-shaped question underneath this post is a scope question: when does offering VMs stop being a KubeVirt-shaped "we can run one if you must" and start being a deploy target next to buildpacks — git push for containers, declarative spec for machines? Four conditions, all of which must hold:
- A provider for your metal. A libvirt, Proxmox, or bare-metal-adjacent provider that runs where your fleet runs — not vSphere, not EC2. Without this, VM API is a front door to someone else's infrastructure.
- A published conformance suite with two passing providers. The TOC's own condition, and the only thing that makes "platform-agnostic" a test result instead of a slogan.
- Multi-vendor core maintenance. So the API's evolution isn't paced by one company's roadmap.
- Neutral repo homes. So your fleet's dependency isn't a vendor branch.
Until all four hold, "also runs VMs" is correctly scoped as a KubeVirt question: one more workload type inside the cluster you already operate, with costs you can price today. The day all four hold, it becomes a platform question: a second deploy target with its own provider lifecycle, and that's a product decision, not an ops ticket.
Monday-morning actions
Three steps, in order, totaling about an hour:
- Read the provider contract, not the pitch. Open the sandbox proposal and the
v1alpha1types it links. Answer one question: if a libvirt provider existed tomorrow, would your fleet offer tenant VMs through it? A yes means follow the repo; a no means set a reminder for KubeCon EU 2027. - Price KubeVirt for your fattest "today" row. Pick the table row your tenants actually ask about, and cost the four items above (KVM nodes, bridge networking, migration-capable storage, on-call load) against outsourcing. Most fleets discover the answer is obvious once it's priced.
- Keep CAPI infra providers out of the tenant conversation. If any internal doc or tool presents
Machineobjects as a tenant VM surface, fix the framing now: nodes are fleet capacity, VMs are tenant product, and the API that conflates them will eventually bill you for the confusion.
The through-line is the same one Salt Lake City keeps repeating: declarative surface area is expanding — clusters through CAPI, backups through Velero, VMs through whichever of these two APIs earns it. Your fleet doesn't need to adopt the new one. It needs to know exactly what would change its mind.
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.
