Wie KVM intern funktioniert
KVM verwandelt den Linux-Kernel in einen Type-1-Hypervisor, indem es ein Zeichengerät /dev/kvm bereitstellt. Ein Userspace-Prozess (typischerweise QEMU) öffnet dieses Gerät, weist den Kernel an, eine virtuelle CPU zu erzeugen, und führt Gastinstruktionen mithilfe von Hardware-Virtualisierungserweiterungen direkt auf der physischen CPU aus. Der Kernel behandelt privilegierte Ereignisse; alles Übrige läuft mit nativer Geschwindigkeit.
KVM funktioniert dank dreier Komponenten. Erstens verwaltet das Kernelmodul kvm.ko CPU- und Speichervirtualisierung und stellt die Schnittstelle /dev/kvm bereit. Zweitens vermittelt ein architekturspezifisches Modul – kvm-intel.ko für Intel VT-x oder kvm-amd.ko für AMD-V – zwischen der generischen KVM-API und den Virtualisierungsbefehlen der CPU. Drittens stellt ein Userspace-Hypervisor wie QEMU, Cloud-Hypervisor oder Firecracker die Geräteemulation bereit: virtuelle Datenträger, NICs, USB-Controller und BIOS- bzw. UEFI-Firmware. Da der Linux-Kernel selbst der Hypervisor ist, gelten alle Linux-Scheduler, Speicherverwaltungs- und Sicherheitsfunktionen für VMs genauso wie für native Prozesse. Aus Kernel-Sicht ist ein KVM-Gast lediglich ein gewichtiger Prozess – weshalb Tools wie top, perf und cgroups ohne Anpassung funktionieren.
KVM vs. OpenVZ vs. VMware ESXi vs. Hyper-V
KVM bietet vollständige Hardware-Virtualisierung mit einem eigenen Gast-Kernel pro VM. OpenVZ nutzt OS-Level-Containerisierung; alle Container teilen sich den Host-Kernel. VMware ESXi ist ein proprietärer Type-1-Hypervisor mit eigenem Kernel (VMkernel). Hyper-V ist Microsofts Windows-basierter Type-1-Hypervisor. Nur KVM, ESXi und Hyper-V bieten einen wirklich isolierten Gast-Kernel.
OpenVZ (und sein Nachfolger Virtuozzo) ist eine Container-Technologie und kein Hypervisor. Jeder OpenVZ-Container teilt sich den Linux-Kernel des Hosts, sodass Sie keine andere Kernelversion ausführen, keine eigenen Kernelmodule laden und kein Nicht-Linux-Betriebssystem betreiben können. Der Kompromiss heißt Dichte: Da kein Per-VM-Kernel-Overhead anfällt, kann ein OpenVZ-Host mehr Container auf derselben Hardware unterbringen, weshalb günstige Shared-VPS-Tarife dies früher häufig nutzten. VMware ESXi ist der Enterprise-Standard für Type-1-Virtualisierung, jedoch ein Closed-Source-Produkt mit Per-Sockel-Lizenzierung, das es im Commodity-VPS-Hosting historisch unattraktiv machte. Hyper-V dominiert Windows-Server-Umgebungen und ist eng mit Active Directory und System Center verzahnt, ist aber für Linux-lastige Hosting-Flotten weniger üblich. KVM ist im modernen VPS-Hosting zum Standard geworden, weil es Open Source ist, im Kernel-Mainline lebt, jedes Gast-Betriebssystem für x86_64 oder aarch64 unterstützt und ein ausgereiftes Management-Ökosystem (libvirt, oVirt, Proxmox, OpenStack Nova) bietet.
Warum KVM die moderne Standardwahl für VPS ist
KVM hat sich als dominierende VPS-Technologie durchgesetzt, weil es jedem Kunden einen echten, isolierten Kernel ohne VMware-Lizenzkosten bietet. Es unterstützt Linux-, Windows-, BSD- und Solaris-Gäste, läuft auf Standard-x86_64- und ARM-Hardware und ist in jeden großen Cloud-Orchestrierungs-Stack integriert – OpenStack, Proxmox VE, Kubernetes via KubeVirt und AWS Nitro bauen alle darauf auf.
Drei Faktoren wirkten zusammen, um KVM zum Standard zu machen. Erstens wurden Hardware-Virtualisierungserweiterungen universell: Intel VT-x kam 2006 in Core-2-Chips, AMD-V in den frühen Athlon-64-Modellen, sodass im Wesentlichen jede Server-CPU der frühen 2010er KVM nahezu nativ ausführen konnte. Zweitens lehnte die Linux-Community Xen-artige Paravirtualisierung im Mainline ab, übernahm aber 2007 KVM in den Mainline-Kernel, wodurch jede Distribution sofort einen integrierten Hypervisor erhielt. Drittens investierte das Public-Cloud-Ökosystem stark: Google Compute Engine startete auf KVM, AWS migrierte von Xen auf eine KVM-basierte Nitro-Architektur, und OpenStack standardisierte KVM als Referenz-Hypervisor. Kleinere VPS-Anbieter profitieren von dieser Anziehungskraft, weil die gleichen Werkzeuge – libvirt, virtio-Treiber, cloud-init – sowohl auf Hyperscaler-Flotten als auch auf einem einzelnen Rack mit Standard-Servern laufen.
Reale Performance: CPU-Steal, IO und Overhead
Auf einem ordentlich provisionierten KVM-Host können Sie einstelligen Prozent-CPU-Overhead gegenüber Bare-Metal, sub-millisekundige zusätzliche Netzwerklatenz auf lokalen Pfaden und 80–95 % der nativen Disk-IOPS erwarten, wenn virtio-blk oder virtio-scsi mit paravirtualisiertem Treiber genutzt werden. Eine dauerhaft über 5 % liegende CPU-Steal-Zeit ist das klassische Anzeichen für Host-Übercommitment und ein klares Upgrade-Signal.
Drei Kennzahlen sind für einen produktiven KVM-Gast entscheidend. CPU-Steal (achtes Feld in /proc/stat) misst den Prozentsatz der Zeit, in der die virtuelle CPU lauffähig war, die physische CPU jedoch andere Gäste bediente. Werte unter 1–2 % sind normales Hintergrundrauschen; dauerhaft über 5 % bedeutet, dass der Host übercommittet ist und Ihre Workload gedrosselt wird. IO-Wait (sichtbar in iostat und top) misst den Prozentsatz der Zeit, in der die CPU auf Disk- oder Netz-IO wartet. Mit virtio-Paravirtualisierung und modernem NVMe-Backing-Speicher deutet ein dauerhaftes IO-Wait über 20 % bei einer eigentlich CPU-gebundenen Workload auf eine ausgelastete Speicherinfrastruktur hin. Der Netzwerkdurchsatz auf virtio-net sollte 80–95 % der physischen NIC-Linerate erreichen; deutlich darunter weist auf eine fehlkonfigurierte Offload-Funktion oder einen alten emulierten e1000-Treiber hin.
Wann KVM NICHT verwendet werden sollte
KVM ist in drei Situationen die falsche Wahl: bei extrem dichten containerisierten Workloads, bei denen der Per-VM-Kernel-Overhead dominiert; bei Windows-lizenzsensiblen Bereitstellungen, in denen die SPLA-Preisgestaltung von Hyper-V deutlich günstiger ist; und bei bestimmten Low-Latency-Hardware-Passthrough-Szenarien, in denen SR-IOV oder GPU-Passthrough für Ihre konkrete NIC oder GPU schlecht unterstützt wird.
Für containerisierte Microservices ohne Anforderung an Kernel-Isolation packen Linux-Container (Docker, Podman, Kubernetes) auf Bare-Metal jeden KVM-VPS um Faktor 3–5, weil jeder Container nur eine Prozessgruppe mit Namespaces und cgroups ist. Dichte-empfindliche Low-Cost-VPS-Anbieter setzten aus genau diesem Grund früher auf OpenVZ. Windows-lastige Bereitstellungen – insbesondere mit SPLA-bezogenen Windows-Server-Lizenzen – können auf Hyper-V deutlich günstiger sein als auf KVM, weil Microsoft Gast-Lizenzen auf konkurrierenden Hypervisoren anders bepreist. Und schließlich sind manche Hardware-Passthrough-Szenarien mit KVM weiterhin schwierig: GPU-Passthrough verlangt sauber isolierte IOMMU-Gruppen, einige Consumer-NICs haben kein SR-IOV, und PCIe-Passthrough von NVMe-Laufwerken kann Reset-Bug-Workarounds erfordern. Für 95 % der allgemeinen Linux-VPS-Workloads gilt nichts davon, und KVM ist die richtige Standardwahl.
Wie Sie überprüfen, ob ein VPS wirklich KVM-basiert ist
Führen Sie innerhalb eines Linux-Gasts `systemd-detect-virt` aus – die Ausgabe sollte `kvm` lauten. Prüfen Sie zusätzlich `lscpu` (die Zeile „Hypervisor vendor“ sollte „KVM“ sein) und `dmesg | grep -i kvm`. Sehen Sie stattdessen „OpenVZ“, „lxc“ oder „VMware“, nutzt Ihr Anbieter eine andere Technologie – auch wenn das Marketing etwas anderes behauptet.
Vor Vertragsabschluss empfiehlt sich eine kleine Diagnose-Reihe auf einem Test-VPS. `systemd-detect-virt` liefert die kanonische Erkennungsausgabe. `cat /proc/cpuinfo | grep -E 'vmx|svm'` bestätigt, dass die Hardware-Virtualisierungserweiterungen durchgereicht werden (manche Anbieter entfernen sie und brechen so die geschachtelte Virtualisierung). `uname -r` prüft, ob ein gastspezifischer Kernel statt eines geteilten Host-Kernels sichtbar ist – auf einem echten KVM-VPS können Sie über `apt install linux-image-…` oder `dnf install kernel-…` einen anderen Kernel installieren und neu booten. Bei OpenVZ ist das nicht möglich. Schließlich verrät `/proc/user_beancounters`: existiert diese Datei, läuft der Host auf OpenVZ – egal, was Marketing-Texte versprechen.