Executive Summary
Broadcom put its VM API into the CNCF Sandbox and took a co-chair on a new workload conformance working group. Set beside a Linux Foundation study released the same day, which found virtual machines carry an average 53 percent of production applications, the move is not generosity. It is a vendor with the largest VM estate writing the interface that governs everyone else.
The number that matters more is 8 percent, the share of VM-running respondents who manage those machines with KubeVirt. Years of argument for virtual machines on Kubernetes have produced a bridge with almost no traffic on it. So this is not a migration signal. It is Broadcom standardizing the layer a rival would have to interoperate with, and a partner play, because a conformance standard certifies an application once instead of once per distribution.
Broadcom contributed its VM API project to the CNCF Sandbox on 9 November. The project takes the declarative model Kubernetes uses for containers and points it at virtual machines, so a VM is created, described and deleted through the same API surface as a pod. It builds on VM Operator, the controller Broadcom already ships for vSphere inside VMware Cloud Foundation, and the stated goal is a provider-neutral API, the way Cluster API is a provider-neutral API for clusters.
The announcement carried two more pieces. Broadcom is co-chairing a new Kubernetes Workload Conformance Working Group, and it validated more than 20 partner products against VMware vSphere Kubernetes Service, taking the count past 90 independent software vendors.
Prashanth Shenoy, Broadcom chief marketing officer for cloud platform, told Paul Gillin at SiliconANGLE that the goal is to “make virtual machines first-class citizens of a Kubernetes environment without sacrificing what makes them distinct and valuable for our customers.” First-class citizen is a claim about the API, not about the deployment.
The 8 percent number is the real finding
A Linux Foundation Research study released the same day surveyed 492 practitioners in September. It found virtual machines running an average 53 percent of production applications, and 71 percent of respondents expecting that share to hold. CNCF and Broadcom sponsored the research, so treat those figures as a description of the installed base rather than as independent validation.
Then the number that undercuts the sales pitch. Among respondents who run VMs, 8 percent manage them through KubeVirt, the CNCF project that has spent years extending Kubernetes to virtual machines. Eight percent is not a migration in progress. Kubernetes virtual machine management is still an early project, not an operating model.
That makes the donation rational for Broadcom. If a virtual machine becomes a neutral, portable Kubernetes object, the interesting competition moves off the hypervisor management plane and onto whatever runs beneath it. A vendor with the largest installed base of enterprise VMs has the least to lose from a portable API and the most to gain from being its reference implementation.
Conformance is a tax cut dressed as a standard
The working group is the part with a business model inside it. Conformance today verifies that a distribution implements the Kubernetes API. It does not verify that a given application behaves the same way on two distributions, because infrastructure capabilities, configuration and operational defaults differ. Every difference is a validation cycle an independent software vendor pays for.
A shared workload conformance standard would let a vendor certify an application once and claim it anywhere conformant. For Broadcom that lowers the cost of maintaining the partner catalog it just expanded. For a customer it means less time re-testing an agent that should already have been portable.
The fair question is who writes the test. A working group co-chaired by the vendor with the largest VM estate, launched the same week that vendor publishes its own portability claims, is normal standards behavior rather than a scandal. It is also why the criteria have to be published and line-itemed. A conformance suite nobody reads is a marketing asset with a PDF attached.
What to do with this if you run the estate
If you are deciding whether to move off VMware, a neutral VM API is a mild tailwind and a poor reason either way. An API does not move a workload, and 8 percent adoption says the tooling is not where a migration gets won. What it changes is the ceiling. An operating model built on Kubernetes objects becomes plausible for the VM estate, which matters if your platform team already talks that way.
If you are staying, watch the conformance group rather than the API. Where the standard lands on network policy, storage attachment behavior and privileged workloads decides whether runs on any conformant cluster becomes a real portability claim or a badge on a partner page. The API is the announcement. The test suite is the product.
Three questions worth putting to anyone selling the portability line. Which conformance suite, published where, and what a pass actually covers. Which workloads would pass on two distributions today without a single change. And which part of the estate would move if VM management became a Kubernetes object tomorrow, because that is where the lock-in lives.
Related reading. One library file turned out to be the real gate on a VMware exit, and Europe got a second vSphere 8 deadline that nobody else got.
Get the next one before it is old news
Independent analysis of cloud-native infrastructure, Kubernetes and data center economics. No vendor spin.