Spätestens seit Red Hat seine Strategie für die Virtualisierung auf KVM (Kernel-based Virtual Machine) ausgerichtet hat, gilt dieser recht neue Hypervisor in der Open-Source-Szene als Nachfolger von Xen. Was macht KVM interessant, und ist es besser als Xen?
War Xen bis vor kurzem noch derjenige offene Hypervisor, der die meisten Hersteller - von IBM über Sun bis Oracle - hinter sich vereinte, ist das Feld der Open-Source-Hypervisor in den letzten Monaten in Bewegung geraten. Neben einem klaren Commitment der Linux Foundation für KVM hat allen voran Red Hat den Stein ins Rollen gebracht. Einstmals einer der großen Player in der Xen-Entwicklergemeinde, hat sich das Unternehmen durch den Aufkauf des KVM-Herstellers Qumranet vollständig der Kernel-based Virtual Machine als Grundlage für seine Server-Virtualisierung RHEV (Red Hat Enterprise Virtualization) verschrieben.
Foto: Radonic
Novell sprang auf den fahrenden Zug auf und nahm KVM neben Xen in SLES 11 auf; zudem wird dort ein eigener Hypervisor auf Basis von KVM entwickelt: AlacrityVM. IBM bewegt sich ebenfalls von Xen auf KVM zu. Citrix setzt mit XenServer konsequent weiterhin auf die Open-Source-Virtualisierungsmaschine Xen und stellte dies mit der soeben veröffentlichten Version 5.6 unter Beweis. Bei Oracle bleibt Xen derzeit Bestandteil von Oracle Linux, Bekenntnisse in Richtung KVM sind nicht verlautbart worden. Da aber Oracle Linux von Red Hat abgeleitet ist, könnten auch hier die Würfel in absehbarer Zeit für KVM fallen.
Das etwa 250 köpfige Xen-Entwicklerteam hat unbeeindruckt von politischem Geplänkel eine sehr umfassende Erweiterung des Hypervisors in Form der Version 4 herausgebracht und adressiert darin viele gerade für den Enterprise-Betrieb relevanten Themen - von Security bis hin zu erhöhter Ausfallsicherheit sowie Kompatibilität.
David gegen Goliath
Was KVM für die Community und die Betriebssystemhersteller so interessant macht, sind vor allem Aspekte der Architektur sowie der Wirtschaftlichkeit der Entwicklung. Xen begann 2006, den Weg für Server-Virtualisierung in der Linux-Welt zu ebnen. Sein Erfolg begründete sich auf dem Bare-Metal-Hypervisor, der mittels Paravirtualisierung eine performante Virtualisierung ermöglichte, 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 Xen wurde nie in den Mainstream-Linux-Kernel integriert.
KVM setzt auf eine schlankere Strategie:
1. Der Name ist Programm: KVM als "Kernel-based Virtual Machine" ist als Modul direkt in den Linux-Kernel integriert. Ein separater Hypervisor und eine separate virtuelle "Partition" für den Betrieb virtueller Maschinen sind nicht erforderlich. Der Linux-Kernel selbst stellt Scheduling, Memory Management, Treiber usw. zur Verfügung. Im Gegensatz zu Xen (Typ 1 Hypervisor) ist KVM als "Hosted Hypervisor" vom Typ 2.
Foto: Radonic
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. Zweiter Bestandteil von KVM neben den Kernelmodulen ist 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.
KVM präsentiert sich somit weniger komplex als Xen und kann immer in Verbindung mit dem aktuellsten Linux-Kernel genutzt werden. Die Integration in den Mainstream-Linux-Kernel 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.
KVM in der Praxis
Aber ist KVM dadurch das bessere Xen? Was spricht heute für KVM, was dagegen?
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. Eine Umgewöhnung ist nicht nötig.
Da Gastsysteme vollständig virtualisiert werden, sind Modifikationen in selbigen nicht erforderlich. KVM unterstützt jedoch bei Bedarf auch die Paravirtualisierung von I/O-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.
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 Virtualisierungs-Engine 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. Nicht nur, dass dies völlig unverständlich erscheint, es erhöht die Kosten des Gesamtsetups und es stellt auch noch einen Single Point of Failure dar, so dass man die Konstruktion insgesamt in Frage stellen darf. Eine reine Open-Source-Lösung soll jedoch in Arbeit sein.
• 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. Insgesamt wird dabei allen voran Red Hat gefordert sein, ein Ökosystem von KVM-Drittherstellern zu schaffen, welches eine Gesamtlandschaft für diesen Hypervisor schafft, um ihn Enterprise-ready zu machen.
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 hotplugfä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 zum Beispiel 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.
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. Viele Linux-Distributionen bieten QEMU und KVM als ein Paket (qemu-kvm) an.
Während Xen, Hyper-V und ESXi Typ-1 Virtual Machine Monitors (VMMs) sind, bei denen der Hypervisor in Ring 0 der CPU läuft, hält sich bei KVM, Virtual Server, VirtualBox, Parallels, VMware Workstation, etc., der VMM in Ring 3 wie eine Applikation auf. Aufgrund seiner Fähigkeit, Hardware-Virtualisierungsfeatures der CPU zu nutzen, entspricht die Performance von KVM jedoch eher derjeniger der Typ1-Hypervisor.
Schichten und Komponenten von KVM:
• Die CPU-Virtualisierung wird durch Features des Prozessors bereitgestellt (Intel VT bzw. AMD-V).
• Der Speicher wird durch KVM virtualisiert.
• IO wird durch einen QEMU-Prozess je Gast virtualisiert.
KVM wird manchmal scherzhaft auch als CPU-Beschleuniger für QEMU bezeichnet. Die Gäste würden auch ohne KVM und nur mit QEMU laufen, jedoch erheblich träger.
KVM versus Xen auf einen Blick
|
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) |
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 für die Virtualisierung 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 Virtualisierungs-Support 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.
Viele heutige Virtualisierungsumgebungen laufen auf Xen und haben derzeit vermutlich keinen zwingenden Grund, auf KVM zu migrieren (es sei denn es handelt sich um zahlende RHEL-Anwender). Solche, die neu in Server-Virtualisierung einsteigen, sollten auch KVM als Alternative evaluieren. Potenzielle Umsteiger werden dabei derzeit eher noch abwarten, bis "runde" Gesamtlösungen aus abgespecktem Host-System mit KVM sowie integriertem Management erscheinen, welche explizit Enterprise-Bedürfnisse adressieren.
Wie es mit Xen weitergeht, wird unter anderem von den im Xen-Team verbliebenen großen Softwareherstellern wie Citrix und Oracle abhängen. Xen wird schwerlich in nächster Zukunft in der Bedeutungslosigkeit untergehen, jedoch sollten Unternehmen bei strategischen Virtualisierungs-Entscheidungen die weitere Entwicklung genau beobachten. (cw/wh)