KubeVirt: Can VM Management With Kubernetes Work?

KubeVirt offers a bridge between virtual machines and containerized environments.  As an open-source project, its standout feature is the ability to run VMs and containers side by side. 

But while the concept is promising, several caveats remain for organizations that need to support critical at-scale VM workloads. The CNCF project also reflects how containers are not going to replace VMs, while the reverse may be true in the long term for many use cases.

Gartner estimates that through 2028, technical and operational limitations will restrict adoption of KubeVirt to less than 10% of on-premises production virtual workloads in enterprise environments.

KubeVirt’s lackluster adoption forecast by Gartner is largely due to how its functionality has been shown to properly support only a limited number of virtual machines running alongside containers. Most of the management and security features that today’s VM infrastructure provides are not available in KubeVirt, in favor of bringing VMs under the Kubernetes management control plan. For organizations seeking to port a significant or large number of VMs and integrate them with Kubernetes, the project lacks the necessary support in several key areas.

Backed by industry players such as NVIDIA, Red Hat, and others, the project has the kind of support that could drive the improvements it still needs. However, it will likely be over a decade before that potential is fully realized, while existing virtual machine infrastructure providers already offer the capacity to run VMs alongside containers today and likely into the extended future.

The Works

KubeVirt remains in the incubation stage after entering the CNCF as a sandbox project in 2019 and advancing to the incubation maturity level in 2022. Designed for organizations that have virtual machine workloads and want to adopt a Kubernetes control plane, KubeVirt serves as a platform that allows for both to run side by side. The KubeVirt Kubernetes Virtualization API and runtime are designed to define and manage virtual machines. However, additional functionality is required that another tool provides: Libvirt is used to integrate VMs with a KVM hypervisor so they can be launched and managed within Kubernetes pods. According to the project’s documentation, KubeVirt is largely limited to very basic declarative usages, such as:

• Creating a predefined VM.
• Scheduling a VM on a Kubernetes cluster.
• Launching a VM.
• Stopping a VM.
• Deleting a VM.

According to Gartner, KubeVirt’s use cases include Infrastructure provisioning to create and destroy short-lived non-production virtual environments (including development and lab environments. 

Once KubeVirt is successfully implemented, its functionality is significantly limited compared to established VM-management offerings, especially those that can extend to Kubernetes, allowing applications running on containers or VMs to be managed on a single platform. 

Functionality Want

KubeVirt provides very basic hypervisor admin features and is limited in use. For integrating a limited number of VMs, the relative lack of functionality and advanced operational capabilities, such as storage-management integration, does not support advanced features expected in VM management. Since VM-based infrastructure has been in use for several decades, VMs benefit from extensive industry understanding and ongoing innovation of management in this space. Ideally, VMs’ advanced capabilities must be available with containers in a common infrastructure. 

Since KubeVirt was created for Kubernetes-executing VMs, this means organizations using KubeVirt remain reliant on storage vendors that support the Container Storage Interface (CSI). According to Gartner, as of January 2025, among the listed CSI drivers:

• 54% do not support snapshots.
• 49% do not support read/write to multiple pods.
• 57% do not support expansion.

CSI requirements can disrupt many storage environments that use many common features like snapshots and 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.

According to Michael Warrilow, a vice president and Gartner analyst, “Most enterprises are likely to find that re-virtualization of existing production virtual workloads will be the most technically challenging, risky, and difficult to justify through at least 2028.”

Integration with storage systems is not a default implementation feature of KubeVirt. Without a standardized storage element that attaches to or is standard for KubeVirt, different storage vendors may or may not easily work with or offer support for it.

While organizations can manage existing VMs with KubeVirt, the management capabilities are minimal and limited to basic hypervisor administration. VMs continue to exist within the infrastructure, but KubeVirt lacks many of the advanced operational and life cycle management features that enterprise-grade virtualization platforms provide.

Skill Ups

Organizations continue to rely on virtual machines because they offer operational simplicity, proven efficiency, and a lower total cost of ownership (TCO). Furthermore, the existing talent pool is better aligned with VM management; hiring skilled professionals in traditional VM environments remains considerably easier than sourcing equivalent expertise in containerized or Kubernetes-native infrastructures.

In comparison to traditional VM platforms, Kubernetes introduces significantly more operational complexity. This architectural shift imposes substantial friction, as it requires organizations to move away from established VM management practices and toward a Kubernetes-centric approach. While Kubernetes offers powerful orchestration capabilities, it also demands a completely new skill set. Virtual infrastructure administrators must be retrained, and organizations must reskill entire teams to manage existing VM workloads through a new control plane such as KubeVirt.

Today’s VM operations are supported by mature orchestration tools, advanced features, and hardened security and compliance frameworks. Introducing virtual machines into a Kubernetes-native environment via KubeVirt would require organizations to overhaul their tooling and significantly reskill technical teams — an effort that carries considerable cost and operational risk. As such, the rationale for running VMs inside Kubernetes clusters using KubeVirt remains limited to highly specific use cases and is not recommended for general enterprise adoption.

For organizations in regulated or mission-critical sectors, such as banking, federal, state, and local governments, utilities, or retail, the risks associated with adopting such a nascent technology like KubeVirt are considerable. Unlike technology leaders such as NVIDIA, Google, or Meta, which have internal engineering capabilities to customize and support open source tools, most enterprises are not equipped to manage this level of technical complexity independently.

KubeVirt is purpose-built for Kubernetes environments, yet the requirements for enterprise adoption remain considerable. The platform operates on the assumption that all workloads will eventually be migrated to Kubernetes. However, such transitions are rarely immediate; even upgrades between Kubernetes versions can take several months — or, in some cases, years.

“This is an evident gap in skills that will need to be overcome to successfully adopt KubeVirt, whether for production or not. Many existing I&O personnel will lack proficiency and experience in modern, cloud-native tools and methodologies,” Warrilow writes. “Implementing DevOps requires significant investment in both technology and training, which has proven to be a barrier to widespread adoption. KubeVirt will force this change.”

This perspective is consistent with observations made by Gartner, which has noted that vendors such as Red Hat, with its OpenShift platform, have adopted KubeVirt as a strategic entry into the VM management market. Developing a mature, enterprise-grade VM management platform typically requires many years, if not decades, of sustained engineering and operational refinement, regardless of whether the solution is open source or proprietary.

Conclusion

KubeVirt is a very well-supported project and can serve as a solid sandbox project for those organizations exploring different virtualization options for VMs and Kubernetes. The healthy number of stars and forks notwithstanding, very few organizations with significant resources can afford to rely on such a young project (Version 1.0 of KubeVirt was released in July 2023) to integrate VMs with Kubernetes and container infrastructure. It is recommended that for the foreseeable future, its use remains limited to the management of small numbers of VMs — think tens of VMs for a sandbox project, and not a thousand VMs that support critical operations. 

As we have mentioned above, we advise against porting large-scale VM deployments — over 100 VMs — to Kubernetes using KubeVirt. This kind of re-virtualization implies that you are likely taking a managed VM infrastructure and forfeiting several key security, advanced features, storage, and management benefits for the sake of running Kubernetes or containers and VMs side by side within a cluster environment.

Achieving ROI would be a challenge. Conversely, platforms exist that have been tried and tested to run both VMs and Kubernetes on a single platform, while preserving all the benefits of a well-managed VM and Kubernetes infrastructure.