Container & Kubernetes

VMs auf Kubernetes betreiben: Wann KubeVirt für dich die richtige VMware-Alternative ist

KubeVirt lohnt sich, wenn du ohnehin Kubernetes betreibst und die letzten VMs nicht in einer zweiten Plattform pflegen willst. Als reiner vSphere-Ersatz ohne bestehendes Cluster-Know-how ist es der aufwendigere Weg, nicht der einfachere.

6 Kapitel mit allen Befehlen
DevOps-Engineer erklärt einem Kollegen Container-Dashboards am Stehtisch
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Zwei Plattformen für dasselbe Rechenzentrum

In den meisten Umgebungen ist die Ausgangslage identisch: Container laufen längst auf Kubernetes, die klassischen Workloads liegen aber weiter auf vSphere. Das bedeutet zwei Scheduler, zwei Rechte- und Netzkonzepte, zwei Backup-Ketten und zwei Betriebsteams, die sich gegenseitig erklären müssen, warum eine Anwendung gerade nicht erreichbar ist. Sobald die Lizenzbedingungen der bestehenden Virtualisierung neu verhandelt werden, steht die Frage im Raum, ob dieser doppelte Unterbau noch sinnvoll ist.

KubeVirt setzt genau dort an: Eine virtuelle Maschine wird zu einem Kubernetes-Objekt vom Typ VirtualMachine, QEMU und libvirt laufen in einem virt-launcher-Pod, und Scheduling, RBAC, Namespaces, Monitoring und GitOps greifen für VMs genauso wie für Container. Für Organisationen mit vorhandenem Cluster oder OpenShift ist das oft der strategisch sauberere Weg, weil er die Plattform konsolidiert statt eine zweite aufzubauen.

Der typische Fehler ist, KubeVirt als direkten Funktionsersatz für vSphere zu planen. Es gibt kein DRS, das Lasten automatisch ausbalanciert, kein gewachsenes vCenter-Rollenmodell und keine Storage-Features, die dir jeder Array-Hersteller schon fertig mitliefert. Wer ohne ReadWriteMany-fähiges Block-Storage startet, wundert sich später über fehlende Live-Migration. Und wer noch kein Team hat, das Kubernetes im Betrieb wirklich beherrscht, verlagert seine Komplexität nur, statt sie zu reduzieren.

Miniatur-Szene: Hafen mit gestapelten Containern, ein Kran hebt einen davon an, daneben ein Steuerrad
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Von der vSphere-VM zum VirtualMachine-Objekt

  1. 01 Inventar und Eignung bewerten
  2. 02 Nodes mit KVM bereitstellen
  3. 03 RWX-Block-Storage aufbauen
  4. 04 Netze über Multus anbinden
  5. 05 Disks per CDI importieren
  6. 06 Live-Migration und Backup testen
Was du mitnimmst

So gehst du die Entscheidung und die Migration an

Die Bewertung läuft in zwei Schritten: Zuerst klärst du ehrlich, ob deine Plattform- und Storage-Basis für VMs taugt, danach planst du den technischen Weg. Diese Punkte bearbeitest du in unserer KubeVirt Schulung zur Kubernetes-Virtualisierung, bei OpenShift Virtualization ergänzt um die Grundlagen aus DO180 und DO280.

Ehrlich prüfen, ob KubeVirt zu deiner Ausgangslage passt

KubeVirt lohnt sich, wenn du Kubernetes bereits produktiv betreibst und deine VMs mittelfristig ohnehin containerisiert werden sollen. Betreibst du fast ausschließlich VMs und kein nennenswertes Container-Portfolio, ist ein klassischer Hypervisor wie Proxmox der geradere Weg. Diese Abwägung solltest du treffen, bevor du das erste Testsystem installierst.

Nodes und Hardware vorbereiten

Die Worker-Nodes brauchen echte KVM-Unterstützung, also entweder Bare Metal oder eine Umgebung mit funktionierender nested virtualization. Dazu kommen genug RAM-Reserven, saubere NUMA- und Hugepages-Konfiguration für latenzsensible Gäste sowie die Frage, welche Nodes über Taints ausschließlich VMs tragen sollen.

Storage als Kernentscheidung behandeln

