Is Open Source KubeVirt Ready for Your VMs at Scale?
It is becoming widely accepted that managing containers and virtual machines (VMs) within a unified management structure is the best option for cloud-native infrastructure. As demonstrated during a talk given at a recent IBM conference and at other venues, the ability to run containerized workloads and VMs has become a critical component of DevOps. The benefits include proper scaling of resources and more efficient container and VM management. Meanwhile, organizations are looking at different approaches for building a hybrid container and VM infrastructure.
In the case of the open-source project KubeVirt, the idea is to run VMs alongside containers by integrating a virtual machine management layer into Kubernetes. KubeVirt is designed for teams focused on DevOps that have or want to adopt Kubernetes — and also have virtual machine workloads that otherwise cannot be easily containerized without KubeVirt. The key concept is that with KubeVirt, VMs are ported into a Kubernetes cluster.
The setup is reasonably straightforward and accessible, as we’ll see below. The project definitely serves as a worthwhile sandbox project and possibly as a solution that can be integrated with existing infrastructure. However, there are a number of caveats with this approach, especially for anyone who maintains and manages VMs at scale and is relatively new to Kubernetes.
The Works
The KubeVirt Kubernetes Virtualization API and runtime are designed to define and manage virtual machines. According to the project’s documentation, KubeVirt is largely limited to comparatively basic declarative usages, such as:
- Create a predefined VM.
- Schedule a VM on a Kubernetes cluster.
- Launch a VM.
- Stop a VM.
- Delete a VM.
KubeVirt’s setup on a PC is reasonably straightforward:
The prerequisites include:
- Homebrew (for installation)
- Kubectl (the Kubernetes CLI)
- minikube (for a local Kubernetes cluster)
- QEMU (suggested for virtualization support).
After the above is installed and KubeVirt is installed, the pods look okay here:
But the KubeVirt VMs do not load:
As we can see, Mac support is lacking since KubeVirt is thus far designed to run on Linux with KVM support. While I was able to successfully create the ARM64 VM manifest and start the VM, KubeVirt VMs would still not start – even with QEMU. Still, it already becomes apparent even at this stage that once VMs are running in the cluster, you enter the world of Kubernetes and its control plane, which is very different, more complex and more limited than managing VMs and containers directly through a traditional VM control plane.
Closer Look
KubeVirt lacks many important features, in addition to those mentioned above, including many of the advanced operational and lifecycle management features that only enterprise-grade virtualization platforms can provide. KubeVirt ostensibly covers VM management, including VM lifecycle, networking and security features. However, the depth of coverage is thin compared to a true enterprise-grade VM management platform.
In terms of VM lifecycle management capabilities, it only offers partial automation of VM provisioning. Features such as templates and cloning are only partially covered. While VM templates and data volumes are supported, they rely on CDI — Kubernetes’ Containerized Data Importer — so the functionality remains limited compared to more robust, enterprise-grade solutions.
Direct control and automation are also patchy in KubeVirt. For instance, while it offers restart capabilities, other operations — such as suspending, resuming and scaling VMs up or down — are neither straightforward nor scalable. These controls fall short of what a full-featured enterprise VM platform typically provides.
Support for custom images used in disaster recovery scenarios — through data volumes, PVCs and templates — is limited. Storage support is lacking and capabilities like CPU and RAM control through Kubernetes schedulers, particularly for I/O balancing, remain basic. Controls over CPU usage, RAM limits and I/O balancing are not comprehensive.
KubeVirt can support anti-affinity rules (used to schedule workloads to maintain high availability (HA) and for failure recovery) but their scope of usage for node-failure recovery for VMs and VM HA is limited. Disaster recovery is technically possible but largely depends on third-party integrations. While KubeVirt does offer backup and restore capabilities, they are not as mature or scalable as those in dedicated VM control planes or platforms.
Persistent volume storage with performance SLAs is limited in KubeVirt, as SLA enforcement depends entirely on the underlying storage infrastructure and its CSI driver, and there is no standardization across vendors. KubeVirt does not provide a built-in storage integration; instead, it relies on Kubernetes’ storage abstractions. As a result, support and compatibility with different storage vendors can vary, and vendors may not offer full support for KubeVirt workloads.
KubeVirt was created for Kubernetes-executing VMs, which means organizations using KubeVirt will remain reliant on storage vendors that support the Container Storage Interface (CSI). According to Gartner, as of January 2025, among listed CSI drivers: 54% do not support snapshots; while 49% do not support read/write to multiple pods; and 57% do not support expansion.
This means adopting KubeVirt could disrupt many environments that use storage unsupported by the CSI, and common storage features like snapshots, or expansion. This stands in stark contrast to traditional storage solutions for virtual environments, whether based on external or software-defined storage. Proven, de facto APIs have enabled storage vendors to consistently offload storage functions for virtual workloads. Examples include cloning, migration, provisioning, reclamation and access control.
Compliance is one area where KubeVirt falls notably short compared to enterprise-grade VM management platforms. It does not include built-in compliance reporting or integrations, though external tools may help..
The Verdict
KubeVirt is certainly different than traditional VM control planes, by integrating VMs within Kubernetes clusters. As such — and as we saw in our tests — when installing KubeVirt, the user organization enters the world of Kubernetes. This means that if an organization attempts to integrate its VMs with Kubernetes pods using KubeVirt, it will require the substantial expertise and experience of DevOps teams to manage VMs through Kubernetes.
Organizations with large VM deployments will face especially difficult transitions due to their reliance on scripting, advanced features and automation. Today’s VM operations benefit from mature tooling and simpler management, making the shift to Kubernetes-native VM management potentially costly and risky.
In other words, Kubernetes experts become necessary. For organizations that are already successfully running VMs on a platform, it is, in many respects, inadvisable to embark on the Kubernetes journey solely for the sake of integrating VMs with containers. The complexity, training and additional expertise required can outweigh the benefits.
KubeVirt is still a relatively young project, while VM platforms have been around for decades. Mature platforms exist that offer effective and viable methods for hybrid container-VM infrastructure. As a result, the added value of adopting a Kubernetes-based approach to VM management is questionable — particularly when existing VM platforms can already deliver integrated solutions without the overhead of managing a full Kubernetes environment.
The Road Ahead
KubeVirt is not expected to be widely adopted in the near term. According to Gartner estimates through 2028, technical and operational limitations will restrict adoption of KubeVirt to less than 10% of on-premises production virtual workloads in enterprise environments. Gartner has also noted that unfettered adoption of KubeVirt for VM management at scale involves sizable risks that can negatively impact ROI. The technical risk is “avoidable” when using KubeVirt for “revirtualizing” VMs, Gartner writes.
Having started as a sandbox project in 2019 and advancing to CNCF incubation in 2022, KubeVirt is still short of graduation-level maturity, which can take years to achieve. Given that KubeVirt’s compliance features and management are lacking compared to what established VM platforms offer, we do not recommend its adoption by organizations in highly regulated sectors like government or banking.
Tech giants might have formidable internal expertise and budgets to lavish on making KubeVirt work, but most enterprises lack the resources to manage this complexity independently. At this time, we recommend that organizations monitor KubeVirt’s progression and its adoption as a sandbox project pending its further development. For those organizations with a limited number of VMs and an established Kubernetes infrastructure, contributions to the community project can bring KubeVirt closer to the day when it might become a graduated CNCF project for those more limited use cases.
It will be interesting to see how the KubeVirt project evolves, while at least in the near term, it should continue to offer only very basic hypervisor admin features and is limited in use for VM management, especially at scale.
