How VM API and KubeVM Service Deliver Open Standards and Enterprise Execution

VMs are the foundation of enterprise computing. They run the majority of mission-critical production workloads today, and they will continue to do so for years to come. What is changing is how platform engineering teams want to operate them.

As organizations build internal developer platforms around Kubernetes, teams want a single, declarative operating model across their entire footprint. They want self-service provisioning, GitOps automation, and policy-as-code applied everywhere. If a team needs declarative VM management, they need an open, standardized way to do it, without fragmenting their tooling or introducing vendor lock-in at the API layer. That is exactly why Broadcom announced on November 9, 2026, that the VM API project has been officially accepted into the Cloud Native Computing Foundation (CNCF) Sandbox.

Making Declarative VM Management Open: The VM API Initiative

The VM API project is not an untested prototype. It builds directly on VM Operator, a project with more than six years of continuous enterprise development and production mileage inside VMware vSphere, handling the real-world complexities of Day-2 operations, dynamic networking, and hardware reconciliation.

The architectural approach for VM API draws inspiration from the Cluster API (CAPI) model. Just as CAPI established a standard framework for platform teams to declaratively provision and manage Kubernetes clusters across different infrastructure backends, VM API aims to apply that same proven architectural pattern to VMs. It establishes a standardized, provider-neutral API contract for virtual workloads.

• Standard CRDs (Portable Intent): Developers define their VM requirements using familiar Kubernetes YAML manifests.
• Pluggable Providers: Behind that single API contract, provider plugins execute operations on the target infrastructure. While VM API serves as the common abstraction layer, different providers will have different advantages and trade-offs depending on their execution environment.

A Unified API Across On-Prem and Cloud

A core advantage of VM API is that it allows platform engineers to abstract VM operations across various supported providers. Instead of forcing teams to learn different APIs for on-premises infrastructure and public clouds, VM API provides developers with a consistent management interface and portable intent. While you can deploy the identical declarative YAML specification across any supported environment, the specific features, performance, and operational outcomes will depend on the underlying provider executing that request.

This declarative intent is then realized as real VMs on the backend. For on-premises, this could be KubeVM Service provisioning native ESX VMs on vSphere, or other potential plugins for environments like Proxmox on KVM. For the public cloud, plugins can provision EC2 instances on AWS or VMs on Google Cloud.

Note: The chart and table below illustrates these potential options to demonstrate the architecture. It does not represent all currently available providers. Please check the active CNCF Sandbox repository to see the official list of supported providers.

Layer	Technology Options (Examples)	Description
API Contract	VM API	Vendor-neutral Kubernetes CRDs defining portable VM intent across any environment.
On-Premises Providers	KubeVM Service (vSphere), Proxmox, KubeVirt, etc.	Executes VM intent natively on local hypervisors (e.g., ESX for VCF).
Cloud Providers	AWS, Google Cloud, etc.	Executes VM intent as real cloud instances (e.g., EC2) backed by hyperscaler infrastructure.

Why This Matters for New AI Applications

The push for declarative VM management is highly driven by the explosion of Generative AI. As developers build autonomous AI agents and complex indexing pipelines, these workloads frequently execute untrusted third-party code or process highly confidential proprietary models. Standard containers share the host operating system kernel, which can expose the underlying infrastructure to security risks when dealing with untrusted agentic AI tasks.

The advantage here is not that containers are inherently less secure, but that moving to containerized boundaries often requires organizations to re-architect their implementation, redesigning firewall rules, network segmentation, and compliance auditing around pod constructs. By bridging VMs into the Kubernetes ecosystem via VM API, platform teams provide hypervisor-enforced isolation boundaries for workloads with elevated security requirements while continuing to leverage established, audited, VM-centric security processes and tooling without reinventing the wheel. Data scientists get the declarative, self-service GitOps experience they expect for GPU-accelerated AI workstations, while enterprise security teams maintain complete operational continuity.

KubeVM Service: Selective Modernization on Existing Investments

While VM API provides the universal open standard for requesting a VM, KubeVM Service is the commercial vSphere provider that fulfills that request natively on VMware Cloud Foundation (VCF).

We want to be clear: there is absolutely nothing wrong with traditional vSphere VMs, and they are here to stay. However, if you want to provide a modern, cloud-native experience for teams developing these new AI applications, KubeVM Service allows you to selectively enable this declarative experience directly on your existing VCF investment. For a deeper dive into how this operates, read our recent post, Introducing KubeVM Service.

By leveraging KubeVM Service as your VM API provider, you get the best of both worlds:

• Frictionless GitOps: Developers manage VMs just like containers using standard Kubernetes workflows.
• Operational Continuity: The same VM remains visible to vCenter, VCF Operations, and existing backup tooling. VI admins retain their established governance and guardrails.
• Enterprise Resilience: Workloads benefit from native vSphere HA, DRS, and vMotion, completely abstracting hardware failures away from the Kubernetes layer.

The Numbers: Why Unified Operations Matter

To benchmark how platform teams are balancing their infrastructure, Broadcom and the CNCF sponsored a Linux Foundation Survey in September 2026, gathering data from 492 practitioners. The findings confirm that VMs remain central to modern enterprise architecture:

• VMs remain the core footprint: The average organization runs 53% of its production applications on VMs, with only 10% reporting zero production VMs.
• Operational teams are merging: 61% of respondents report that their VM administrators and container/platform teams are now collaborative or fully integrated.
• AI workloads demand hardware-grade isolation: Among organizations expanding VM capacity, 34% cite AI and agentic workloads as a primary driver, prompting teams to lean into hardware-level isolation for untrusted third-party code.

Advancing the Ecosystem Through Open Collaboration

The contribution of VM API aligns with Broadcom’s broader strategy to strengthen the cloud-native ecosystem through upstream collaboration. Alongside the VM API Sandbox acceptance, Broadcom also announced it is co-chairing the newly formed Workload Conformance Working Group within the Kubernetes community. While programs exist today to certify Kubernetes platforms, this new working group aims to establish common, verifiable expectations for how workloads behave, reducing validation efforts for enterprise platform teams and ISVs across heterogeneous environments.

Furthermore, the ecosystem supporting these workloads is expanding rapidly. VMware vSphere Kubernetes Service (VKS) recently validated more than 20 new partner solutions, spanning observability, security, and storage, giving customers greater flexibility when deploying both containers and VMs.

For more details on these initiatives, read the official press release and the companion open collaboration blog.

Get Involved

Platform teams aren’t looking to abandon their virtualization platforms. They want to bring declarative, Kubernetes-native workflows to those environments so developers have a single, automated interface for compute.

We invite the platform engineering community to help shape this evolution.

• Test KubeVM Service: Experience the commercial vSphere provider firsthand by enabling it on your existing VCF deployments.
• Contribute to VM API: View the specification, explore the different providers, and contribute code in the VM API GitHub repository within the CNCF Sandbox.