Can Kubernetes run VMs, and how does KubeVirt compare with Proxmox?
Yes. KubeVirt, a CNCF graduated project, adds virtual machines to Kubernetes as custom resources and runs each VM inside a Pod, so VMs and containers share one control plane, one network and one storage layer. Proxmox VE is a standalone virtualization platform built around VMs and LXC containers, with its own web interface and clustering. KubeVirt suits teams that want to consolidate onto Kubernetes; Proxmox is simpler for teams whose work is mostly VMs.
How KubeVirt works
KubeVirt extends the Kubernetes API with resources such as VirtualMachine and VirtualMachineInstance. You define a VM in YAML, apply it with kubectl and manage it with the same tools you use for Deployments.
Under the hood, a cluster-wide virt-controller schedules each VM, and a virt-handler daemon on every node starts it. Each VM runs in its own virt-launcher Pod, which uses a libvirt daemon for QEMU inside the Pod to start the virtual machine. Because the VM is a Pod, the scheduler, resource requests, node selectors, network policies and persistent volume claims all apply to it. Nodes should support hardware virtualization (/dev/kvm); the installation guide offers a software emulation fallback, which is slow and meant for testing.
Red Hat created KubeVirt in 2016, and it became a CNCF graduated project on November 10, 2026. Red Hat OpenShift Virtualization and the open-source Harvester platform are built on it.
What KubeVirt needs from the cluster
- Storage. VM disks are persistent volumes. Live migration requires volumes with the
ReadWriteManyaccess mode, so a node can be drained without stopping the VM. Block storage that only supportsReadWriteOncemeans VMs restart instead of migrating. - Networking. By default a VM gets an address on the Pod network. VMs that need to sit on an existing VLAN or keep their old IP addresses use a secondary network through Multus and a Linux bridge. A bridge binding on the Pod network blocks live migration.
- Migration tooling. Forklift, the upstream of Red Hat’s Migration Toolkit for Virtualization, imports VMs from VMware vSphere, oVirt, OpenStack and OVA files.
KubeVirt vs Proxmox VE
| Aspect | KubeVirt | Proxmox VE |
|---|---|---|
| What it is | A Kubernetes add-on | A complete virtualization platform installed on the server |
| Hypervisor | KVM through QEMU and libvirt | KVM through QEMU, plus LXC containers |
| Day-to-day interface | kubectl, YAML and GitOps; a web UI through OpenShift or Harvester |
Built-in web interface, CLI and REST API |
| Scheduling | The Kubernetes scheduler, with affinity and resource requests | Placement by the administrator or high-availability rules |
| Storage | Any CSI driver; ReadWriteMany for live migration |
Built-in support for ZFS, Ceph, LVM, NFS and iSCSI |
| Import from VMware | Forklift | Built-in ESXi import wizard since Proxmox VE 8.2 |
| Skills required | Kubernetes first, virtualization second | Linux and virtualization |
| Fits | Teams consolidating VMs onto an existing Kubernetes platform | VM-first teams, small clusters, mixed workloads managed by hand |
The two are not exclusive. Many teams run Proxmox as the hypervisor and Kubernetes nodes as VMs on it, which is the setup in the Proxmox Kubernetes tutorial. For the broader comparison of the two technologies, see Proxmox vs Kubernetes.
When to run VMs on Kubernetes
KubeVirt pays off when most new work already runs in containers and a set of VMs remains: a legacy application, a Windows service, an appliance from a vendor. Moving those VMs onto the cluster removes a second platform, with its own monitoring, access control, backup and patching. VMs and containers can then talk over the cluster network and be deployed from the same pipelines.
It is a weaker fit when VMs are the majority of the estate and the team does not run Kubernetes yet. In that case, KubeVirt adds Kubernetes, a CSI storage layer and Multus networking on top of the original problem. Teams leaving VMware often start with a hypervisor swap and adopt Kubernetes for applications they containerize, as described in VMware alternatives.
When to keep a hypervisor under Kubernetes
Running Kubernetes nodes as VMs on Proxmox, vSphere or another hypervisor is the common default on-premises. It gives fast node replacement from templates, snapshots before upgrades and smaller nodes on large servers. Bare-metal nodes remove the hypervisor layer and give direct access to GPUs and network cards; the bare metal vs virtual machines comparison goes through the trade-offs. If you need to understand the basic difference first, read containers vs virtual machines.
How Cloudfleet fits
Cloudfleet Kubernetes Engine (CFKE) accepts Proxmox VE virtual machines as cluster nodes, created with Terraform and registered automatically through cloud-init, next to bare-metal servers and cloud nodes in the same cluster. See Proxmox nodes in CFKE.