Virtualisierung
KVM / QEMU
KVM ist das Virtualisierungsmodul des Linux-Kernels, QEMU der Maschinen-Emulator darüber; zusammen bilden sie die offene Basis von Proxmox VE, OLVM und OpenStack.
- Im Linux-Kernel (GPL)
- Hardware-Virtualisierung (VT-x / AMD-V)
- VirtIO-Paravirtualisierung
- Basis von Proxmox, OLVM, OpenStack
- Isolation per CPU und sVirt
KVM (Kernel-based Virtual Machine) und QEMU sind zwei Bausteine, die zusammen die Standard-Virtualisierung unter Linux bilden. KVM ist ein Kernel-Modul, das die Virtualisierungsfunktionen moderner Prozessoren nutzbar macht und den Linux-Kernel selbst zum Hypervisor erweitert. QEMU ist der Maschinen-Emulator im Userspace, der einer virtuellen Maschine ihre virtuelle Hardware bereitstellt.
Dieser Artikel erklärt das Zusammenspiel beider Komponenten, die Rolle der Hardware-Virtualisierung, die VirtIO-Paravirtualisierung für Performance, die Wahl des CPU-Modells im Hinblick auf Live-Migration, die Machine-Types, das sichere Durchreichen von Geräten per VFIO, die Speichertechniken sowie die Sicherheitsschichten und die Einordnung in die Typ-1/Typ-2-Debatte.
1. Zwei Bausteine, eine Aufgabe
Die Arbeitsteilung ist klar: KVM stellt über das Gerät /dev/kvm die Schnittstelle zur Hardware-Virtualisierung bereit und führt den Gastcode direkt auf der realen CPU aus. QEMU läuft als normaler Prozess im Userspace, modelliert die virtuelle Hardware (Festplattencontroller, Netzwerkkarte, BIOS/UEFI) und koordiniert die VM.
Ohne KVM kann QEMU jede Hardware rein in Software emulieren, das ist aber langsam und nur für fremde Architekturen oder Tests sinnvoll. Mit KVM beschleunigt die CPU die Ausführung, und die VM erreicht nahezu native Geschwindigkeit. KVM ist seit 2007 fester Bestandteil des Linux-Kernels, eine separate Installation entfällt also.
2. Hardware-Virtualisierung als Fundament
KVM setzt auf den Virtualisierungserweiterungen der CPU auf: Intel VT-x (VMX) beziehungsweise AMD-V (SVM). Der Gastcode läuft in einem eigenen, weniger privilegierten Modus direkt auf der CPU. Erst bei sensiblen Operationen (bestimmte Ein-/Ausgaben, Spezialregister) springt die CPU per VM-Exit zurück, KVM behandelt den Fall oder reicht ihn an QEMU weiter. Die Speicherisolation übernimmt die CPU über erweiterte Seitentabellen (EPT bei Intel, NPT bei AMD).
Voraussetzungen prüfen (Linux)
# Unterstützt die CPU Virtualisierung? (Treffer = ja)
egrep -c '(vmx|svm)' /proc/cpuinfo
# Sind die KVM-Module geladen?
lsmod | grep kvm
# kvm_intel bzw. kvm_amd plus kvm3. VirtIO: Paravirtualisierung für Tempo
Emulierte Hardware ist kompatibel, aber langsam. VirtIO ist ein offener, von OASIS standardisierter Paravirtualisierungs-Ansatz: Der Gast weiß, dass er virtualisiert läuft, und spricht über schlanke Ringpuffer direkt mit dem Hypervisor. Wichtige Geräte sind virtio-net (Netz), virtio-blk und virtio-scsi (Storage), virtio-balloon (Speicher) und virtio-fs (Dateifreigabe).
Für noch mehr Durchsatz verlagert vhost-net den Netzwerk-Datenpfad in den Kernel und spart Kontextwechsel; vhost-user reicht ihn an einen Userspace-Prozess wie eine DPDK-Anwendung weiter. In der Praxis gehören VirtIO-Treiber in jeden Gast, der Leistung braucht.
4. CPU-Modell und Live-Migration
Welche CPU der Gast sieht, ist eine bewusste Entscheidung mit Folgen für die Migration:
- host-passthrough reicht die echte Host-CPU mit allen Flags durch, maximale Leistung, aber sichere Live-Migration auf abweichende Hardware ist damit nicht möglich.
- benanntes Modell ein definiertes, stabiles Feature-Set (etwa Skylake-Server oder EPYC), Voraussetzung für Live-Migration über leicht unterschiedliche Hosts hinweg.
- host-model der libvirt-Kompromiss: wählt ein passendes benanntes Modell und ergänzt verfügbare Host-Features, migrationsfreundlich.
In einem Cluster, der Live-Migration können soll, gehört ein einheitliches, benanntes CPU-Modell konfiguriert. host-passthrough liefert das letzte Prozent Leistung, verbaut aber die Verschiebbarkeit der VMs.
5. Machine-Type: q35 statt i440fx
QEMU emuliert einen ganzen Chipsatz. Der moderne Typ q35 bringt einen echten PCIe-Bus, integriertes SATA und bessere ACPI-Unterstützung und ist Voraussetzung für sauberes PCIe-Passthrough. Der historische Typ i440fx kennt nur PCI und wird zunehmend abgekündigt. Für neue VMs ist q35 die richtige Wahl; ein nachträglicher Wechsel will geplant sein, weil sich Gerätepfade im Gast ändern können.
6. Geräte durchreichen: VFIO, IOMMU und SR-IOV
Soll eine VM direkt auf eine echte GPU oder Netzwerkkarte zugreifen, übernimmt das VFIO-Framework des Kernels. Die IOMMU (Intel VT-d, AMD-Vi) sorgt dabei dafür, dass das durchgereichte Gerät per DMA nur den Speicher der VM erreicht, nicht den ganzen Host. Voraussetzungen sind eine aktivierte IOMMU und eine saubere Gruppierung der Geräte.
SR-IOV teilt eine physische Netzwerkkarte in mehrere virtuelle Funktionen auf, die sich einzeln an VMs übergeben lassen, ideal für hohen Netzdurchsatz. Durchgereichte Geräte binden die VM allerdings an die Hardware und schränken die Live-Migration ein.
7. Live-Migration im Betrieb
Bei der Live-Migration überträgt der Quell-Host den Arbeitsspeicher der laufenden VM in mehreren Durchläufen an den Ziel-Host (Pre-Copy) und schickt geänderte Seiten erneut. Sinkt die noch zu übertragende Restmenge unter eine kleine Schwelle, wird die VM kurz angehalten, der letzte Zustand kopiert und auf dem Ziel fortgesetzt. Bei sehr schreibintensiven Gästen kann QEMU die vCPUs drosseln, um die Übertragung konvergieren zu lassen; alternativ verschiebt Post-Copy die VM sofort und lädt fehlende Seiten bei Bedarf nach.
8. Speicher: KSM, Ballooning und Hugepages
Mehrere Techniken erhöhen die Speicherdichte oder die Leistung:
- KSM (Kernel Same-Page Merging) führt identische Speicherseiten mehrerer VMs zu einer zusammen und spart so RAM, öffnet aber ein Seitenkanal-Risiko und wird in sicherheitskritischen Umgebungen oft deaktiviert.
- Memory-Ballooning gibt über virtio-balloon im laufenden Betrieb Speicher zwischen Gast und Host zurück, Grundlage für Überbuchung.
- Hugepages nutzen 2-MiB- oder 1-GiB-Seiten statt 4 KiB, entlasten den TLB und helfen latenzkritischen Lasten; sie vertragen sich schlecht mit KSM.
9. Sicherheit: mehr als CPU-Isolation
Die Grundisolation kommt von der CPU-Hardware. Darüber hängt der QEMU-Prozess als Angriffsfläche, der mehrschichtig gehärtet wird: sVirt gibt jeder VM ein eigenes SELinux- oder AppArmor-Label, sodass ein ausgebrochener QEMU-Prozess nicht auf fremde VMs oder den Host zugreift; seccomp sperrt unnötige Systemaufrufe; ein eigener Mount-Namespace beschränkt den Gerätezugriff. Für höchste Anforderungen verschlüsseln AMD SEV oder Intel TDX den Gastspeicher sogar gegen den Host (Confidential Computing).
10. Typ-1 oder Typ-2?
Ob KVM ein Typ-1- (bare-metal) oder Typ-2-Hypervisor (auf einem Wirtssystem) ist, lässt sich nicht eindeutig beantworten. Dafür spricht Typ-1: Der Kernel läuft direkt auf der Hardware und ist selbst der Hypervisor. Dafür spricht Typ-2: Der Linux-Kernel ist ein vollwertiges Betriebssystem, und QEMU ein gewöhnlicher Prozess. In der Praxis ist KVM ein hybrides, typ-1-artiges Modell, die Schubladen-Frage ist eher akademisch.
11. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Offen und im Linux-Kernel, keine Lizenzkosten | Nackt selten praktikabel, braucht ein Management darüber |
| Nahezu native Leistung über Hardware-Virtualisierung und VirtIO | QEMU-Prozess ist Angriffsfläche, verlangt Härtung (sVirt, seccomp) |
| Breites Ökosystem (Proxmox, OLVM, OpenStack, libvirt) | host-passthrough schließt sichere Live-Migration aus |
| VFIO/SR-IOV für direkten Gerätezugriff | KSM birgt Seitenkanal-Risiko; mit Hugepages unverträglich |
| Confidential Computing (SEV, TDX) verfügbar | Geräte-Passthrough bindet VMs an die Hardware |
Häufige Fragen zu KVM / QEMU
KVM ist ein Linux-Kernel-Modul, das die Virtualisierungserweiterungen der CPU nutzt und den Gastcode beschleunigt ausführt. QEMU ist der Userspace-Prozess, der die virtuelle Hardware bereitstellt und die VM koordiniert. QEMU kann auch ohne KVM arbeiten (reine Emulation), ist dann aber deutlich langsamer; in Produktion laufen sie zusammen.
Die CPU muss Virtualisierung unterstützen: Intel VT-x (VMX) oder AMD-V (SVM), was bei Server- und den meisten Desktop-CPUs der Fall ist und im BIOS aktiviert sein muss. Für direkten Gerätezugriff (Passthrough) kommt eine aktivierte IOMMU (VT-d / AMD-Vi) hinzu.
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
KVM / QEMU 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.