Why Organizations Are Moving VMs into Kubernetes

▶ Watch (0:52)

Around 60% of workloads still run on virtual machines. Many Kubernetes clusters themselves run on VMs. VMware dominates the hypervisor market, but vendor lock-in concerns are pushing teams toward alternatives. KubeVirt, a CNCF open source project with Red Hat as its primary maintainer, lets teams manage VMs through the same Kubernetes API they already use for containers. Teams skilled on Kubernetes can then own both VMs and pods without splitting into separate operations groups.

KubeVirt Architecture: Three Components and the virt-launcher Pod

▶ Watch (5:27)

KubeVirt installs as a cluster add-on with three components. The virt-api intercepts VM creation requests. The virt-controller watches VM objects and manages their lifecycle. The virt-handler runs as a DaemonSet, one pod per node, and manages the libvirt or QEMU process on each node. When a VM is deployed, a fourth component appears: the virt-launcher pod. This pod bridges Kubernetes networking and storage to the VM itself. Deleting the virt-launcher pod kills the VM. VM lifecycle is tightly bound to pod lifecycle.

Networking: Cilium vs. Kube-OVN and the Static IP Problem

▶ Watch (18:02)

Tragni compared two CNIs for VM workloads. Cilium uses eBPF, performs well, and suits DevOps teams, but until recently did not preserve a VM’s IP during live migration. Kube-OVN supports subnets, static IPs, and VLANs, making it familiar to network engineers but operationally heavier. Kube-OVN preserves static IP across live migration today. Cilium is implementing the same feature, though the IP-preservation capability sits in the Isovalent enterprise tier for now. Calico announced the same feature the day before this talk. His prior advice to choose based on workload mix no longer holds once both CNIs reach parity.

Six Limitations to Know Before Committing

▶ Watch (23:31)

Live migration is fragile compared to VMware DRS. Storage volumes must be read-write-many so both source and destination nodes can access the disk simultaneously during migration. Kubernetes eviction timeout defaults to 300 seconds, which is too long for VMs. Device pass-through locks a VM to one node, removing Kubernetes scheduling flexibility. Disaster recovery is self-managed: no HA equivalent ships with KubeVirt, so teams must add Kasten, Velero, or a GitOps approach. MAC-address-bound software licenses break entirely because Kubernetes operates at layer three, not layer two.

Production Readiness: Real Use Cases from Schwarz Digit

▶ Watch (21:57)

Three workload types migrate well today. Legacy Windows VMs that cannot be containerized move into KubeVirt and stay as VMs. Telco workloads benefit from Kubernetes’s fast pod scheduling to spin VMs quickly. Ephemeral Kubernetes control planes can run as VMs inside an existing cluster, enabling nested cluster topologies. These use cases come from Schwarz Digit, an early KubeVirt adopter in production. Tragni put the minimum time to a stable alpha deployment at 18 months. Multicast-heavy applications and MAC-licensed software remain poor fits.

Q&A

Does running VMs inside Kubernetes always mean nested virtualization? Not necessarily. If Kubernetes runs on bare metal, the VMs are first-level, not nested, though high read-write workloads can add latency. ▶ 29:04

Does live migration actually preserve the IP address visible outside the pod? The IP inside the VM is kept, but the pod’s external IP changes on migration, which is the core issue KubeVirt CNI and Cilium’s upcoming bridge-network feature aim to fix. ▶ 30:10

What is the biggest barrier to a single control plane for all infrastructure? Management and contractual inertia, not technical gaps. Existing vendor deals and fear of migrating critical applications slow adoption more than any missing feature. ▶ 32:29

Notable Quotes

we still have around maybe I will say 60% overall of the workload is still going on virtual machine Evangelista Tragni · ▶ 2:09

the virtual machine in Kubernetes are just pods okay because what you need to care mainly is the life the pod life itself Evangelista Tragni · ▶ 7:22

live migration is a little bit uh fragile, so not really strong and backed in this case Evangelista Tragni · ▶ 23:55

I think that in this case, a lot can be like a management problem to migrate to a unified platform, okay? That rule everything. Evangelista Tragni · ▶ 33:03

Key Takeaways

  • KubeVirt VMs are pods: deleting the virt-launcher pod terminates the VM immediately.
  • Live migration requires read-write-many storage and a reduced Kubernetes eviction timeout below 300 seconds.
  • Plan at least 18 months of alpha runtime before treating a KubeVirt deployment as production-grade.

About the Speaker(s)

Evangelista Tragni is a Lead DevOps Engineer at Devoteam. He holds CNCF Kubestronaut status, vExpert 2026 recognition, and instructor certifications from the Linux Foundation, VMware, and AWS. His work spans DevOps and cloud infrastructure across Luxembourg, Germany, and other European deployments.