KVM versus Xen: Open-Source-Virtualisierung im Vergleich

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.

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

Funktion	KVM	Xen 4
Host
Hypervisor Typ	2	1
Architektur Hypervisor	32+64 Bit, Intel-VT/AMD-V	32+64 Bit, Intel-VT/AMD-V
max.nutzbarer RAM Host	1 TB	1 TB
SAN-Boot	ja	ja
PXE-Boot	ja	ja
Gast
Gast-Betriebssysteme	Linux, Windows, Solaris, BSD, FreeBSD, und andere	Linux, Windows, Solaris, BSD, FreeBSD, und andere
RAM pro Gast	64 GB	32 GB
Architektur VMs	32 Bit, 64 Bit	32 Bit, 64 Bit
max. virtuelle CPUs	16	8
Dateiformat	RAW, qcow2, vmdk	RAW, Dateisystem, VHD, qcow2
VLAN	ja	ja
QoS (CPU, Platte, Netz)		ja
PV-Treiber	ja	ja
Hot-Plugging von VM-""Hardware"""	CPU, PCI, USB	CPU, RAM, Laufwerke, Nics
USB direkt	ja, dynamisch	ja, USB 2.0
Bluetooth	ja	nein
PCI	ja	ja
Seriell	ja	ja
VGA Passthrough	nein	ja
3D Grafik	OpenGL (Linux-VMs)	ja
Management
Managementkonsole	Textmen, CLI, GUI	Textmen, CLI
Memory Overcommitment	Ja (KSM - Kernel Shared memory)	nein
Shared Storage	ja, SAN, NAS	SAN, NFS, NAS
Live Migration	Ja	Ja
ThinProvisioning	ja	ja
Nested Virtualization	Ja	Nein
NIC Redundanz	NIC Bonding	NIC Teaming/Load Balancing
Multipath IO	Ja	ja
Snapshotting	ja	ja
P2V-Tools	ja	ja, Linux und Windows
Failover/HA	nein	ja
SNMP	ja	ja

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.