Virtualisierung
KubeVirt / OpenShift Virtualization
KubeVirt erweitert Kubernetes um virtuelle Maschinen als gleichberechtigte Workloads; OpenShift Virtualization ist das darauf aufbauende, supportete Red-Hat-Produkt.
- VMs als Kubernetes-Workload
- CNCF-Projekt (Apache 2.0)
- VMs und Container auf einer Plattform
- libvirt/QEMU/KVM im Pod
- OpenShift Virtualization als Produkt
KubeVirt bringt virtuelle Maschinen in Kubernetes hinein: nicht als Fremdkörper, sondern als gleichberechtigte Workloads neben Containern. Eine VM wird zu einem Kubernetes-Objekt, das über dieselbe API, dasselbe Scheduling, dieselbe Rechteverwaltung läuft wie ein Container. Das von Red Hat gestartete und an die CNCF übergebene Projekt ist die Basis des supporteten Produkts OpenShift Virtualization.
Dieser Artikel erklärt, wie VMs über Custom Resources in Kubernetes abgebildet werden, welche Komponenten dahinterstehen und dass am Ende libvirt und QEMU/KVM im Pod arbeiten, wie Storage und Live-Migration funktionieren, welche Netzwerk- und Hardware-Voraussetzungen gelten, was OpenShift Virtualization samt VMware-Migration ergänzt und wo die Grenzen liegen.
1. VMs als Kubernetes-Objekt
KubeVirt erweitert Kubernetes über Custom Resource Definitions um zwei zentrale Objekte: die VirtualMachine als dauerhafte Definition (mit Start/Stopp-Logik, vergleichbar einem StatefulSet) und die VirtualMachineInstance als laufende Instanz (vergleichbar einem Pod). Eine VM wird damit in YAML beschrieben, versioniert und in Pipelines verwaltet, genau wie containerbasierte Workloads.
Eine VM als Custom Resource (gekürzt)
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: web01
spec:
running: true
template:
spec:
domain:
cpu: { cores: 2 }
memory: { guest: 4Gi }
devices:
disks:
- name: rootdisk
disk: { bus: virtio }
volumes:
- name: rootdisk
dataVolume: { name: web01-root }2. Was unter der Haube läuft
KubeVirt erfindet keinen neuen Hypervisor, es nutzt den bewährten Linux-Stack. Mehrere Komponenten greifen ineinander: virt-api (API-Server für die VM-Objekte), virt-controller (clusterweite VM-Logik), virt-handler (ein Agent je Knoten) und je laufender VM ein virt-launcher-Pod. In genau diesem Pod laufen libvirt und der QEMU/KVM-Prozess. Jede VM ist also ein normaler Linux-Prozess, isoliert durch die Kubernetes-Mechanismen und die Hardware-Virtualisierung darunter.
3. Storage und Live-Migration
VM-Disks kommen über den Containerized Data Importer (CDI) in den Cluster, der Images aus dem Web, aus einer Registry oder per Upload in PersistentVolumes lädt (DataVolumes). Die VM bindet diese als PVC ein. Wichtig für die Praxis: Live-Migration setzt voraus, dass die Disk gleichzeitig von Quell- und Zielknoten beschreibbar ist, also einen Speicher mit ReadWriteMany-Zugriff (etwa Ceph RBD im Block-Modus). Mit reinem ReadWriteOnce-Speicher ist keine Live-Migration möglich.
4. Netzwerk und Hardware-Voraussetzung
Netzwerkseitig hängt eine VM standardmäßig am Pod-Netz (Masquerade-NAT) oder direkt an einer Bridge; über Multus lassen sich zusätzliche Schnittstellen anbinden, für hohen Durchsatz auch per SR-IOV. Eine harte Voraussetzung ist die Hardware-Virtualisierung auf den Knoten: KubeVirt braucht Intel VT-x oder AMD-V, also Bare-Metal-Knoten oder eine Cloud-Instanz mit durchgereichter Virtualisierung (nested). Reine Software-Emulation ist möglich, aber nicht für Produktion gedacht.
5. OpenShift Virtualization und VMware-Migration
OpenShift Virtualization ist das von Red Hat supportete Produkt auf KubeVirt-Basis, installiert als Operator. Besonders relevant ist das mitgelieferte Migration Toolkit for Virtualization (auf dem Open-Source-Projekt Forklift): Es migriert VMs aus vSphere, auch als Warm Migration, bei der die Quell-VM während des Vorkopierens weiterläuft und nur die geänderten Blöcke (über Changed Block Tracking) nachgezogen werden. Das macht KubeVirt zu einem konkreten Ziel für den Ausstieg aus VMware, sofern Kubernetes als Plattform gewünscht ist.
6. Sicherheit
Die VM-Isolation ruht auf mehreren Schichten: die Hardware-Virtualisierung von KVM, die Pod-Isolation durch Namespaces und cgroups sowie eine eigene SELinux-Policy, die jedem virt-launcher-Pod eindeutige Sicherheitskategorien zuweist, sodass keine zwei VMs auf einem Knoten dieselben teilen. KubeVirt strebt einen möglichst wenig privilegierten Betrieb an. Das Projekt hat 2025 zudem seinen ersten externen Sicherheitsaudit durchlaufen; die Befunde wurden vorab offengelegt und in aktuellen Releases behoben, ein Zeichen wachsender Reife.
7. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| VMs und Container auf einer Plattform, ein Steuerstand | setzt volle Kubernetes-Komplexität voraus |
| VMs als versionierbare Manifeste, GitOps-fähig | Live-Migration erfordert RWX-fähigen Speicher |
| Konkreter VMware-Ausweg (Warm Migration via Forklift) | Bare-Metal oder nested Virtualisierung nötig |
| Nutzt den bewährten libvirt/QEMU/KVM-Stack | Netzwerk (Multus, SR-IOV) braucht eigene Expertise |
| Offen (CNCF), supportet über OpenShift Virtualization | kein Ersatz für reine VM-Häuser ohne Kubernetes |
Häufige Fragen zu KubeVirt / OpenShift Virtualization
Nur dort, wo Kubernetes ohnehin die Plattform ist. KubeVirt bringt VMs in Kubernetes hinein, mit gemeinsamem Scheduling, Netzwerk und RBAC. Wer keine Container-Plattform betreibt und nur VMs braucht, fährt mit OLVM, Proxmox VE oder vSphere einfacher, weil KubeVirt die volle Kubernetes-Komplexität voraussetzt.
KubeVirt ist das quelloffene CNCF-Projekt, das Kubernetes um VMs erweitert. OpenShift Virtualization ist das darauf aufbauende, von Red Hat supportete Produkt, installiert als Operator und ergänzt um Werkzeuge wie das Migration Toolkit for Virtualization für den Umzug von VMware.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
KubeVirt / OpenShift Virtualization im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.