KVM ist der Hypervisor-Nachzügler mit viel Potenzial

Was ist KVM, Kernel Virtual Machine?

| Autor / Redakteur: Thomas Drilling / Ulrike Ostler

Unter den Hypervisoren „ESXi“, „Hyper-V“, „Xen“ und „KVM“i st „Kernel Virtual Machine“ der jüngste. Wie Xen ist die Software quelloffen.
Unter den Hypervisoren „ESXi“, „Hyper-V“, „Xen“ und „KVM“i st „Kernel Virtual Machine“ der jüngste. Wie Xen ist die Software quelloffen. (Bild: Thomas Drilling)

„KVM“, Abkürzung für „Kernel Virtual Machine“, der Hypervisor des Linux-Kernels, nimmt im Reigen der großen vier Hypervisoren eine Sonderstellung ein. Entwickelt seit 2005 und offizieller Kernel-Bestandteil seit 2007 besitzt er als jüngster Vertreter der Gattung die geringsten Marktanteile. Das wundert kaum, legt man den Blick allein auf Enterprise-Virtualisierungssoftware, die auf KVM basiert. Allerdings ist KVM auch der bevorzugte Hypervisor in OpenStack und weist daher im Cloud-Bereich eine große Verbreitung auf.

Im Gegensatz zu „Xen“, dem anderen quelloffenen Hypervisor, ist die Geschichte von KVM weniger wechselvoll und zeigte vom Start weg nur steil nach oben. Und der Anfang geht so: Der Israeli Avi Kivity hatte im Mai 2005 das Unternehmen Qumranet geründet, das sich primär der Entwicklung einer komplett neuen Desktop-Virtualisierungssoftware, einschließlich zugehörigem Hypervisor widmete. Dieser sollte auf Linux aufsetzen.

Hauptziel war also nicht nur der Hypervisor an sich, für den offenbar Linux als bevorzugte Plattform erachtet wurde, sondern die Desktop-Virtualisierung als Alternative zu Citrix und „View“, die allerdings hinsichtlich der Management-Werkzeuge vorrangig auf eine Windows-Infrastruktur aufsetzte, einschließlich Active Directory Integration.

Was ist KVM?

KVM ist primär kein Bare-Metal-Hypervisor, sondern setzt auf Linux auf. Somit ist KVM formal ein Typ2-Hyervisor, was schlicht bedeutet, dass er im nicht privilegierten Ring 3 läuft. Allerdings führen die Experten seit Jahren eine inzwischen historische Diskussion darüber, ob KVM nicht doch ein Typ1-Hypervisor ist.

Typ 1 versus Typ 2: KVMs und andere Hypervisoren

Glaubenskrieg um die richtige Virtualisierung

Typ 1 versus Typ 2: KVMs und andere Hypervisoren

09.06.11 - Die Kernel-basierte Virtuelle Maschine (KVM) ist in Verruf geraten. Das liegt an Missverständnissen bezüglich Typ-1- und Typ-2-Hypervisoren, sagt IBMs federführender Virtualisierungsarchitekt Michael Day. lesen

Denn es laufen auch einige Teile (die Kernel-Module zur Interaktion mit der Hardware- oder der Paravirtualisierungs-Schnittstelle) in Ring 0, da KVM offizieller Bestandteil des Linux-Kernels ist. Setzt man also für die Virtualisierung an sich einen speziell dazu abgespeckten small-footprinted Linux-Kernel ein, wie es zum Beispiel Red Hat bei „Red Hat Virtualization“ (RHV) mit „RHV-H“ tut, ist KVM wohl doch als Bare-Metal-Hypervisor zu betrachten.

Die Besonderheit an KVM ist, dass Kivity im Gegensatz zu den Xen-Entwicklern von Anfang an eng mit Linux- Kernel-Entwicklern kooperierte. So gab er beispielsweise schon 2006 alle seine Patches über die Kernel-Mailingliste weiter. Zudem war er stets penibel bemüht, den Code für eine wohl von Anfang an geplante Integration in Linux vorzubereiten.

Seine Bemühungen sollten nicht daher nicht lange unbelohnt bleiben, denn Linus Torvalds nahm KVM Anfang 2007 bereits offiziell in den Kernel 2.6.20 auf, was den Xen-Entwicklern bis dahin - und auch bis heute aus verschiedenen Gründen - nicht gelungen war.

KVM und Red Hat

Einen ganz großen Coup landete Kivity dann 2008. Er konnte sein Unternehmen Qumranet mitsamt Hypervisor und der darauf basierenden Desktop-Virtualisierung an Red Hat verkaufen.

Red Hat modelte die Software (nicht den Hypervisor) dann über mehrere Jahre in einem mühevollen Prozess zu einer rein Linux-basierten Enterprise-Virtualisierungs-Software um (nicht nur VDI), die heute unter der Bezeichnung Red Hat Virtualization läuft.

