What is KubeVirt? How does it migrate VMware workloads to Kubernetes?

There are many different types of abstractions used in modern IT deployments. While it’s still possible to run applications on bare metal, that approach doesn’t fully optimize hardware utilization. That’s where virtualization comes in. With virtualization, one physical piece of hardware can be abstracted or ‘virtualized’ to enable more workloads to run.

Modern virtualization isn’t just about abstracting any one single piece of hardware, but also about abstracting larger clusters in cloud deployments. There are many different ways of doing virtualization in the cloud, and among the most common approaches is to use the open-source Kubernetes container orchestration system. A container is a type of virtualization that is different from a virtual machine (VM). 

Prior to the advent of Kubernetes, one of the most popular ways for organizations to deploy virtualization was with VMs, more often than not using technology from VMware.

What is KubeVirt?

The open-source KubeVirt project is a technology that does exactly what the two parts of the name imply. Namely it combined Kubernetes, the container orchestration system, with virtualization, in this case specifically virtual machines.

KubeVirt enables users to deploy and manage VM workloads directly inside of Kubernetes deployments. By default, Kubernetes relies on container virtualization and not VMs. Traditional virtualization platforms like VMware vSphere operate independently from container orchestration systems, requiring separate management tools, workflows, and expertise.

KubeVirt bridges that gap, enabling cloud-native deployments to run both VMs and containers in the same Kubernetes environment. KubeVirt makes virtual machines behave like native Kubernetes resources, allowing operations teams to apply the same principles, patterns and tools they use for container management to virtual machines. It’s an approach that can enable a consistent operational model across both VM and containerized workloads.

The KubeVirt open-source project was started by Linux vendor Red Hat in 2016. The project joined the Cloud Native Computing Foundation (CNCF), which is the home of Kubernetes, in 2019. As part of the CNCF, KubeVirt benefits from a broad ecosystem of vendors that contribute to the project. According to the CNCF contributors include: Amadeus, Apple, CloudFlare, IBM, NEC, Nvidia, SAP and SUSE.

The project is maintained on GitHub, with the primary repository GitHub – kubevirt/kubevirt. Commercial support and tooling are available from multiple vendors.

The evolution of KubeVirt

Since the project got started in 2017, KubeVirt has grown in a number of ways.

“KubeVirt started with the goal of bringing VMs into Kubernetes, enabling the automation and scaling concepts of Kubernetes for virtual machines, providing a faster development lifecycle regardless of what technology the application was deployed to,” Sachin Mullick, senior manager, Red Hat OpenShift Virtualization, told Network World. “This vision continues, but we have seen it expand to address infrastructure requirements with rapid innovations, not just in KubeVirt but also adjacent ecosystem projects.”

Mullick noted that projects like medik8s, NMstate and OVN-Kubernetes have provided high availability and advanced networking features for virtual machines. Features like hot-plug and resource overcommit were delivered over the last couple of years, coming out of the strong focus on ensuring virtualization admins have a feature rich experience. 

“The rapid growth of Kubernetes and its ecosystem will bring additional features like confidential computing to virtualization,” he said.

How does KubeVirt work?

KubeVirt works by enabling what is known as container-native virtualization. Basically what that means is KubeVirt allows VMs to run inside of container pods.

From a functional perspective, there are several key aspects to the KubeVirt architecture including:

• Customer Resource Definitions (CRDs): KubeVirt extends the Kubernetes API through CRDs. CRDs allow Kubernetes to run different types of resources. The CRD for KubeVirt is specifically configured to handle VM-related objects, enabling users to define VMs with specifications like CPU, memory and network interfaces.
• Virt-api-server: This is the entry point for all virtualization-related operations, handling the validation and processing of virtual machine image (VMI) resources before they enter the system.
• virt-controller: This Kubernetes Operator, responsible for cluster-wide logic, manages the lifecycle of VMs, including creation and scheduling. It reacts to new VM objects posted to the API server, creating the necessary Kubernetes pods.
• virt-launcher: For each VMI object, KubeVirt creates a corresponding pod that runs the virt-launcher component, which uses libvirtd to start and manage the actual virtual machine process within the containerized environment.
• virt-handlers: These are Kubernetes system daemons that run on each node, handling node-specific operations such as launching and configuring VMs. They work alongside the kubelet (which is a process that run on each node in a cluster), ensuring VMs are aligned with the desired state.

