Der KVM Hypervisor mitsamt QEMU, virtio, virsh und libvirt Mainframe + Open Source = Sichere Virtualisierung

Unglaublich? Unbekannt? Die „Kernel Virtual Machine“, also der Hypervisor KVM, hat auf dem IBM Mainframe eine Heimat. Der Artikel beschäftigt sich mit den Ursprüngen und dem modernen, sehr erfolgreichen Open-Source-Produkt. Zwei IBMer haben zusammengefasst, was sich zu wissen lohnt - KVM im Allgemeinen und KVM auf IBM Z im Besonderen.

Anbieter zum Thema

IBM Deutschland GmbH

AixpertSoft GmbH

Vor 45 Jahren, genauer gesagt am 2. August 1972, kündigte IBM das Großrechner-Betriebssystem „VM/370“ (Virtual Machine Facility/370) an. Heute nennen wir es einfach „z/VM“. Wie sich unschwer aus dem Namen ablesen lässt, war Virtualisierung schon damals eine Kernfunktionalität der IBM Z Plattform.

Indem jedem Benutzer ein vollständiges virtuelles Computersystem präsentiert wurde, war es möglich, mehrere Betriebssysteme gleichzeitig auf einem IBM System/370 Großrechner laufen zu lassen. Der Vorteil: Dabei kann wesentlich mehr virtuelle Hardware zur Verfügung gestellt werden, als in der Realität vorhanden ist, und gibt dem Nutzer mehr Flexibilität.

Logische Partitionen

Ein weiterer Meilenstein war die Einführung von „PR/SM“ im Jahre 1988: Diese Technologie ermöglicht es, eine physische Maschine in mehrere vollständig voneinander getrennte logische Partitionen (LPARs) zu unterteilen.

LPARs verfügen über dedizierten, nicht geteilten Hauptspeicher und führen Ein- und Ausgabeoperationen direkt, schnell und sicher auf nicht-virtualisierte Geräten aus. Dadurch ist es möglich, die strengen Sicherheitsvorgaben gemäß der US-amerikanischen Norm Common Criteria EAL5 zu realisieren. Seit der Einführung der aktuellen Architektur vor 15 Jahren ist die Benutzung von LPARs obligatorisch.

Leistungsfähige Open-Source-Software

Mit KVM ist jetzt ein leistungsfähiger Open-Source-Hypervisor verfügbar, der weitere Einsatzmöglichkeiten durch ein reichhaltiges Open-Source-Ökosystem eröffnet. Die Kombination aus dem Open-Source-Betriebssystem Linux und robuster, skalierbarer Mainframe-Technologie ist zu einem Erfolgsmodell geworden, das Nutzern die Freiheit gibt, eine für sie optimale Lösung zu finden.

Genauso wie Linux sich als Ergänzung zu (und nicht als Ersatz für) traditionelle Betriebssysteme etabliert hat, bietet sich KVM als weitere Virtualisierungsoption an. Zum Beispiel können Benutzer von KVM auf von anderen Plattformen bekannte Standard-Tools für das System-Management zurückgreifen und standardisierte Anwendungen zum Einsatz bringen. Dadurch wird KVM für Kunden interessant, die bisher noch keine Erfahrung mit der Mainframe-Virtualisierung haben, aber trotzdem nicht auf die Vorteile der IBM Z-Architektur verzichten wollen.

Das Ziel von Virtualisierung ist es, Betriebssystemen und den darin laufenden Programmen eine virtuelle Maschine mit allen üblichen Ressourcen zur Verfügung zu stellen. Dazu gehören CPU und Hauptspeicher sowie Ein- und Ausgabegeräte wie Platten und Netzwerkschnittstellen. Moderne Rechnerarchitekturen unterstützen die Virtualisierung von CPU und Hauptspeicher mittels spezieller privilegierter Operationen. Linux stellt dafür Architektur-spezifische KVM-Module bereit, die diese Aufgabe übernehmen.

QEMU sorgt für Ein- und Ausgaben

