News

CNCF Research: VMs Hold Their Ground as AI Isolation Needs Grow

Virtual machines remain a substantial part of cloud native production infrastructure, with a new survey finding that AI workload isolation is adding another reason for organizations to maintain or expand their virtualized environments.

The Cloud Native Computing Foundation (CNCF) and Broadcom announced the findings Nov. 9. The Linux Foundation Research study surveyed 492 practitioners and leaders in September. It describes VM and container operations coexisting, rather than documenting a wholesale replacement of one deployment model by another.

The report, Virtual Machines, Agentic AI and the Mix of Workloads, was written by Adrienn Lawson, with a foreword by Broadcom engineering executive Dilpreet Bindra. CNCF and Broadcom sponsored the research.

Nine key statistics about virtual machines, agentic AI and the mix of workloads from the 2026 Cloud Native Workloads Survey
[Click on image for larger view.] Key findings from the 2026 Cloud Native Workloads Survey. (source: Adrienn Lawson, The Linux Foundation, November 2026; CC BY-ND 4.0).

VM Share and VM Growth Measure Different Things
Respondents reported that VMs host 53% of production applications on average; 51% said at least half of their applications run as VMs. Average VM share reached 64% at organizations with 10,000 or more employees, compared with 45% at those with fewer than 500.

Among respondents answering both current and expected workload-share questions, 71% anticipated staying within the same VM-share range over the next year. That expectation does not mean the number of VMs will remain unchanged.

The full study separately found 51% expanding their VM footprint. Absolute VM counts can grow without raising their share of applications, and modest changes may stay within a survey band. Among expanders, application growth led the reasons at 53%, followed by hardware utilization at 48%, security and isolation at 47%, and AI or agentic workloads at 34%.

AI Isolation Adds Another Role for Virtualization
Among valid answers, 62% reported at least one VM-based AI isolation approach: hardware-level isolation, containers within VMs or MicroVM sandboxing. Current MicroVM sandboxing use was 20%, versus 30% planning use next year. Confidential computing stood at 12% current use and 26% planned use. These are respondents' intentions, not completed deployments.

The isolation technologies address different layers of infrastructure. The Kata Containers project's technical overview describes lightweight VMs that integrate with container management while using hypervisors to separate a container, or a pod's containers, from other workloads. A dedicated guest kernel separates that execution environment from the host kernel shared by conventional containers.

Kata supports the Open Container Initiative container format and Kubernetes Container Runtime Interface. Its documentation describes hardware virtualization as an isolation boundary for sensitive workloads, including untrusted AI code. That is a runtime approach to isolation; it does not require turning an application into a conventional, separately administered VM before using container orchestration.

The project identifies both short-lived and longer-running uses, including serverless functions, continuous integration and delivery, and web servers. Its overview also describes isolating network, input/output and memory through the dedicated-kernel environment, with hardware virtualization extensions available to enforce that separation.

Shared Operations Do Not Necessarily Mean a Shared Platform
The study found 61% describing their VM and container administration teams as collaborative or fully integrated. That measures organizational coordination, not the detailed technical arrangement of every workload. Among VM users, 8% reported KubeVirt, which brings VM management into Kubernetes.

KubeVirt's architecture documentation explains that the project adds resource types, controllers and node-level daemons to Kubernetes. Kubernetes handles scheduling, networking and storage, while KubeVirt provides virtualization functionality. The controllers and daemons themselves run on the cluster.

Administrators can define a VirtualMachine resource and its desired behavior through the Kubernetes API. KubeVirt's VirtualMachine controller manages the associated VirtualMachineInstance, including recreating an instance when the configured run strategy requires it. The project also documents maintaining stable VM configuration across restarts and exposing a VM through a Kubernetes service. Those mechanisms explain how VM workloads can participate in Kubernetes operations while retaining a guest operating system.

Reading the Survey's Limits
The web survey recruited through Linux Foundation and partner channels. Respondents answered for their organizations, but organization names were not collected, so multiple respondents could represent one organization. The research did not measure the composition of the non-VM application share or fully map how technologies are layered. Its VM percentage therefore cannot be read as an inverse measure of container adoption.

About the Author

David Ramel is an editor and writer at Converge 360.

Featured