Persistente Disks kommen als PersistentVolumeClaims über eine CSI-Klasse. Für Live-Migration brauchst du ReadWriteMany im Block-Modus, in der Praxis meist Ceph über Rook oder OpenShift Data Foundation. Snapshots laufen über VolumeSnapshots, Backups über Velero mit passendem Plugin, nicht über die Werkzeuge, die du aus der vSphere-Welt kennst.

Netzwerk und Adressen sauber planen

Das Pod-Netz reicht für viele VMs nicht aus, weil Altanwendungen feste IP-Adressen, VLANs oder Layer-2-Nachbarschaften erwarten. Über Multus hängst du zusätzliche Interfaces an, etwa per bridge oder SR-IOV, und legst fest, wie Services, Ingress und externe Firewall-Regeln zusammenspielen.

Disks importieren statt VMs neu bauen

Der Containerized Data Importer holt bestehende Images aus HTTP-Quellen, Registries oder Upload in einen PVC. Für den Weg von vSphere gibt es mit Forklift beziehungsweise der Migration Toolkit for Virtualization eine gesteuerte Variante inklusive Inventar und Cutover. Windows-Gäste brauchen vorher die passenden virtio-Treiber, sonst startet die VM nach dem Import nicht sauber.

Betrieb, Rollen und Automatisierung festlegen

VMs werden als Manifeste verwaltet, damit passen GitOps mit Argo CD oder Flux, Policies mit Kyverno und Monitoring mit Prometheus direkt auf die Virtualisierung. Gleichzeitig musst du klären, wer per RBAC eine VM starten, konsolen-verbinden oder migrieren darf, und wie Patchfenster für Cluster-Upgrades mit laufenden VMs zusammengehen.

Tutorial

Von der Node-Prüfung bis zur ersten migrierten VM

Der Ablauf folgt der Reihenfolge, in der du es auch im Rechenzentrum machst: erst prüfen, ob die Nodes überhaupt taugen, dann KubeVirt und den Import-Dienst einrichten, danach Storage und Netz festlegen. Erst ganz am Ende wandert die erste Disk. Der Betriebsteil beantwortet, was beim Node-Neustart mit deinen VMs passiert.

01

Nodes prüfen, bevor du irgendetwas installierst

KubeVirt startet die VMs als QEMU-Prozess in einem Pod. Ohne Hardware-Virtualisierung auf dem Node läuft das nur in Emulation, und die ist für Produktion unbrauchbar.

Virtualisierungsfähigkeit je Worker prüfen
# Auf jedem Node, der VMs tragen soll
grep -Ec 'vmx|svm' /proc/cpuinfo
ls -l /dev/kvm

# Ausführlicher Check aus den libvirt-Tools
sudo dnf install -y libvirt-client     # RHEL/Rocky/Alma
sudo apt install -y libvirt-clients    # Debian/Ubuntu
sudo virt-host-validate qemu

virt-host-validate meldet fehlendes /dev/kvm, fehlende IOMMU-Unterstützung und cgroup-Controller, die nicht eingehängt sind. Alles, was dort auf FAIL steht, kostet dich später eine Nacht.

Vor der Installation geklärt

  • CPU-Modelle der Worker sind vergleichbar oder du erzwingst ein gemeinsames CPU-Modell.Live-Migration bricht ab, wenn der Ziel-Node ein CPU-Flag nicht anbietet, das der Gast bereits benutzt. Gemischte Generationen ohne festes CPU-Modell machen Migration zur Glückssache.
  • RAM ist real vorhanden, nicht überbucht.VMs reservieren ihren Speicher als Pod-Request. Die Überbuchung, die du aus vSphere kennst, gibt es hier nicht in derselben Form, und ein OOM-Kill trifft die ganze VM.
  • Die KubeVirt-Version passt zur Kubernetes-Version des Clusters.KubeVirt unterstützt jeweils nur ein Fenster von Kubernetes-Versionen. Ein Cluster-Update ohne Blick auf die Matrix legt im schlimmsten Fall alle VMs gleichzeitig still.
  • Es ist festgelegt, wer den Cluster patcht und wer die VMs verantwortet.Mit KubeVirt wird der Cluster zum Unterbau der VMs. Ein unabgestimmtes Node-Update ist ab sofort ein Eingriff in den VM-Betrieb.
02

KubeVirt und den Datenimporter installieren

Beide Komponenten bestehen aus einem Operator und einer Custom Resource. Ohne den Containerized Data Importer bekommst du keine Disk komfortabel in den Cluster.

