The API for declaring your VMs is now neutral; the provider that fulfils it is not

On 9 November, Broadcom announced that VM API is entering the CNCF Sandbox: Kubernetes CRDs for declaring a virtual machine with the same YAML, whatever hypervisor sits underneath. The next day, on its own blog, sits the sentence that qualifies it: "the specific features, performance, and operational outcomes will depend on the underlying provider executing that request". Both are in the same document and both are true. What travels is the request. What does not travel is the result.

We are writing this from a comfortable position: we resell no platform — not VMware, not Proxmox — and we run both, alongside Kubernetes and Docker Swarm in production. Which means there is no commission in this announcement for us either way, and that lets us say the part the press releases leave out: for most of the companies reading this, today it changes absolutely nothing, and the interesting part is not the announcement but the seams that are already showing.

What was announced, with the dates attached

The file is longer than the headline, and it is worth having in full. The application was opened by a Broadcom engineer on 2 September 2026. The CNCF TOC approved taking it to a vote on 22 September with two written conditions: "that the project moves kubevm out of the vmware repositories and demonstrates the pluggability of at least two providers". The vote closed in favour on 28 September — 72.73% of binding votes, eight in favour, none against — the issue was closed on 28 October when the onboarding one was created, and Broadcom's public announcement came on 9 November. Along the way the project changed its name: it was called KubeVM, and on 8 October its author explained that the CNCF discourages "kube" in project names, so it became vm-api, "similar to cluster-api". That administrative detail also explains why there are two repositories floating around. The project introduces a VirtualMachine resource in the vm-api.io API group, plus primitives on top: VirtualMachineReplicaSets and VirtualMachineDeployments, which are exactly what they sound like. The application states the pattern without hedging: "the pattern is Cluster API's core-plus-providers split, applied to VM lifecycle rather than cluster lifecycle". A generic core, pluggable providers, and a status contract between them so that the core imports no provider code at all. As an architectural decision that is a good one, and it is worth saying so before turning critical.

Two calendar details that change how everything else should be read. First: Sandbox is the CNCF's front door, the tier where young projects are accepted; it is not a maturity badge or a recommendation to deploy. Second: the public vm-api/vm-api repository was created on 30 October 2026, under Apache 2.0, and the API is at v1alpha1. That label is not decorative: alpha in Kubernetes means fields may change or disappear between releases. The code underneath is not new — it builds on vm-operator, with "more than six years of continuous enterprise development" inside vSphere — but the portable contract under discussion here is.

The two sentences in the same document

You do not need to find a critic to locate the small print: it is in the article Broadcom published on 10 November, a few lines apart: one in the paragraph explaining the main advantage and the other in the table that follows it. Putting them side by side already says most of what the announcement says. The rest is in the seams.

We are not going to settle which column weighs more, because your case decides that, not ours. If your pain is that every platform is asked in a different way and your product team wants to request a VM the way it requests a deployment, the left-hand column is a genuine improvement. If your pain is the invoice or the hypervisor underneath, the right-hand column tells you nothing has moved there: the piece that turns your YAML into a running machine is still a commercial product on VCF. The open standard is the request; whatever fulfils it on your current hardware belongs to somebody.

Where the abstraction splits: your portable VM carries no netmask

An abstraction is judged by its seams, and here there are two documented by someone who went looking for them with their hands. On 7 October 2026, an external developer opened an issue in the vm-operator repository explaining that they had written a provider for Proxmox VE following the official guide, and left two observations about the contract along the way. The second is the one to read slowly if you have ever configured a static IP by hand.

The portable resource's network addresses, it says, "are bare IPs with no prefix length and no gateway". And it adds why that is enough in one place and not another: "That is enough for platforms that hand out addresses (EC2, GCE) but not for ones that configure the guest directly". That is precise. On AWS or Google you ask for a machine and the platform hands it an address; the guest learns it over DHCP and nobody needs to write a netmask. On a hypervisor that configures the guest — Proxmox with cloud-init, and the author suspects vSphere is in the same position with its guest customization — the ipconfigN parameter needs a CIDR and a gateway. If the portable contract cannot express them, those two values end up in provider-specific fields. Which is to say: in the exact place where the coupling the abstraction came to free you from starts again.

The first observation is subtler and more interesting to anyone running Proxmox. "Every Proxmox state change (clone, start, shutdown, stop, resize, destroy) returns a task UPID and completes later". The guide's two examples are a synchronous platform — you ask, it answers — and an eventually-consistent one, EC2 style. Proxmox is a third shape: it hands you a task identifier and the work carries on afterwards, with a "transitional" state that can last minutes. What you watch is not the object, it is the task; and if you reconcile again while a task is running, the right move is to adopt it, not start a second one. Anyone who has automated Proxmox in a hurry and ended up with two clones of the same template knows exactly what this is about.

It is only fair to say: these are early, normal seams in something marked v1alpha1, written by somebody who also offers to draft the missing section of the guide. They are not a scandalous defect. They are the exact measure of how much portability exists today, which is a different thing from how much there will be.

