Der Punkt, an dem die meisten Erklärungen verwirren
"QEMU vs. KVM" klingt nach einem Vergleich zwischen zwei konkurrierenden Optionen – so wie "Proxmox vs. VMware". Ist es aber nicht. QEMU und KVM sind keine Alternativen zueinander, sondern zwei Bauteile, die zusammen eine VM ausführen. Die eigentliche Frage, die sich die meisten stellen wollen, lautet eher: "Was übernimmt was, und warum ist das relevant für die Performance meiner VMs?"
Die Aufteilung
QEMU ist ein Hardware-Emulator, komplett in Software: virtuelle CPU, virtuelle Disk, virtuelle Netzwerkkarte. Rein mit QEMU (ohne KVM) lässt sich sogar eine ARM-VM auf einem x86-Host emulieren – das funktioniert, ist aber wegen Software-Emulation der CPU-Befehle brutal langsam.
KVM ist ein Linux-Kernel-Modul, das die Hardware-Virtualisierungserweiterungen der CPU nutzt (Intel VT-x oder AMD-V). KVM emuliert nichts – es lässt VM-Code direkt auf der echten CPU laufen, mit Hardware-Isolation. Dafür kann KVM aber nur x86-auf-x86 (bzw. ARM-auf-ARM), keine Cross-Architektur-Emulation.
lsmod | grep kvm # kvm_intel oder kvm_amd sollte geladen sein
egrep -c '(vmx|svm)' /proc/cpuinfo # > 0 = CPU unterstützt Hardware-Virtualisierung
Proxmox (und praktisch jeder moderne Linux-Hypervisor) nutzt beide zusammen: KVM für CPU und RAM, QEMU für alles drumherum – virtuelle Disk-Controller, Netzwerkkarten, USB, Grafikausgabe.
Architektur
Proxmox / libvirt – Management-Layer
QEMU – Device-Emulation (Disk, NIC, USB, Display)
KVM – CPU + RAM (Hardware-beschleunigt, near-native)
Linux-Kernel
Hardware (CPU mit VT-x/AMD-V)
VirtIO – warum emulierte Geräte langsam sind
Ein komplett emuliertes Gerät (z.B. eine virtuelle IDE-Disk oder eine e1000-Netzwerkkarte) zwingt den Gast-Treiber, sich wie mit echter Hardware zu verhalten – inklusive aller Warteschleifen und Interrupts, die reale Hardware braucht, aber virtuelle Hardware eigentlich nicht. VirtIO ist ein paravirtualisiertes Treiber-Set, das dem Gast-OS mitteilt: "Du läufst virtualisiert, wir sparen uns die Emulations-Umwege."
| Gerät | Emuliert | VirtIO (paravirtualisiert) |
|---|---|---|
| Disk | IDE/SATA | virtio-scsi |
| Netzwerk | e1000 | virtio-net |
# Proxmox: VirtIO konfigurieren
qm set 100 --scsi0 local-lvm:vm-100-disk-0,cache=writeback
qm set 100 --net0 virtio,bridge=vmbr0
Windows-Gäste brauchen dafür die VirtIO-Treiber-ISO von der Proxmox-Downloadseite – ohne die sieht Windows die virtio-scsi-Disk beim Setup gar nicht erst.
Performance – realistische Größenordnungen
| Konfiguration | Performance vs. Bare-Metal |
|---|---|
| QEMU ohne KVM (reine Emulation) | 10–100x langsamer |
| KVM + emulierte Devices | ~85% |
| KVM + VirtIO | ~97% |
| KVM + PCIe-Passthrough | ~99%+ |
Diese Zahlen sind grobe Richtwerte, keine Laborergebnisse – die tatsächliche Differenz hängt stark vom Workload ab. CPU-lastige Berechnungen liegen näher an 99%, I/O-lastige Workloads (Storage, Netzwerk) profitieren am stärksten vom Umstieg auf VirtIO.
Fazit
QEMU und KVM sind Teamplayer, kein Vergleich. KVM gibt der VM Zugriff auf echte CPU-Performance, QEMU emuliert alles drumherum – und VirtIO-Treiber sind der Unterschied zwischen "spürbar virtualisiert" und "kaum vom Bare-Metal-Betrieb zu unterscheiden".
Ich berate und betreue Unternehmen in Heidelberg, Mannheim, Karlsruhe und der Rhein-Neckar-Region im Bereich Proxmox-Virtualisierung. Beratung anfragen.