Für das Bereitstellen von Ein- und Ausgabegeräten ist „QEMU“ zuständig. Ursprünglich als Emulator für verschiedene Rechnerarchitekturen konzipiert, ist dieses Programm essentieller Bestandteil der KVM-Infrastruktur geworden. Jede virtuelle Maschine wird durch eine Instanz von QEMU implementiert, wobei der Emulator die Programmausführung dem KVM-Kernel-Modul überlässt, und im Wesentlichen nur dann Kontrolle bekommt, wenn es um das Ausführen von Ein- und Ausgabe-Operationen geht.

Als Management-Infrastruktur für QEMU und KVM hat sich „libvirt“ etabliert. Zu den Aufgaben von libvirt gehören die persistente Definition von virtuellen Maschinen, das Verwalten der Host-Ressourcen und ihre sichere Zuteilung an die VMs. Weiterhin bietet libvirt Schnittstellen an, um virtuelle Maschinen managen zu können. Die Kernkomponente von libvirt ist ein System-Prozess (daemon), der Anfragen von Management-Anwendungen (Clients) entgegennimmt, um beispielsweise virtuelle Maschinen zu starten oder deren Status abzufragen.

Virtualierungssoftware verfolgt oftmals das Ziel, alle Betriebssysteme zu unterstützen, die auf der echten Hardware lauffähig sind. Das hat zur Folge, dass den Gästen eine Vielfalt an Legacy-Geräten zur Verfügung stehen. Dabei handelt es sich entweder um reale Geräte, die der virtuellen Maschine zugeordnet (dedicated) werden, um geteilte (shared) oder auch emulierte Geräte.

Da KVM auf IBM Z primär für Linux konzipiert ist, kann auf die Emulation von traditionellen Mainframe-Geräten weitgehend verzichtet werden. Stattdessen werden unter KVM ‚paravirtualisierte‘ Ein- und Ausgabegeräte zur Verfügung gestellt, die wesentlich effizienter arbeiten als emulierte Geräte. Das transparente Durchreichen von Geräten wird zurzeit nicht unterstützt, befindet sich aber in der Entwicklung.

Der Unterschied: KVM auf IBM Z und auf x86

Ein offensichtlicher Unterschied zwischen KVM auf IBM Z und x86 liegt in der Hardware-Architektur, was sich unter anderem auch bei den angebotenen Peripheriegeräten niederschlägt. Typische PC-Hardware wie Grafik- oder Soundkarten und USB-Ports gibt es beim Mainframe nicht. Ansonsten wird KVM-Kennern auffallen, dass es wenige praxisrelevante Unterschiede zwischen den KVM-Plattformen gibt.

Das Konzept der Paravirtualisierung von E/A-Geräten nutzt aus, dass ein Gastbetriebssystem sich der Tatsache bewusst ist, in einer virtuellen Maschine ausgeführt zu werden. Daher ist es möglich, effizientere Kommunikationsmechanismen für den Transport von Daten zwischen VM und Hypervisor zu implementieren.

Paravirtualisierung mithilfe von virtio

Unter KVM ist eine Paravirtualisierungstechnik mit der Bezeichnung „virtio“ weit verbreitet. virtio-Geräte verwenden einen standardisierten Ringpuffer (virtio-ring) für die Daten im Gast, auf die der Hypervisor direkt zugreifen kann. Um den Datentransfer auszulösen, kann der Gast einen so genannten Hypercall (kick) durchführen. Diese Technik wird genutzt, um folgende virtuelle Gerätetypen zu implementieren:

Diese virtio-Geräte sind generell architekturunabhängig, so dass Gerätetreiber nur einmal geschrieben werden müssen und somit allen Plattformen zur Verfügung stehen, die virtio unterstützen. Die virtio-Basis-Implementierung ist allerdings architekturspezifisch.

Unter anderem wird bei der Geräte-Erkennung ein plattformspezifischer Mechanismus eingesetzt. So werden virtio-Geräte auf x86-Systemen als virtuelle PCI-Geräte dargestellt, während bei IBM Z ein spezielles virtuelles Channel-Subsystem zum Einsatz kommt.

Management per virsh