A Proxmox provider already exists, and it has been waiting thirty-five days

The provider in that issue is not a mock-up. According to its author it implements the VirtualMachine resource against a QEMU VM cloned from a template, with sizing, native cloud-init (SSH keys, hostname, DNS, IPv4 by DHCP or static), power on and off with all three API modes, addresses read from the guest agent, and deletion. And it is tested at three levels: unit tests against an in-memory Proxmox, envtest with core and provider on a real API server, and end to end against real Proxmox VE 9.2, on arm64 and on amd64 under nested KVM. The repository is public and Apache 2.0, created on 6 October.

Its two questions are the kind you cannot answer alone: where third-party providers should live, and whether a hypervisor provider is useful to them right now to support the claim that "the API generalises". As of 11 November, the thread has no public reply. Thirty-five days. And the question is not rhetorical: the condition the TOC set for taking the project to a vote was, literally, to demonstrate "the pluggability of at least two providers". Meanwhile, the table in Broadcom's article lists "KubeVM Service (vSphere), Proxmox, KubeVirt, etc." in the on-premises providers row, with a footnote warning that the table "illustrates these potential options" and "does not represent all currently available providers". Which is to say: Proxmox appears in the drawing as a possibility, and the person who wrote the provider is waiting for an answer.

Before drawing conclusions, the counterweights. The issue is open in the vm-operator repository and not in the new vm-api one, which did not even exist when it was written, so it may simply be in the wrong inbox; the project has spent those weeks changing its name and its home; and silence on GitHub is not a refusal, because plenty of conversations happen on lists, on Slack or on a call. Nor is this the only third party to have approached the project, or the first: that comes next. What we are saying is that as of today this particular thread is still open and unanswered, and that is a fact anyone can go and check.

The part of the file that made it into no press release

On 11 October, two weeks after the vote, two authors of virtualisation projects stepped into the application to say they disagreed with how their work had been described. The first, author of KubeSwift and VirtRigaud: "VirtRigaud is currently used in production, it does support extended lifecycle management of VSphere, LibVirt and Proxmox Hypervisors and VM Migration across hypervisors". That is, a third-party project already running Proxmox in production and moving machines between hypervisors on top. Their underlying complaint: the application described that work as attempts "with limited adoption" against an implementation that was "production-proven ... from the outset", when the applicant's code lived at the time in a branch of another repository.

The second, author of banlieue and a self-declared friend of the first — his words, not ours — put in writing the objection that weighs most here, because it is the same one holding up this post from the opening: "My main concern is that the case for vendor neutrality rests on things that don't exist yet". And he grounded it in the application itself: the generic controller was at that point "the first milestone on the roadmap and is not yet written", and the only provider in production was VM Operator, which is also the control plane of Broadcom's commercial product. A month later, that controller exists and has its own repository. The objection was not prophecy; it was a date.

There were replies, and they deserve the same volume. The applicant answered on 13 October, apologised for the delay — "I apologize for not getting to the comments earlier" — and explained where the confusion came from. Days earlier, on 5 October, he had already answered in public the person asking how this differs from Cluster API. And the CNCF pointed out that overlap between projects is no grounds for rejection, in line with its "no kingmakers" principle, and that the application had already been reviewed on its merits. So the picture is not "nobody answers anybody": the substantive objections and the Cluster API comparison were answered. What remains unanswered, in its own thread, is the offer of a second provider — which happens to be one of the two conditions the TOC set. For anyone buying infrastructure this is not repository gossip: it is the cheapest way there is to tell the neutrality asserted on a slide from the neutrality that holds up when third parties turn up to argue about it in writing.

The other unanswered question: what about KubeVirt?

On 4 November, with the TOC vote closed in favour since September, somebody opened a well-made and uncomfortable question in the VM API repository. The argument is solid, and the calendar has reinforced it on its own. KubeVirt is already a Kubernetes-native VM API: it entered the Sandbox in September 2019, moved to incubation in April 2022, and its graduation vote passed on that same 4 November with 81.82% in favour, three minutes before the question was opened. The CNCF announced it publicly on 10 November, at KubeCon in Salt Lake City, with 2,088 contributors from 520 organisations behind it. Put another way: the week VM API came in through the bottom rung, the project it is compared against was leaving through the top one. And it is no longer tied to QEMU/KVM: there is explicit work decoupling the core from KVM-specific logic, and a Hyper-V integration as proof it can support further hypervisors. The question, then, is direct: why is another generic layer needed, beside or above the one that already exists? And the irony that sharpens it: VM API's own roadmap lists KubeVirt as one of its planned providers.

Sixteen minutes later, the same author declared their conflict of interest — "I am actively involved in KubeVirt" — and extended the question towards Cluster API, which is where the pattern comes from: if the design mirrors the Machine contract, what happens to lifecycle ownership when a VM is also a cluster node? A week later, that thread still has no reply from the project. The general question — how this differs from Cluster API — was answered, and in public, as we have just seen; what remains open is this specific variant about who owns the lifecycle. We take no side here either: the question comes from an interested party, and it is perfectly possible the answer is a good one and simply unwritten. But two APIs competing to be the place where a virtual machine is declared is, precisely, the problem a standard came to solve.