Since VMs are just another resource type (thanks to CRD), they are functionally encapsulated within Kubernetes pods. As such they benefit from pod networking and storage, managed through standard Kubernetes tools like kubectl. 

What can you do with KubeVirt?

KubeVirt enables several key capabilities:

• Run. Run traditional VM workloads alongside containerized applications in Kubernetes clusters.
• Manage. Manage both VMs and containers using the same Kubernetes tools and workflows.
• Migrate. Migrate legacy applications to a cloud-native environment without immediate containerization.
• Optimize. Optimize resource utilization by running VMs and containers on the same underlying hardware.
• Evolve. Gradually decompose and rewrite VMs into microservices, increasing platform density and saving on dual platform and management costs.

Benefits of KubeVirt

Like any other technology, KubeVirt offers users and organizations benefits as well as posing some challenges. Among the benefits are:

• Unified management. Simplifies operations by providing a single platform for both VM and container workloads. This reduces the complexity of managing separate environments for VMs and containers.
• Resource efficiency. Optimizes infrastructure utilization and potentially reduces costs. KubeVirt offers higher workload density compared to traditional VMs.
• Performance. KubeVirt can more rapidly adjust to changing CPU requirements and memory allocation, resulting in lower latency when compared to traditional virtualization solutions.
• Built-in security. KubeVirt takes advantage of Kubernetes-native security, ensuring that policies are applied consistently across all environments, including virtual machines.
• Deployment environments. Kubernetes is widely supported across all major public cloud providers making it easier to deploy KubeVirt workloads.

KubeVirt challenges

• Learning curve. Though KubeVirt claims to have feature parity with traditional VM technologies like VMware, teams may need to adapt to new tools and processes for managing VMs in a Kubernetes environment.
• Performance overhead. Running VMs inside containers may introduce some performance penalties compared to bare-metal virtualization.
• Complex migration. Migrating existing VM workloads to KubeVirt may require careful planning and execution to ensure smooth transitions.

How can KubeVirt be used for VMware migrations?

KubeVirt can facilitate the migration of VMware-based workloads to a Kubernetes environment through two primary approaches:

• Lift-and-shift migration: This method involves replicating VMs from VMware to KubeVirt with minimal changes. It’s faster and reduces risk but may require some modifications for legacy applications.
• Rebuilding VMs: This approach entails creating new VMs in KubeVirt and migrating the application and data. While more time-consuming, it offers opportunities for optimization and improvement.

The migration process typically involves assessing the current VMware environment, setting up a Kubernetes cluster with KubeVirt, and then transferring VM disk images using tools like virt-v2v or virt-p2v.

Forbes Guthrie, director of product management, SUSE virtualization and storage, told Network World that SUSE has seen a lot of interest in its KubeVirt-based tools. That includes the SUSE Virtualization product, which is part of Rancher Prime and provides a platform for customers who want to run both VMs and containers. SUSE Edge also utilizes KubeVirt for its small footprint Edge-based deployments. Guthrie noted that SUSE has its own VM-Import tool, which allows users to import their virtual machines from VMware and OpenStack into SUSE Virtualization.

“We encourage customers to evaluate their workloads as they progress through their modernization journey from other platforms and decide if each workload’s destination should be a virtual machine or a container,” Guthrie said.

Ever since Broadcom acquired VMware, with all of its resulting fallout and uncertainty, there has been an uptick of interest in KubeVirt overall. (Read our related feature: Enterprises reevaluate virtualization strategies amid Broadcom uncertainty)

“We have seen a multiple fold increase in adoption and usage of KubeVirt and its ecosystem over the last year, and the level of interest continues in 2025,” Red Hat’s Mullick said. “Many customers are looking for alternatives to their current virtualization hypervisor, and KubeVirt provides them a viable path forward.”

For migrating workloads, Guthrie noted that he sees organizations leveraging Red Hat’s Migration Toolkit for Virtualization. That toolkits is based on the community Forklift project, that inventories virtualization environments and can cold or warm migrate virtual machines to the new platform. 

“For larger environments, we see customers work with us to assess the entire virtualization environment and come up with a phased migration approach that can be based on many factors in order to de-risk the migration and match their business cycles, yet still achieve their overall timelines to migrate into the new environment,” Guthrie said.