Broadcom’s VM API Joins the CNCF Sandbox: What to Compare Before a Pilot
Broadcom announced on Nov. 9, 2026 that it has contributed VM API to the open source cloud native ecosystem, with the project entering the CNCF Sandbox. In Broadcom’s announcement, the company frames VM API as a way to provide common virtual machine lifecycle definitions while allowing provider-specific implementations underneath. Broadcom also says the project builds on VM Operator work. Separately, Broadcom’s engineering post describes the effort as an open collaboration aimed at advancing cloud native virtual machine management.
Broadcom investor announcement, Nov. 9, 2026
Broadcom engineering explanation, Nov. 9, 2026
What the project is trying to standardize
Based on Broadcom’s materials, the practical idea is to define a common Kubernetes-facing VM lifecycle model, while leaving the actual provider implementation to each platform. That distinction matters. A shared API can make it easier to describe desired VM actions in a consistent way, but it does not automatically mean every backend behaves the same way in practice.
Broadcom says VM API builds on VM Operator, which suggests the project is not starting from zero. For evaluators, that usually means the right comparison is not simply “does it exist,” but “what behavior is actually implemented, by whom, and with what evidence.”
What Sandbox acceptance does and does not prove
CNCF Sandbox acceptance is best read as an early-stage community signal, not as proof of production maturity. It indicates a project has entered the CNCF ecosystem, but it does not establish that the project has two working providers, functional parity across providers, or guaranteed portability between environments.
It also does not mean a buyer should treat the project and any specific commercial product as interchangeable. If a vendor uses VM API in one offering and a different stack or management layer in another, those should be evaluated separately unless the evidence clearly shows otherwise.
A simple buyer checklist for a disposable VM pilot
Define one disposable test VM and use the same workload and resource targets in each supported environment.
- Confirm the actual supported implementation on each platform before comparing anything. If a second implementation is not confirmed, record it as "not tested."
- Track the requested CPU and memory for the disposable VM, and note whether the platform accepted those values as requested.
- Record whether start and stop actions were requested, and whether the lifecycle result matched the request.
- Document storage assumptions separately, including the storage class or backing model if it is known and confirmed.
- Document network assumptions separately, including any expected connectivity or attachment behavior that was explicitly tested.
- Capture the lifecycle result in plain language: created, started, stopped, deleted, failed, or partially completed.
- Keep evidence with each result, such as logs, UI state, or API response records, if those are available in the evaluation process.
- If behavior cannot be compared against a second confirmed implementation, do not imply parity; mark the missing side as "not tested."
How to read pilot results carefully
If one platform can create the disposable VM but another cannot, that is a useful finding, not a failure of the checklist. If both can create it but differ on start, stop, storage handling, or network behavior, note the difference directly and avoid claiming portability. Portability should be demonstrated, not assumed from a shared API name.
For decision-making, the most helpful output is usually a small matrix of observed behavior, with every unconfirmed item labeled clearly. That keeps the evaluation grounded in what was actually tested and avoids overstating the significance of an early-stage CNCF project.
What to record before moving ahead
Broadcom’s VM API appears intended to make virtual machine lifecycle definitions more consistent across Kubernetes-oriented environments, while still allowing provider-specific implementations. That is a meaningful design goal, but Sandbox status alone should not be mistaken for proof of production readiness, multiple working providers, parity, or guaranteed interoperability. Before any pilot, compare the implementations you can actually verify and record the rest as not tested.
