Having your cake and eating it too? Maybe not.
For the KubeVirt virtualization environment, you’ll have your cake but you’ll have to wait to eat it or not eat it at all. As usual, there’s many ways to characterize a comparison like this one between KubeVirt and AHV. Our former SVP for Product and Solutions says, “KubeVirt can become quicksand pretty easily.” Lee Caswell has been the master of metaphors for us at Nutanix, so let’s see why.
The problem is that KubeVirt-based VMs were designed originally to help developers quickly get a VM up and running from their own self-provisioning environment. They could use them for testing as needed and then potentially pass them over to IT to manage more traditionally when they’re ready to use.
Developers use a familiar declarative YAML file that they already use to set up containers to run VMs in Kubernetes (K8s) pods alongside their containers. Additionally, if they want to access an already running, production VM, they could use their CSI drivers or API calls to access whatever is needed for their apps. There’s arguably no need to spin up a new one other than for testing in many cases. The main point here is that KubeVirt VMs were not typically created as 1st class citizens in a production environment by developers (or by IT operators utilizing YAML files). Check out The New Stack article here.
The Broadcom Factor
After Broadcom’s acquisition of VMware, customers began looking for alternatives to run their vSphere production VMs, including “revirtualizing” them to KubeVirt-based VMs. The thought was at first that VMs could be migrated over from production workloads and then candidates for refactoring eventually to containerized workloads. That was an aspirational goal but a lot of organizations just wanted to keep their VMs running indefinitely in production with no need to convert to containers.
There are many other reasons to run KubeVirt-based VMs, outside of enterprise, mission-critical data center environments. For example, they can run at the edge and for smaller, less mission-critical workloads.
A Heavy Lift
If organizations want to run production VMs in K8s pods, a lot of additional overhead and potentially very sophisticated automation needs to take place. The mitigation strategies have to address several fronts as shown in the following table:
| Feature | Mitigation Challenge |
| Storage | CSI drivers were meant for container volumes, not VM disks. Snapshots, cloning, and mobility will not work the same as for traditional VMs in production. |
| Networking | K8s pods typically use Layer-3 networking, while traditional VMs often rely on Layer 2 networking. |
| Resilience | K8s pod checks can’t see the VM OS. The QEMU guest agent provides visibility inside the VM and can result in a mismatch between VM and pod status. |
| Performance | Ideal performance requires CPU pinning and HugePages. You have to manage the constraints and tune for specific workloads. |
| Security | KubeVirt introduces a dual-layer security model: the K8s pod boundary and the guest OS. That means more surfaces to secure and manage operationally. |
As a result, after addressing these issues, KubeVirt-based VMs can run properly on a day-to-day basis but are not really meant for folks eager to eat cake any time soon. Let’s also hope it’s not quicksand. You might have your own metaphor like stuffing a grand piano in a carry-on bag.
Let’s have a look at this recorded video session I had with one of our Distinguished Engineers at Nutanix about this very topic, Kostadis Roussos.
To find out more check out the following:
- Nutanix Cloud Native Community
- Nutanix University: NKP Playlist
- Simplify Cloud Native Kubernetes Management
Here’s some ways to get to know NKP as we’ve emerged as a leader for enterprise containerization:
This next series provides a deeper dive into NKP capabilities:
If you want to try NKP out yourself, click here.
FAQ: AHV vs KubeVirt-Based VMs
Q: What is the fundamental difference between Nutanix AHV and KubeVirt?
A: Nutanix AHV is a mature, enterprise-grade, Type-1 hypervisor purpose-built to run mission-critical virtual machines with native, first-class management. KubeVirt, conversely, is an add-on that runs VMs inside Kubernetes pods. It was primarily designed to give developers a self-service way to spin up temporary VMs alongside their containers using familiar declarative YAML, rather than serving as a foundational platform for traditional, long-running enterprise VMs.
Q: Can KubeVirt serve as a drop-in replacement for VMware vSphere?
A: Not easily. While the "Broadcom Factor" has many organizations looking to migrate off vSphere infrastructure, treating KubeVirt as a direct substitute for production VMs could lead to operational quicksand. Refactoring traditional VMs to run as containerized workloads is a heavy lift. Nutanix AHV, on the other hand, is designed precisely as a drop-in, enterprise-ready alternative to vSphere, requiring no complex application refactoring or paradigm shifts for IT operations.
Q: How do storage and networking compare between the two?
A: They rely on entirely different paradigms.
- Storage: Nutanix AHV uses native VM-centric storage APIs for seamless snapshots, cloning, and mobility. KubeVirt relies on Container Storage Interface (CSI) drivers, which were built for container volumes. Applying traditional VM data protection and mobility workflows to CSI-backed VMs is complex as CSI drivers are developed and applied differently than traditional enterprise VM storage solutions.
- Networking: AHV natively supports the Layer-2 networking that traditional VMs expect. KubeVirt pods typically utilize Layer-3 networking, meaning bridging traditional VM traffic into a Kubernetes network model requires significant abstraction and manual configuration.
Q: What are the performance and security implications of running production VMs on KubeVirt?
A:
- Performance: Delivering bare-metal or enterprise hypervisor-level performance in KubeVirt requires extensive manual tuning, such as CPU pinning and managing HugePages constraints to bypass the K8s overhead. AHV is designed to deliver high performance out-of-the-box without requiring pod-level micro-management.
- Security & Resilience: KubeVirt introduces a dual-layer security and monitoring model (the K8s pod boundary and the guest OS). Kubernetes pod checks cannot natively see the VM OS status without agents (like QEMU guest agent), which can lead to mismatches between pod status and actual VM health, expanding the operational surface area.
Q: If our organization needs to run both VMs and containers, what is the recommended approach?
A: You don't have to stuff a grand piano into a carry-on bag by forcing VMs into Kubernetes pods. A recommended approach is to let each workload run in its native environment. By utilizing Nutanix AHV for your production VMs and the Nutanix Kubernetes Platform (NKP) for your cloud-native workloads, you get the best of both worlds—managed from a single, unified infrastructure plane without compromising performance, security, or day-two operations.
©2026 Nutanix, Inc. All rights reserved. Nutanix, the Nutanix logo and all Nutanix product and service names mentioned herein are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. Nutanix, Inc. is not affiliated with VMware by Broadcom or Broadcom. VMware and the various VMware product names recited herein are registered or unregistered trademarks of Broadcom in the United States and/or other countries. Red Hat and OpenShift are registered trademarks or trademarks of Red Hat, Inc. or its subsidiaries in the United States and/or other countries. Kubernetes is a registered trademark of The Linux Foundation in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).