OpenShift Virtualization (built on the open-source KubeVirt project) lets you run traditional VMs directly on OpenShift, right next to your containers. Same control plane, same API, same RBAC, same GitOps pipeline. There’s no separate hypervisor cluster to run and no second team to staff for it.
The part that took me a while to accept is how a VM actually runs.
A VM lives inside a special pod called virt-launcher. Inside that pod, QEMU and libvirt talk to KVM, the hypervisor that’s already built into the Linux kernel on every RHEL CoreOS node. Because KVM sits in the kernel, the VM gets close to native performance. It’s real virtualization, not emulation. And as far as Kubernetes is concerned, that VM is just another workload, so it inherits scheduling, monitoring, and networking for free. You define it as kind: VirtualMachine and manage it in YAML, the same way you’d manage a deployment.
A few pieces make it usable in production:
Storage: The Containerized Data Importer (CDI) pulls disk images into PVCs, using the same CSI storage your containers already use.
Networking: Multus attaches extra NICs to a VM, so it can sit on the pod network and still reach external VLANs.
Live migration: you can move a running VM between nodes with no downtime, as long as your storage supports ReadWriteMany.
Migration Toolkit for Virtualization (MTV): imports existing VMs from vSphere, RHV, or OpenStack.
So why does this matter? Most companies aren’t close to fully containerized, and they won’t be for years. Databases, legacy apps, and appliances still live in VMs and aren’t going anywhere soon. OpenShift Virtualization means you don’t have to pick a side. You modernize gradually on one platform instead of paying for and running two separate stacks. With everything happening in the traditional virtualization market lately, a lot of teams are looking hard at exactly this.
If you’re running OpenShift Virtualization in production, I’d like to hear what caught you off guard.