Operator und Custom Resource ausrollen
KV=$(curl -s https://api.github.com/repos/kubevirt/kubevirt/releases/latest | jq -r .tag_name)
kubectl apply -f https://github.com/kubevirt/kubevirt/releases/download/${KV}/kubevirt-operator.yaml
kubectl apply -f https://github.com/kubevirt/kubevirt/releases/download/${KV}/kubevirt-cr.yaml
kubectl -n kubevirt wait kv kubevirt --for condition=Available --timeout=900s

# Containerized Data Importer für den Disk-Import
CDI=$(curl -s https://api.github.com/repos/kubevirt/containerized-data-importer/releases/latest | jq -r .tag_name)
kubectl apply -f https://github.com/kubevirt/containerized-data-importer/releases/download/${CDI}/cdi-operator.yaml
kubectl apply -f https://github.com/kubevirt/containerized-data-importer/releases/download/${CDI}/cdi-cr.yaml

kubectl get pods -n kubevirt zeigt danach virt-api, virt-controller und je Node ein virt-handler-Pod. Fehlt der virt-handler auf einem Node, wird dort auch keine VM starten.

virtctl passend zur Cluster-Version installieren
curl -L -o virtctl \
  https://github.com/kubevirt/kubevirt/releases/download/${KV}/virtctl-${KV}-linux-amd64
sudo install -m 0755 virtctl /usr/local/bin/virtctl
virtctl version

# Welche Nodes dürfen VMs aufnehmen?
kubectl get nodes -l kubevirt.io/schedulable=true

virtctl ist kein Ersatz für kubectl, sondern die Ergänzung für alles, was Kubernetes nicht kennt: Konsole, VNC, Migration, Disk-Upload.

03

Storage entscheidet darüber, ob Live-Migration überhaupt geht

Diese Entscheidung fällst du einmal und lebst danach damit. Nachträglich den Storage zu wechseln bedeutet, jede VM erneut zu kopieren.

Für Live-Migration müssen Quell- und Ziel-Node dieselbe Disk gleichzeitig geöffnet haben. Das erzwingt ReadWriteMany. Blockgeräte sind dabei schneller als ein Dateisystem-Layer, weil eine Indirektionsschicht wegfällt.

Storage-Optionen und ihre Folgen

BackendReadWriteManyLive-MigrationAnmerkung
Ceph RBD, volumeMode BlockjajaDer übliche Weg, wenn du ohnehin Ceph betreibst
NFS über CSI-TreiberjajaEinfach einzurichten, kostet IOPS und mag keine Netzaussetzer
iSCSI oder FC über CSI, Blockje nach Treiberje nach TreiberVorher testen, nicht dem Datenblatt glauben
local-path, LVM lokalneinneinVM klebt für immer an ihrem Node
hostPathneinneinNur Lab, keine Produktion
DataVolume mit passenden Storage-Eigenschaften
apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: srv01-root
spec:
  source:
    http:
      url: "http://depot.intern.example.com/images/srv01.qcow2"
  storage:
    storageClassName: ceph-rbd
    accessModes:
      - ReadWriteMany
    volumeMode: Block
    resources:
      requests:
        storage: 80Gi

Der Import läuft als eigener Pod. kubectl get dv -w zeigt den Fortschritt, kubectl logs -l cdi.kubevirt.io=importer die Ursache, wenn er hängt.

04

Netz: der Standardpfad reicht für Altsysteme selten

Im Standard hängt eine VM per masquerade am Pod-Netz und bekommt eine Pod-IP. Für neue Workloads ist das richtig. Ein gewachsener Fileserver mit fester IP und DHCP-Reservierung braucht dagegen Layer 2 im vorhandenen VLAN.

Bridge-Anbindung über Multus
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: vlan120
spec:
  config: '{
    "cniVersion": "0.3.1",
    "name": "vlan120",
    "type": "bridge",
    "bridge": "br-vlan120",
    "ipam": {}
  }'

Leeres ipam heißt: Kubernetes vergibt keine Adresse, die VM holt sie sich wie bisher per DHCP aus dem VLAN. Die Bridge br-vlan120 muss auf jedem Node existieren, auf dem die VM laufen darf, sonst startet sie nur auf der Hälfte des Clusters.

Interface und MAC-Adresse in der VM-Definition
spec:
  template:
    spec:
      domain:
        devices:
          interfaces:
            - name: vlan120
              bridge: {}
              macAddress: "52:54:00:1a:2b:3c"
      networks:
        - name: vlan120
          multus:
            networkName: vlan120

Die MAC-Adresse der alten VM zu übernehmen ist der einfachste Weg, DHCP-Reservierungen, Lizenzbindungen und Firewallregeln unverändert zu lassen.

05

Disks importieren statt VMs neu bauen

Das eigentliche Kopieren ist der leichte Teil. Die Arbeit steckt in der Vorbereitung des Gastsystems, und die erledigst du noch auf der alten Plattform.

Gast vorbereiten, solange er noch auf der alten Plattform läuft
# VMware-Tools deinstallieren, qemu-guest-agent installieren
sudo dnf install -y qemu-guest-agent    # RHEL/Rocky/Alma
sudo apt install -y qemu-guest-agent    # Debian/Ubuntu
sudo systemctl enable qemu-guest-agent

# virtio-Treiber müssen in die Initramfs, sonst findet der Kernel die Rootdisk nicht
sudo dracut --regenerate-all --force            # RHEL/Rocky/Alma
sudo update-initramfs -u -k all                 # Debian/Ubuntu

# Kontrolle
lsinitrd | grep -E 'virtio_(blk|scsi|net)'                       # RHEL/Rocky/Alma
lsinitramfs /boot/initrd.img-$(uname -r) | grep -E 'virtio'      # Debian/Ubuntu

Der Gast-Agent meldet später IP-Adressen an Kubernetes und ermöglicht ein sauberes Herunterfahren. Ohne ihn siehst du in kubectl get vmi -o wide keine Gast-IP.

Disk konvertieren und hochladen
# VMDK in qcow2 wandeln, -p zeigt den Fortschritt
qemu-img convert -p -f vmdk -O qcow2 srv01.vmdk srv01.qcow2
qemu-img info srv01.qcow2

# Upload in ein DataVolume, der cdi-uploadproxy muss erreichbar sein
virtctl image-upload dv srv01-root \
  --size=80Gi \
  --storage-class=ceph-rbd \
  --image-path=./srv01.qcow2 \
  --uploadproxy-url=https://cdi-uploadproxy.apps.intern.example.com

Bei einem selbst signierten Zertifikat am Uploadproxy brauchst du zusätzlich --insecure. Snapshots der Quell-VM vorher konsolidieren, sonst konvertierst du eine Kette aus Delta-Dateien und wunderst dich über den fehlenden Datenstand.

06

Betrieb: Migration, Node-Wartung und Rollen

Ab hier zählt nur noch, ob dein Cluster ein Node-Update übersteht, ohne dass jemand die VMs von Hand einsammelt.

Migration auslösen und beobachten
virtctl migrate srv01
kubectl get vmim -w                  # VirtualMachineInstanceMigration
kubectl get vmi -o wide              # auf welchem Node läuft die VM jetzt?

virtctl console srv01                # serielle Konsole, Abbruch mit Strg+]
virtctl vnc srv01                    # grafische Konsole
virtctl stop srv01 && virtctl start srv01

Schlägt eine Migration fehl, steht der Grund in den Events des VMIM-Objekts: kubectl describe vmim. Häufigste Ursachen sind fehlendes ReadWriteMany und ein nicht migrierbares Gerät an der VM.

Eviction-Strategie setzen, sonst killt der Drain die VM
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: srv01
spec:
  running: true
  template:
    spec:
      evictionStrategy: LiveMigrate
      domain:
        cpu:
          cores: 4
        memory:
          guest: 8Gi

Ohne evictionStrategy: LiveMigrate behandelt kubectl drain die VM wie einen beliebigen Pod und beendet sie. Du kannst die Strategie auch clusterweit in der KubeVirt-Custom-Resource unter spec.configuration vorgeben.

Rollen, die du früh vergibst

  • kubevirt.io:admin für das Team, das VMs anlegt und löscht, gebunden an den Namespace des jeweiligen Bereichs
  • kubevirt.io:edit für alle, die VMs starten, stoppen und die Konsole brauchen, aber nichts anlegen sollen
  • kubevirt.io:view für Monitoring und Servicedesk
  • Namespaces als Mandantengrenze nutzen, denn Netzwerk- und Storage-Zuweisung hängen daran

Plane den Rückweg mit ein. Solange die Quellplattform noch steht, ist ein Rollback ein Start der alten VM. Lösche die Originale erst, wenn die migrierte VM einen kompletten Backup- und Restore-Zyklus im neuen Umfeld überstanden hat.

Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Gut zu wissen

Häufige Fragen zu VMs auf Kubernetes mit KubeVirt

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Was ist KubeVirt und wie führt es virtuelle Maschinen aus?
KubeVirt ist eine Erweiterung von Kubernetes, die den Objekttyp VirtualMachine per Custom Resource Definition ergänzt. Jede laufende VM steckt in einem virt-launcher-Pod, in dem libvirt und QEMU auf dem KVM-Modul des Nodes arbeiten. Dadurch greifen Scheduling, Namespaces, RBAC, Netzwerk-Policies und Monitoring auf VMs genauso wie auf Container.
Was ist der Unterschied zwischen KubeVirt und OpenShift Virtualization?
OpenShift Virtualization ist die von Red Hat unterstützte und integrierte Distribution von KubeVirt. Der technische Kern ist derselbe, du bekommst aber Support, eine abgestimmte Storage- und Netzwerkbasis sowie die Migrationswerkzeuge mit dazu. Wer den Weg über OpenShift geht, baut das Grundwissen sinnvollerweise über DO180 und DO280 auf, während die reine Upstream-Variante in unserer KubeVirt Schulung im Mittelpunkt steht.
KubeVirt oder Proxmox als VMware-Alternative?
Das hängt davon ab, wo dein Schwerpunkt liegt. Proxmox ist ein klassischer Hypervisor mit KVM, LXC und Ceph und fühlt sich für reine VM-Landschaften vertrauter an, weshalb Teams ohne Kubernetes-Betrieb damit meist schneller produktiv werden. KubeVirt lohnt sich, wenn du Kubernetes ohnehin betreibst und beide Welten unter einer Control Plane zusammenführen willst. Für den Hypervisor-Weg haben wir den Proxmox Grundkurs, den Proxmox Aufbaukurs zu Cluster, Ceph und High Availability sowie den Kurs zur Migration von VMware zu Proxmox im Programm.
Funktioniert Live-Migration unter KubeVirt?
Ja, KubeVirt beherrscht Live-Migration zwischen Nodes, stellt dafür aber Bedingungen. Die Disks müssen als ReadWriteMany im Block-Modus verfügbar sein, die Nodes brauchen kompatible CPU-Modelle, und sehr spezielle Zuweisungen wie durchgereichte PCI-Geräte schließen eine Migration aus. Ein automatischer Lastausgleich im Stil von DRS ist nicht enthalten, entsprechende Umverteilung musst du über Descheduler oder eigene Regeln lösen.
Welche Vorkenntnisse braucht mein Team dafür?
Solides Kubernetes-Grundwissen ist Voraussetzung, also Pods, Deployments, Storage-Klassen, RBAC und Cluster-Betrieb. Wenn das noch fehlt, sind der Kubernetes Grundkurs oder die Vorbereitung zum Certified Kubernetes Administrator der bessere Startpunkt. Auf dieser Basis kommt das Virtualisierungswissen dazu, und dein bestehendes Hypervisor-Know-how bleibt bei Themen wie Storage-Layout, Netzsegmentierung und Gastsystem-Tuning weiter wertvoll.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Sehr kompetenter Dozent der gut auf alle Fragen eingegangen ist.
Rückmeldung aus dem Kurs „Kubernetes Grundkurs“
Qualitativ sehr guter Kurs. Ruhiger und wertschätzender Umgang. Keine Informationsüberlastung.
Rückmeldung aus dem Kurs „Ansible Kompaktkurs“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Sprich mit uns über deinen Weg zur konsolidierten Plattform

In der KubeVirt Schulung von cmt baust du ein Cluster auf, importierst bestehende Disks und testest Live-Migration, Snapshots und Betriebsabläufe an echten Systemen. Alle Kurse laufen als Präsenztermin, Live-Online oder als Inhouse-Schulung mit deiner eigenen Ausgangslage. Wenn du noch zwischen KubeVirt, OpenShift Virtualization und Proxmox abwägst, gehen wir das im Gespräch gemeinsam durch und sagen dir auch, wenn ein anderer Weg besser passt.