What this changes if you run forty virtual machines (today, nothing)

This is the part nobody with something to sell wants to tell you. If your company runs a virtualisation cluster with a few dozen VMs, a couple of people maintaining it and Kubernetes nowhere, putting your VMs behind a Kubernetes control plane fixes no problem you have today. It adds a second control plane on top of the same hypervisor: one more thing to upgrade, one more thing to watch, and a new failure domain stacked on one that already existed. The resilience question to ask before any other is what happens when that cluster goes down, and whether your machines still boot without it.

And there is a recurring cost almost nobody adds up when deciding this at a whiteboard: the calendar. Kubernetes ships a new release every four months, each one is supported for fourteen, and upgrades cannot skip versions; we laid out the dates in Kubernetes expires every fourteen months and you cannot skip versions. That is the real price of owning a control plane, and you pay it whether you run forty VMs or four hundred. If the underlying decision on your table is which orchestrator you actually need, the criteria are written without dogma in Docker Swarm is not dead: what you are really choosing.

When it does make sense to watch this closely, then. It is worth a look if you already run Kubernetes in production with somebody maintaining it; if your product team requests infrastructure through YAML and GitOps and VMs are the exception requested by email; or if you carry containers and virtual machines through two separate workflows and that costs you hours every week. In that scenario, declaring both the same way is a genuine improvement.

Five questions before this goes into a contract

When somebody shows you a slide with a neutral API in the middle and several hypervisors hanging off it, these five questions separate what is standardised from what is drawn. They work for VM API and for any abstraction layer sold to you afterwards.

What we do with an announcement like this

We read it, note it and carry on. We run Proxmox VE with Ceph in production, we have worked with VMware since old releases, and we deploy both Kubernetes and Docker Swarm, including managed Kubernetes: we are orchestrator-agnostic because we are paid for none of them. When a layer like this matures and a serious provider fulfils it on the platform you already own, it will be time to write about it again with numbers. Today the honest thing to say is that it is at v1alpha1, that the vote putting it in the Sandbox closed in September with two conditions and one of them is still open, and that the piece fulfilling it on VCF is commercial.

If this decision is on your table — or the one below it, which is which hypervisor you want for the next five years — that is exactly the job of our IT consulting: putting numbers on both options while taking commission from neither. The layer underneath we build ourselves, in infrastructure and cloud, and if what you are looking at is leaving VMware, the layered path with a way back is in VMware to Proxmox migration.

Sources (checked on 11-11-2026): the contribution announcement and the Sandbox acceptance date come from Broadcom's press release of 09-11-2026. The quotes on portable intent, outcomes depending on the provider, KubeVM Service as the commercial provider on VCF, the provider table including Proxmox and the note "It does not represent all currently available providers" come from How VM API and KubeVM Service Deliver Open Standards and Enterprise Execution, published on 10-11-2026 on the VMware Cloud Foundation blog. The description of the VirtualMachine resource, the initial API group — then kube-vm.io, before the rename — the replica and deployment primitives and the sentence about the Cluster API pattern are from the CNCF Sandbox application (issue 517), opened on 02-09-2026 and closed on 28-10-2026. That same thread is the source of the two TOC conditions of 22-09, the vote result of 28-09 (72.73% in favour, eight binding votes), the rename from KubeVM to vm-api on 08-10, the interventions by the authors of VirtRigaud/KubeSwift and of banlieue on 11-10, the applicant's reply of 13-10 with its apology, the CNCF's reply on the "no kingmakers" principle, and the 05-10 answer on how this differs from Cluster API. The vm-api.io API group we checked in the repository's own code (api/v1alpha1/groupversion_info.go). KubeVirt's graduation, with the vote closed on 04-11-2026 at 81.82%, is in TOC issue 1822, and the public announcement with the figures of 2,088 contributors and 520 organisations is in the CNCF statement of 10-11-2026. The two contract notes, the scope of the Proxmox provider and its test matrix against Proxmox VE 9.2 on arm64 and amd64 are in vm-operator issue 2013, opened on 07-10-2026; the provider code is klarsmith/kubevm-provider-proxmox, Apache 2.0. The KubeVirt question, its CNCF history and the extension towards Cluster API are in vm-api issue 13, dated 04-11-2026. The "no reply" status of those two issues we checked ourselves through the GitHub API on 11-11-2026 and it may have changed by the time you read this: the vm-operator one had no comments and the vm-api one had a single comment, from its own author. The creation date and licence of the vm-api/vm-api repository (30-10-2026, Apache 2.0) come from the same source. The Kubernetes release calendar is developed and linked in our own post. We are not resellers of VMware, Broadcom or Proxmox, and we sell no platform licences. Photograph: "Datacenter Server Racks" by Carl Lender, CC BY 2.0 via Wikimedia Commons, original 6,000 × 4,000, cropped by us.