KVM versus Xen: Open-Source-Virtualisierung im Vergleich

    KVM LogoSpätestens seit Red Hat seine Virtualisierungsstrategie auf KVM (Kernel-based Virtual Machine) ausgerichtet hat, gilt dieser junge Hypervisor-Sproß in der Open-Source-Szene als potenzieller Nachfolger von Xen. Was KVM für die Community und die Betriebssystemhersteller so interessant macht, ist vor allem eine gegenüber Xen schlankere Architektur.

    Xen ist mit sieben Jahren Dienstalter einer der Veteranen der Open-Source-Server-Virtualisierer in der Linux-Welt. Der Erfolg beruht sich auf seinem Bare-Metal-Hypervisor, der mittels Paravirtualisierung schon zu Zeiten von Hardware ohne Virtualisierungsunterstützung eine hohe Performance virtualisierter Gäste erlaubte, und gleichzeitig auch vollvirtualisierte Gäste vermittels der damals neuen CPU-Virtualisierungsfeatures ermöglichte.

    Xen erreicht dies mit einem verhältnismäßig hohem Aufwand: Der Hypervisor benötigt für das Virtualisieren von Gästen (domU) eine privilegierte Linux-VM (dom0) mit einem speziell gepatchten Linux-Kernel. Aufgrund des hohen Pflegeaufwandes ist dieser Linux-Kernel auf einem eher alten Stand; und zum Verdruss der Xen-Entwickler wurde es nie in den Mainstream-Linuxkernel integriert.

    KVM-Architektur

    KVM setzt auf einen schlankeren Ansatz:

    1. Als „Kernel-based Virtual Machine“ wird KVM als Modul direkt an den Linux-Kernel angeflanscht. Ein separater Hypervisor und eine eigene virtuelle „Partition“ für den Betrieb virtueller Maschinen sind nicht erforderlich. Der Linux-Kernel selbst ist Gastgeber und stellt Scheduling, Memory Management, Treiber usw. zur Verfügung. Im Gegensatz zu Xen (Typ 1 Hypervisor) ist KVM als „Hosted Hypervisor“ vom Typ 2.
    2. KVM setzt direkt auf der CPU-Unterstützung für Virtualisierung (Intel VT und AMD SVM) auf und wurde von vorne herein im Hinblick auf moderne „virtualisierungsorientierte“ Hardware konzipiert. Dadurch kommt es mit weniger Code aus.

    KVM Architektur
    Abbildung: KVM-Architektur

    Die Kernel-based Virtual Machine setzt auf die Vollständige Virtualisierung (Typ-2-Hypervisor) und läuft unter Linux ab Kernel-Version 2.6.20. Bestandteile sind die Kernel-Module kvm.ko, die hardwarespezifischen Module kvm-intel.ko oder kvm-amd.ko und die Gerätedatei /dev/kvm. Nach dem Laden der Module arbeitet der Linux-Kernel selbst als Hypervisor. KVM selbst stellt keine virtuelle Hardware zur Verfügung, dies übernimmt QEMU, eine wohlbekannte Emulationssoftware. Diese ist zuständig für die virtualisierte Bereitstellung von Geräten in den Gästen und bietet gleichzeitig die Ablaufumgebung der VMs.

    Da Gastsysteme vollständig virtualisiert werden, sind Modifikationen in selbigen nicht erforderlich. KVM unterstützt jedoch bei Bedarf auch die Paravirtualisierung von IO-Schnittstellen (Netzwerk, Festplatte, Memory Ballooning, VGA). Hierzu nutzt es die standardisierte virtio-Schnittstelle des Linux-Kernels. Der Vorteil dieser Treiber ist der geringere Overhead und die höhere Performance.

    So spielen die Komponenten von KVM zusammen:

    • Die CPU-Virtualisierung wird durch Features des Prozessors bereitgestellt (Intel VT bzw. AMD-V).
    • Der Speicher wird durch KVM virtualisiert.
    • I/O wird durch einen QEMU-Prozess je Gast virtualisiert.

    KVM ist in seinem Aufbau weniger komplex als Xen und kann immer in Verbindung mit dem aktuellsten Linux-Kernel genutzt werden. Die Integration in den Mainstream-Linuxkernel garantiert dabei eine gewisse Zukunftssicherheit des Produkts. Zudem kann die Hypervisor-Technologie mit deutlich geringerem Aufwand weiterentwickelt werden und profitiert gleichzeitig sehr stark von Weiterentwicklungen bei der Hardware.

    Wie wirken sich die Eigenschaften von KVM in der Praxis aus?

    Installation und Handling

    KVM präsentiert sich bereits bei der Installation sehr schlank und einfach: es sind im Wesentlichen die Kernel-Module zum bestehenden System dazu zu installieren sowie Qemu und Management-Tools einzurichten. Damit kann im Gegensatz zu Xen auch ein bereits vorhandener Linux-Server nachträglich zum Virtualisierungssystem aufgerüstet werden. Bei Xen ist immer eine komplette Neuinstallation notwendig, da es sich um ein Bare-Metal System handelt.

    Auch beim Handling finden sich Linux-Administratoren sofort zurecht: Jeder Gast bzw. jede virtuelle CPU verhalten sich wie ganz gewöhnliche Linux-Prozesse und können so beispielsweise auch über normale Kommandos wie z.B. top, kill usw. kontrolliert und gesteuert werden. Dies gilt auch für die Gerätelandschaft, speziell für Speichergeräte – da hier die normalen Linux-Treiber genutzt werden, ist eine Umgewöhnung nicht nötig.

    Management

    Beim Management zeigt sich der junge Charakter von KVM noch von seiner eher unpraktischen Seite. KVM ist zwar in vielen Linux-Distributionen als eine Sammlung von Paketen bereits an Bord. Zum Standard gehört hier z.B. bei Ubuntu (welches ebenfalls von Xen zu KVM umgeschwenkt ist) der grafische virt-manager sowie die Kommandozeilen-Toolbox virsh. Beide laufen auf Basis des Hypervisor-übergreifenden Schnittstellenpakets libvirt (welches sich auch auf Xen versteht). Remote Management ist damit möglich, jedoch keine „Orchestrierung“ ganzer Pools virtueller Maschinen mit weitergehenden Funktionen wie Failover, High Availability und dergleichen.

    Hier springen Drittprojekte sowie Softwarehersteller in die Bresche, typischerweise allesamt Open-Source (wenngleich teilweise kostenpflichtig):

    • Convirture (ehemals ConVirt, ehemals XenMan) verwaltet Pools von Xen- und KVM-Servern parallel unter einer grafischen Weboberfläche.
    • oVirt: libvirt-basierende Web-GUI für das Management virtualisierter Server
    • Ganeti: Cluster Virtual Server Management Software von Google
    • Enomaly: Cloud Computing Plattform für KVM und Xen
    • openQRM: Data-Center Management Plattform mit Xen, KVM, VMware und Linux VServer als Basis für virtualisierte Server

    Aufbauend auf KVM als Virtualisierungsengine sind inzwischen verschiedene Komplettlösungen für Server-Virtualisierung am Markt angekommen:

    • RHEV (Red Hat Virtualization): das Lösungspaket enthält Komponenten für HA, Scheduling, Migration, Energieverwaltung sowie für Monitoring. Pikanterweise hat die Open-Source-only Schmiede derzeit nur ein Windows-basierendes Management-System. Dieses benötigt einen Windows 2003 Server sowie eine Windows-Workstation für die Nutzung der grafischen Konsole. Eine reine Open-Source-Lösung (Java-basierend) ist jedoch in Arbeit.
    • Proxmox VE: Out-of-the-Box Virtualisierungsplattform für KVM und openVZ

    Da erst solche Komplettlösungen den breiten Markt erschließen können, ist davon auszugehen, dass in nächster Zeit weitere solcher Produkte entstehen werden, was die Popularität von KVM weiter fördern dürfte.

    Unterstützte Gastsysteme

    Im Gegensatz zu QEMU unterstützt KVM nur Gast-Systeme mit x86-Architektur.

    Die Zahl unterstützter Systeme ist ähnlich groß wie bei Xen. Sämtliche wichtigen Windows-Varianten sind dabei: 2000, XP, Vista, Windows Server 2003 und 2008. Darüber hinaus natürlich Linux, Solaris, BSD, FreeBSD und einige eher exotische wie z.B. ReactOS.

    Technische Features

    Alle Funktionen, die man von einem modernen Hypervisor erwartet, sind an Bord: Detaillierte Konfiguration von Gästen (Speicher, virtuelle CPUs), dynamische Speicherverwaltung welche den Shared Memory des Linux-Systems nutzt (Kernel Same-page Merging = KSM), bis hin zur Live Migration von Gästen. Geräte am PCI-Bus und an USB-Anschlüssen können – auch Hot-plug-fähig – an Gäste durchgereicht werden.

    Performance

    Bislang existieren recht wenige Performancemessungen und -vergleiche. Insgesamt zeichnet sich ab, dass KVM im Schnitt eine mit Xen vergleichbare Performance aufweist, mit etwas unterschiedlichen Ausprägungen:

    • Bei der CPU-Performance hat Xen etwas die Nase vorn. Insbesondere dürfte damit der paravirtualisierte Betrieb von Linux, BSD oder Solaris hier die höchste Geschwindigkeit liefern.
    • Bei der IO-Performance ist KVM etwas schneller, so dass z.B. gerade der Windows-Gastbetrieb profitiert.

    Sicherheit

    Sicherheit kann gerade im Enterprise-Umfeld zum Prüfstein für KVM werden, da hier aufgrund der Kernel-nahen Implementierung (jeder Gast ist ein Linux-Prozess) die Gast-Isolation geringer ist als bei Bare-Metal Hypervisoren. Demgegenüber kann Xen eine höhere Gastisolation vorweisen und darüber hinaus von Hardware-Sicherheitsfeatures (z.B. TPM) Gebrauch machen. Das sVirt-Projekt soll SELinux im Hinblick auf die spezifischen Virtualisierungsanforderungen an Security erweitern, um KVM zu härten.

    Gegenüberstellung KVM und Xen

    KVM

    XEN

    Hardware

    Setzt Intel VT / AMD-V voraus

    Läuft auf fast jeder aktuellen Hardware, auch ohne Virtualisierungsfeatures

    Reifegrad

    Stabilität

    Noch nicht völlig ausgereift, viele Releases, keine als stabil markierten Versionen. Noch kein breiter Rechenzentrums-Einsatz

    Sehr ausgereift, sehr stabil. Verlässliches Release-Konzept, Regressionstests. Breiter Einsatz in Rechenzentren und Private und Public Clouds.

    Architektur

    Läuft mit und in jew. aktuellem Standard-Linux-Kernel (ab 2.6.20), mit vielen Distributionen verfügbar.

    Vollständige Virtualisierung, dadurch keine Modifikationen für Gastsysteme nötig.

    Auch Desktop-Betrieb möglich.

    An einen spezifischen, älteren Linux-Kernel (seit Xen 4 ist es 2.6.31, bei Xen 3 2.6.18) gebunden.

    Paravirtualisierung (Modifikationen am Gast-Kernel nötig) sowie Vollständige Virtualisierung (setzt Intel VT/AMD-V voraus).

    Setzt dedizierte Hardware voraus, daher nur Servereinsatz.

    Features

    Gute Grundlage durch Linux-Kernel.

    Gast-Funktionen teilweise noch im Ausbau begriffen.

    Mit Xen 4 großer Funktionsumfang, z.B. Support für VHD-Dateiformat, integrierte HA-Features, USB 2.0 Direktzugriff.

    Performance

    Schnell, vor allem gute IO-Performance

    Schnell, vor allem gute CPU-Performance.

    Gastsysteme

    Linux, Windows, Solaris, BSD, FreeBSD, MS-DOS und andere

    Linux, Windows, Solaris, BSD, FreeBSD, und andere

    Management

    Noch begrenzt. Wenige Drittanbieter.

    Mächtige Basis-Tools, große Auswahl an Dritt-Tools

    Enterprise-Lösungen

    RHEV

    Citrix XenServer, Oracle

    Zukunftssicherheit

    Hoch

    Fraglich

    Sicherheit

    Gast-Isolation geringer als bei Bare-Metal Hypervisor

    Hochgradige Gastisolation, Nutzung von Hardware-Sicherheitsfeatures (z.B. TPM)

    Funktionen von KVM und Xen im Vergleich

    FunktionKVMXen 4
    Host
    Hypervisor Typ21
    Architektur Hypervisor32+64 Bit, Intel-VT/AMD-V32+64 Bit, Intel-VT/AMD-V
    max.nutzbarer RAM Host1 TB1 TB
    SAN-Bootjaja
    PXE-Bootjaja
    Gast
    Gast-BetriebssystemeLinux, Windows, Solaris, BSD, FreeBSD, und andereLinux, Windows, Solaris, BSD, FreeBSD, und andere
    RAM pro Gast64 GB32 GB
    Architektur VMs32 Bit, 64 Bit32 Bit, 64 Bit
    max. virtuelle CPUs168
    DateiformatRAW, qcow2, vmdkRAW, Dateisystem, VHD, qcow2
    VLANjaja
    QoS (CPU, Platte, Netz) ja
    PV-Treiberjaja
    Hot-Plugging von VM-""Hardware"""CPU, PCI, USBCPU, RAM, Laufwerke, Nics
    USB direktja, dynamischja, USB 2.0
    Bluetoothjanein
    PCIjaja
    Serielljaja
    VGA Passthroughneinja
    3D GrafikOpenGL (Linux-VMs)ja
    Management
    ManagementkonsoleTextmen, CLI, GUITextmen, CLI
    Memory OvercommitmentJa (KSM - Kernel Shared memory)nein
    Shared Storageja, SAN, NASSAN, NFS, NAS
    Live MigrationJaJa
    ThinProvisioningjaja
    Nested VirtualizationJaNein
    NIC RedundanzNIC BondingNIC Teaming/Load Balancing
    Multipath IOJaja
    Snapshottingjaja
    P2V-Toolsjaja, Linux und Windows
    Failover/HAneinja
    SNMPjaja

    Fazit

    KVM ist durch seine Ansiedlung im Kernel schlank und schnell und erbt direkt alle Fähigkeiten des Linux -Betriebssystems. Auch wenn KVM im direkten Feature-Vergleich mit Xen und anderen Open-Source-Hypervisoren wie VMware ESXi momentan nicht in allen Punkten gleichziehen kann, so scheint dies bei der Geschwindigkeit der Entwicklung nur eine Frage der Zeit. Vorausgesetzt, man findet seinen eigenen Mix aus Host-Linux, KVM-Version und Management-Tools, kann man den Hypervisor bereits heute erfolgreich betreiben.

    Weder Xen noch VMware weisen dabei so gewichtige Vorteile auf, dass diese nicht in kurzer Zeit von KVM wieder aufgewogen werden könnten. Die Tatsache, dass es nur auf neueren Chips mit eingebautem Virtualisierungssupport läuft, dürfte heutzutage zu vernachlässigen sein. Schon eher dürfte – vor allem aus Sicht des Produktivbetriebs – der teilweise noch experimentelle Charakter und das Fehlen eines verlässlichen Release-Modells problematisch sein.

    6 Kommentare

    Bild von joe-eis
    joe-eis sagt:
    3. November 2010 - 13:08

    32GB RAM, 8 CPU's für XEN 4.x, wird hier nicht korrekturgelesen?

    Nach www.xen.org:

    128 vcpus per guest, 1 TB of RAM per host, up to 1 TB of RAM per HVM guest or 512 GB of RAM per PV guest, 128 physical CPUs per host (as a default, can be compile-time increased to lots more).

    Bild von Andrej Radonic
    3. November 2010 - 21:13

    Sie haben Recht, die Angaben sind wohl nicht (mehr) korrekt, vielen Dank für den Hinweis. Allerdings kann ich die Angaben zu den vcpus nicht bestätigen - das aktuelle Xen 4.0 Datenblatt von xen.org spricht von "64 vcpus per guest".

    Bild von darkfader
    darkfader sagt:
    28. Februar 2011 - 16:31

    Hallo,

    bisher war fuer mich bei KVM die Stabilitaet und Skalierung ein wenig fragwuerdig.
    Hat sich dieses gebessert?

    Also es gab sowohl Berichte, dass KVM bei nur 20-30 Gast-VMs bereits crashed, als auch das Problem, dass die Performance nur dann mit Xen vergleichbar ist, wenn man nur ein paar wenige VMs laufen laesst. Auch KVM User haben mir gesagt, dass es mit zunehmender Anzahl an VMs immer langsamer werde.

    Ich kann das jetzt schwer einschaetzen - entweder die kennen sich einfach nicht genug aus und haben deswegen Performanceprobleme, oder aber KVM ist eben doch nicht da, wo es angeblich sein soll.

    Aus meiner Sicht ist der Typ2-Hypervisor Ansatz ein nettes Feature, wenn man mal kurz auf dem Laptop eine VM braucht - so nutze ich es auch. Aber ansonsten ist es einem sauber getrennten Konzept stark unterlegen - wie schon der Kernelfootprint von KVM wesentlich hoeher ist, als der von Xen(deswegen wurde bei Xen ja Hypervisor und dom0 getrennt), so verlier ich auch Stabilitaetspunkte. Ein Xenserver mit virtuellen NICs arbeitet weiter, auch wenn die dom0 crashed.

    Ich hab das Gefuehl, dass KVM viel "blingbling" hat, weil es so schoen im Desktop funktioniert. Das war bei Xen2 vor 6 Jahren auch so. Dann hat es sich halt weiterentwickeln muessen, um auch RZ-Anspruechen gerecht zu werden, und ohne diese Entwicklung gaebe es KVM nichtmal (weil dann gaebe es kein VT...).

    Ihre Uebersichtstabelle ist auf jeden Fall mit viel Muehe erstellt worden, ich wuerde aber gerne wissen, ob Sie auch ueberzeugt sind, dass die KVM'schen Features auch in der Realitaet bestand haben.

    Oder ist es so wie bei "Highend-switches" von Huawei, die auf dem Datenblatt immer mindestens so schnell sind, wie ein Cisco, aber leider noch immer unter Last Frames droppen?

    Bild von B. Reit
    B. Reit sagt:
    5. September 2011 - 0:12

    Ich denke dennoch das der gute alte XEN noch lange nicht verbannt ist. Für den Servereinsatz ist er eben sehr gut skalierbar und die Gast-Isolation ist schon sehr gut. Vielleicht ist er daher auch gern in Rechenzentren gesehen.

    KVM hat sicher Zukunft, muss sich aber noch beweisen. Es gibt aber einige nette Ansätze wie z.B. auch VirtualBox, VM Ware oder auch Virtuoso ...

    Beruflich Virtualisiere ich viel mit XEN und ich kann echt nur sagen, der läuft halt ... :)

    Bild von Jörn
    Jörn sagt:
    9. Januar 2014 - 18:26

    Dieser Artikel ist eine sehr ansprechende Arbeit.
    Seit der Zeit des Entstehens aber ist einiges passiert, XEN steckte in einer Krise und hat sich wieder aufgerafft. Mich würde der Vergleich mit den aktuellen Parametern interessieren, d.h. eine Aktualisierung dieses Artikel würde ich sehr begrüßen.

    Mit besten Grüßen
    Jörn

    Bild von Oli
    Oli sagt:
    28. Juli 2014 - 2:40

    Ich schließe mich dem Wunsch von Jörn gerne an.
    Eine Aktualisierung des Artikels mit den aktuellen Möglichkeiten der beiden Hypervisor wäre sehr interessant!