Wie bei Red Hat üblich, liegt dem kommerziellem Produkt auch ein von Red Hat gefördertes Community-Projekt „oVirt“ zugrunde, das sämtliche Änderungen, einschließlich der recht komplexen Code-Rewrites (große Teil des C+-Codes mussten auf Java und die Middleware dazu auf „JBoss“ umgestellt werden) quelloffen zur Verfügung stellt.

Von netten „Abfall“-Produkten, wie dem Hyervisor KVM oder SPICE (Multi-Channel-Secure Remote-Access und performantes VDI-Protokoll in Einem) profitiert heute die gesamte Linux-Gemeinschaft, weil Red Hat nicht nur deren Community-Charakter bewahren konnte, sondern als finanzkräftige Sponsor auch Treiber für die Weiterentwicklung wurde und seit jeher eigene Entwickler für die Projekte abstellt. KVM ist heute in jeder Linux- Distribution enthalten, oft ergänzt um spezielle paravirtualisierte Treiber für Netzwerk- und Storage.

Die Technik von KVM

Soweit zur Historie. Im Gegensatz zu Xen ist es verhältnismäßig einfach, KVM jeweils auf den aktuellen Stand der Technik zu hieven. Ist nämlich bei Xen dazu stets das Neukompilieren des Kernels mit entsprechenden Reboots notwendig, genügt es bei KVM, die aktuellen Kernelmodule aus dem Kernel zu entfernen und die jeweils zuvor neu gebauten Module zu laden.

Technisch weist KVM im Gegensatz zu allen anderen Hypervisoren eine Besonderheit auf. So kümmert sich KVM selbst überhaupt nicht um die Emulation an sich, sondern stellt lediglich die Infrastruktur dazu bereit. KVM interagiert dazu mit bestehender OpenSource-Software, wie „Qemu“.

Qemu stellt den virtualisierten Gastsystemen die benötigten Geräte wie Festplatten, Netzwerk-, Sound- und Grafikkarten zur Verfügung. Erst nach dem Laden des KVM-Kernel-Moduls arbeitet der Linux-Kernel als Hypervisor für virtuelle Maschinen.

KVM unterstützt eine breite Palette an Gastsystemen, neben Linux (32 und 64 Bit) und „Windows“ (32 und 64 Bit) auch „Haiku“, „AROS“, „ReactOS“, „FreeDOS“, „Solaris“ und diverse BSD-Derivate, selsbt auf dem Mainframe findet sich KVM. Auch Unterstützung für Paravirtualisierung ist mithilfe der Paravirtualisierungsschnittstelle „Virtio“ möglich, die seit dem Kernel 2.6.25 im Kernel verfügbar ist. Support für Nested Virtualization auf Intel-CPUs gibt es seit der Kernel-Version Kernel 3.1, für AMD-CPUs bereits seit dem Kernel 2.6.30.

Die Kombination mit Qemu

Eine Gemeinsamkeit verbindet KVM mit ESXI und Xen. Im Gegensatz zu Hyper-V lässt sich die Virtualisierung auch ohne CPU-gestützt Hardware-Virtualisierung nutzen, wobei die Virtualisierung/Emulation dann wie beschrieben durch Qemu erfolgt. Die VMs laufen dann um den Faktor 5 langsamer.

Ob die Host-CPU Hardware-Virtualisierung unterstützt, findet man mit dem Kommando „kvm-ok“ heraus. Sollten die zugehörigen Kernel-Module nicht geladen sein, lässt sich dieses unter Linux zum Beispiel mit „modprobe kvm „und „modprobe kvm_intel“ (bei Intel) oder „modprobe kvm_amd“ jederzeit nachholen.

Steuerung virtueller Maschinen

KVM ist nur ein Hypervisor. Anders als bei ESXI oder Hyper-V gibt es keine 1:1-Beziehung zu einer zugehörigen Virtualisierungssoftware. Auch bei Xen muss, da es sich um einen ebenfalls quelloffenen Hypervisor handelt, nicht zwangsläufig der „Xenserver“ zum Einsatz kommen, wie das Beispiel Amazon Web Services (AWS) zeigt.

Allerdings gibt es, was die direkte Steuerung angeht, auch Gemeinsamkeiten mit KVM. Abhilfe schafft daher unter Linux ein Abstraktions-Layer namens „libvirt“. Die Bibliothek abstrahiert die Funktionen für die Hypervisoren Xen, KVM (und andere) unter Linux.

Sie stellt sie über eine Administrationsschnittstelle bereit, wahlweise per Application Programming Interface (API) oder als Kommandozeilenoberfläche Shell, zum Beispiel in Form der CLI „Virsh“ oder diverser verfügbarer grafischer Management-Tools wie „Virt-Manager“ und „Gnome-Boxes“. Man kann KVM aber auch wie ehemals vorgesehen mit oVirt oder Red Hat Enterprise Virtualization nutzen.

*Thomas Drilling ist freier IT-Autor und -Berater. Auf DataCenter-Insider schreibt er seinen eigenen Blog:Drillings Open-Source-Eck“.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44805129 / Definitionen)