Üblicherweise wird ein Linux, das sich als KVM-Host benutzen lässt, mit den Userspace-Paketen QEMU und libvirt ausgeliefert. Teil von libvirt ist ein einfaches Client-Programm mit der Bezeichnung „virsh“ (virtualization shell), mit der alle wesentlichen Management-Operationen durchgeführt werden können. Daneben gibt es noch weitere Management-Anwendungen, wie „virt-manager“, eine grafische Benutzeroberfläche für das Administrieren von virtuellen Maschinen, oder vollständige Cloud-Frameworks wie OpenStack.

Eines der wichtigsten Features aktueller Hypervisors ist die Möglichkeit, Gäste zwischen verschiedenen Systemen zu migrieren („Live Guest Migration“), um zum Beispiel eine Hypervisor-Instanz nach dem Einspielen von Service Patches neu starten zu können, ohne dass dies die Gäste beeinträchtigen würde.

Bei der Live Guest Migration wird der komplette aktuelle Zustand eines Gastes von der Quell- zur Ziel-Hypervsior Instanz kopiert. Dies beinhaltet unter anderem den kompletten Hauptspeicher sowie den Zustand der Prozessoren. Festplatten, Netzwerkkarten und Ähnliches bedürfen einer gesonderten Behandlung.

Hier ist es am einfachsten, die entsprechenden Geräte entweder auch auf dem Ziel-Hypervisor zur Verfügung zu stellen, oder für gleichartigen Ersatz zu sorgen. Tritt während der Migration ein Fehler auf, so kann vor deren Abschluss jederzeit diese abgebrochen und das System auf dem Quell-Hypervisor weiter betrieben werden.

Die Schritte der Migration im Einzelnen:

• 1. Anlegen eines neuen Gasts auf dem Zielsystem

• 2. Kopieren des Inhalts des Hauptspeichers vom Quell zum Zielsystem

• 3. Anhalten des Gasts auf dem Quellsystem

• 4. Kopieren von Zustandsinformationen (Prozessoren, Geräte, etc.) auf das Zielsystem

• 5. Start des Gasts auf dem Zielsystem

Die Migration sämtlicher Daten erfolgt dabei über verschlüsselte Verbindungen im Netzwerk. Da die Dauer, während der Gast weder auf Quell- noch auf dem Zielsystem läuft (Schritte 3-5) deutlich unter einer Sekunde liegt, tritt hier praktisch kein Produktivitätsausfall auf.

Die neueste IBM Z Generation „z14“ wurde im Juli angekündigt. Support für alle wesentlichen neuen Features liegt bereits in den Open-Source-Paketen (Linux, QEMU, libvirt) vor oder ist in Arbeit.

Erster! Z14 verschlüsselt alle Daten auf jeder Ebene

Mainframe verteidigt seine zentrale Bedeutung und bringt alles mit für noch mehr Macht

Die wichtigsten Features für KVM-Gäste:

• Instruction Execution Protection: Hierbei handelt es sich um ein sicherheitsrelevantes Feature das verhindert, dass Inhalte in etwa als Datensegmente gekennzeichneten Speicherseiten in Gästen ausgeführt werden können.

• SIMD Extensions: Neue Vektorinstruktionen des Prozessors, mittels derer die gleiche Operation auf mehreren Datensätzen gleichzeitig ausgeführt werden kann, was zu deutlichen Performance-Gewinnen führt.

• Pauseless Garbage Collection: Mit diesem Feature kann die Garbage Collection einer Java Runtime annähernd ohne Unterbrechung der Anwendungen erfolgen, womit der berüchtigte „GC-Schluckauf“ der Vergangenheit angehört.

Derzeit ist KVM für IBM Z regulärer Bestandteil von „Suse SLES 12SP1“ oder höher, sowie Ubuntu 16.04 und höher.

Weiteres Wissen:

Über die neuesten Upstream-Entwicklungen von KVM auf IBM Z wird in dem IBM-Blog berichtet.

Enterprise Security mit System Z

mehr zu Kernel Virtual Machine, KVM

Das libvirt-Projekt

* Viktor Mihajlovski ist Architekt für KVM auf IBM Z und Stefan Raspl ist der Development Lead KVM sowie Netzwerk Architekt für Linux auf IBM Z. Beide arbeiten im deutschen IBM Forschungs- und Entwicklungszentrum bei Stuttgart.

(ID:44872389)