© Takayuki ISHIHARA, 123RF

Die Zeiten, in denen Admins das Management virtueller Maschinen an der Konsole erledigen mussten, sind vorbei. Die Konkurrenz für VMware und Citrix tischt ebenso anspruchsvolle GUIs auf. Mit Ovirt gibt jetzt Red Hat eine freie Java-Oberfläche für die Libvirt frei.

Virtualisierung und kein Ende: Jeder IT-Dienstleister und -Entwickler, der gegenwärtig ernst genommen werden will, muss ein Virtualisierungsmanagement in seinem Menü haben. Die Vier-Sterne-Köche von VMware (ESX, [1]) und Citrix (Xen Server, [2]) haben es vorgemacht: Virtualisierung taugt für den Geschmack der Mehrheit, zumindest dann, wenn sie mit einer schönen Oberfläche daherkommt und so für Admins per Mausklick bedienbar ist.

Entgegen allen Unkenrufen verschmähen nämlich auch Profis komfortable Interfaces nicht, außerdem ist nicht jeder Linux-Admin ein Kommandozeilen-Ass. Für Produkte, die die Administration von virtuellen Maschinen erleichtern, ist also mehr als genug Bedarf. Diese Tatsache ist auch Red Hat nicht entgangen. Der weltweit umsatzstärkste Linux-Distributor steckt in dieser Hinsicht allerdings in einem Dilemma: Die gängigen Management-Interfaces sind entweder streng herstellerspezifisch und proprietär (wie Citrix Xen Server und VMware ESXi) oder taugen weder für hohe Ansprüche noch den Massenmarkt [3].

Die Libvirt [4], die sich auf Linux-Systemen zum Standard für virtuelle Maschinen gemausert hat, funktioniert zwar ausgezeichnet. Der »virt-manager« , der als ihre grafische Benutzerschnittstelle dient, taugt allerdings nur sehr begrenzt; ganze Rechnerschwärme zu verwalten gelingt nicht, weil er dafür auch nie konzipiert war. Für Red Hats Enterprise Virtualization Management [5] kam er jedenfalls nicht in Frage.

Von Qumranet zu RHEV

Die Firma aus Raleigh in North Carolina tat das, was Konzerne in solchen Fällen fast immer tun: Sie kaufte 2008 für 107 Millionen Dollar Qumranet [6], einen israelischen KVM-Spezialisten, und begann, dessen Produkt Solid ICE umzustricken. Besonders die lästige Active-Directory- und Dotnet-Abhängigkeit war dem Linux-Distributor verständlicherweise ein Dorn im Auge. Doch den zu entfernen, schien leichter gesagt als getan: Fast vier Jahre brauchten die Entwickler mit den roten Hüten, um die bisweilen als regelrecht peinlich wahrgenommene Situation zu ändern. Ein Red-Hat-Produkt, das nur mit Windows-Servern und -Clients verwaltbar ist?

Erst 2011 war es so weit, Red Hat präsentierte RHEV – die Red Hat Enterprise Virtualization [7]. 2012 sollen endlich alle hässlichen Abhängigkeiten beseitigt sein, ein reines Linux-Produkt als Konkurrent für Platzhirsch VMware scheint geboren, und RHEV bietet zum Steuern der VMs eine hübsche Libvirt-Oberfläche auf Java-Grundlage.

Künftig will Red Hat sogar mit offenen Karten spielen, zumindest was seine Virtualisierungslösung angeht. Anfang Dezember gaben die Amerikaner ihre Entwicklung mit viel Trara – traditionsgemäß wie bei Spacewalk [8] – auch unter einer Open-Source-Lizenz frei und machte sie zum Teil des Ovirt-Projekts [9]. Bei dem handelte es sich bisher um eine kastrierte Version von RHEV. Anfang Februar zelebrierte Ovirt die erste Release (passend zu RHEV gleich als Version 3.0) in neuer Aufstellung und lag damit voll im Plan (Abbildung 1).

Abbildung 1: Die Benutzerkonfiguration in Ovirt ist ausgesprochen fein granuliert und erlaubt vielfältige Einstellungen in mehreren Ansichtsvarianten.

Mit viel Unterstützung aus der Industrie

Dabei hat Red Hat sich auch Rückendeckung besorgt: Um VMware Einhalt zu gebieten, haben sich die Rothüte vor der Veröffentlichung der Unterstützung gewichtiger Partner versichert: IBM propagiert Ovirt genauso wie Suse, Canonical oder Intel. Die Unternehmen stellen sogar Entwickler ab, die sich fortan an der Ovirt-Entwicklung beteiligen sollen. Netapp ist ebenfalls mit im Boot und soll sicherstellen, dass sich die hauseigenen Storages gut in die Virtualisierungslösung einfügen.

Das neue Ovirt besteht aus insgesamt sieben Komponenten. Der Name Ovirt steht also viel weniger für ein fertiges Programm, sondern eher für die Komposition der Einzelteile, die schließlich zu einer komfortablen Verwaltung virtueller Maschinen führt. Die zentrale Komponente ist die Ovirt-Engine, die Management-Instanz.

Dieser Motor läuft nur auf einem Rechner innerhalb der Virtualisierungsumgebung (Abbildung 2). Für ihn stehen zwei verschiedene Interfaces zur Verfügung: ein CLI-basiertes und eines auf Basis von SDK. Ebenfalls von großer Bedeutung ist VDSM. Diese Abkürzung begegnet dem Admin bei Ovirt sehr häufig, das Kürzel steht für Virtual Desktop and Server Manager. Vereinfacht ausgedrückt ist VDSM die Brücke, die die Engine benötigt, um Befehle auf den tatsächlichen Virtualisierungshosts auszuführen.

Abbildung 2: Die einzelnen Komponenten von Ovirt spielen über SOAP, HTTPS, SSH und SSL zusammen und integrieren externe Datenquellen.

Ovirt-DWH ist das Data Warehouse und damit das alte Ovirt-Werkzeug zum Erstellen von Statistiken. Sein Nachfolger ist auch schon an Bord und hört auf den Namen Reports. Ovirt-Guest-Agent als siebte Komponente läuft in den virtuellen Maschinen, die von Ovirt verwaltet werden, und führt dort Befehle aus, die die Administratoren über die Ovirt-Engine und das VDSM an die virtuellen Maschinen schicken.

Nur mit Fedora gut

Erwartungsgemäß testet Red Hat die Installation vor allem auf RHEL- und Fedora-Systemen. Für Systeme von anderen Distributoren wie Ubuntu existieren zwar Installationsanleitungen [10], allerdings sind diese teilweise nicht mehr aktuell. Immerhin existieren »make« -Targets, um RPM-Pakete zu erstellen. Debian-basierte Systeme mit »dpkg« schauen aber noch in die Röhre, hier ist für den Admin Handarbeit angesagt.

Bevor ein Admin mit Ovirt loslegen kann, muss er einige Vorbereitungen treffen. Zusätzlich zu Ovirt braucht er nämlich auch eine Java-Umgebung mit Jboss, Apache und allem Drum und Dran. Hinzu kommt eine PostgreSQL-Datenbank, in der alle Daten der Engine landen. Mal eben schnell und zwischendurch ist Ovirt also nicht zu haben – wohl ein Effekt des frühen Stadiums, in dem sich das neue Ovirt im Augenblick befindet.

Mit Ubuntu gibt’s Probleme

Entsprechend holprig gestaltet sich auf einem System mit Ubuntu 11.10 die Installation: Ist die aktuelle Version der Ovirt-Engine erst mal aus dem Git-Verzeichnis des Projekts heruntergeladen, folgt eine ganze Menge Schritte mit dem Java-Buildsystem Maven [11]. Die Installationsanleitung für Ubuntu ist an manchen Stellen unvollständig, während des Tests behinderten außerdem Bugs den Vorgang. Das Deployment der Ovirt-Engine, also das Kopieren der Jar-Files ins Root-Verzeichnis von Jboss, klappte im Test beispielsweise erst, nachdem die entsprechenden Maven-Anweisungen händisch korrigiert waren.

Wer die Engine installiert und sich entsprechend lange in Geduld geübt hat (die Installation dauert je nach Hardware etliche Minuten), wird zum Schluss mit dem Login-Prompt für das Webinterface belohnt (»http://Ovirt-Server/webadmin« , Abbildung 3). Die Login-Daten sind »admin@internal« und »letmein!« . Klappt der Login, präsentiert sich das Ovirt-Webinterface, das freilich etwas spartanisch anmutet (Abbildung 4).

Abbildung 3: Nach der Ovirt-Installation präsentiert sich das Login-Fenster im Browser.

Abbildung 4: Das Ovirt-Dashboard sieht bei frischen Installationen zunächst etwas karg aus.

Grundsätzlich unterteilt sich der Arbeitsbereich innerhalb des Web-GUI in zwei Bereiche. Links lassen sich einzelne »Data Centers« auswählen. Innerhalb von Ovirt ist das Datacenter die oberste Konfigurationseinheit. Alle Virtualisierungshosts innerhalb von Ovirt gehören zu Datacentern und sind diesen nach bestimmten Kriterien zugeordnet: So lassen sich Hosts zum Beispiel in ein Datacenter integrieren, weil sie denselben Storage verwenden. Welcher Storage für ein Datacenter zum Einsatz kommt, ist schon beim Anlegen desselben anzugeben: Im Augenblick unterstützt Ovirt I-SCSI, Fibre Channel, NFS und lokalen Storage auf den Virtualisierungshosts.

Menü-Strukturen

Neben der Auswahl eines bestimmten Datacenters findet sich im linken Teil des Web-GUI auch eine Lesezeichenfunktion, damit auch jene Admins den Überblick nicht verlieren, die viele Datacenter gleichzeitig verwalten. Ovirts Architektur bietet die Möglichkeit, von einem Server aus, auf dem die Engine läuft, viele Virtualisierungshosts zu verwalten. Und das sogar dann, wenn diese nicht im selben Netzwerk oder Rechenzentrum stehen wie der Server mit der Engine. Der Motor wird in diesem Falle zu einem Konfigurationsclient, der sich dank Netzwerkverbindung praktisch überall verwenden lässt.

Um sich alle Rechner des aktuell ausgewählten Datacenters anzeigen zu lassen, beherrscht die »System« -Übersicht übrigens mehrere Darstellungsvarianten, nicht zuletzt auch die typische Baumansicht. Der rechte Teil des GUI-Fensters listet alle Ressourcen auf, die Ovirt kennt. Die Ansicht teilt sich in einzelne Registerreiter: Neben einer Liste aller Datacenter lassen sich hier auch konfigurierte Cluster und Hosts anzeigen, zudem verfügbare Storages, alle virtuellen Maschinen, und die konfigurierten Pools.

Über solche Becken fasst Ovirt verschiedene Rechner zu größeren Gruppen zusammen, die der Admin mit einzelnen Aufgaben betrauen kann. Pools bilden quasi eine Untereinheit der Datacenter. In den Augen vieler Ovirt-Entwickler sind Pools aber sinnvoll nur aus solchen Servern zu bilden, die tatsächlich über ähnliche Ressourcen verfügen.

Nicht zuletzt bietet der Open Virtualization Manager im Reiter »Users« auch einen Überblick über die vorhandenen Benutzer – zumindest dann, wenn man sich als Admin einloggt und tatsächlich auch das Webadmin-GUI nimmt. Zusätzlich kommt Ovirt nämlich auch mit einem GUI, das sich an User richtet und im Wesentlichen das Anlegen neuer VMs erlaubt (Abbildung 5). Die Benutzerverwaltung lässt den Schluss zu, dass Ovirt sehr fein granuliert, wenn es um Zugangsberechtigungen geht: Nahezu jede Teilaufgabe lässt sich Benutzern erlauben oder verbieten.

Abbildung 5: Neben dem Webadmin-Interface steht für einfache Benutzer auch ein User-Portal bereit, über das diese neue VMs anlegen und Statistiken einsehen können.

Ovirt-Verwaltung

Die Hauptaufgabe des Admin bei Ovirt ist es, den Überblick über sämtliche Ressourcen zu behalten, die die Plattform benutzt. Ist ein Datacenter angelegt, dann gilt es, Hosts zu definieren, die zu ihm gehören. Auf jedem Rechner, der in Ovirt zu erfassen ist, muss VDSM installiert und konfiguriert sein. Das gestaltet sich schwieriger, als man glaubt: Intern arbeitet die Lösung durchgängig mit SSL und ist für die entsprechenden Zertifikate auf eine PKI angewiesen – am besten natürlich auf eine ohnehin vorhandene. Im Test erwiesen sich allerdings einige der SSL-Skripte aus Ovirt als fehlerbehaftet und spielten erst nach händischer Korrektur mit.

Ist die PKI aufgesetzt und VDSM installiert, lässt sich der neue Gastgeber über das Webinterface als »Host« hinzufügen. Storages haben einen eigenen Menüpunkt und lassen sich in Domains einteilen. Das mag imposant klingen, letztlich sind Domains in Ovirt aber vor allem Labels, um einzelne Speicherbackends zusammenzufassen. Auch Storages muss der Administrator noch händisch über das GUI definieren.

Sind Hosts einem Datacenter zugewiesen und ist freier Storage vorhanden, können sich Benutzer über das GUI anschließend eine neue VM einfach zusammenklicken. Will ein Admin seinen Anwendern diese Aufgabe noch leichter machen, kann er Templates anlegen, die mit wenigen Mausklicks eine neue VM ins Leben rufen. Ovirt hat an dieser Stelle offensichtlich bei den gängigen Cloudlösungen abgeschaut, wo neue VMs genauso unkompliziert entstehen.

Sniplets, Templates, Plug & Play

Im Hintergrund werkeln die Ovirt-Engine, VDSM und die Libvirt dabei fleißig zusammen, damit kein Sand ins Getriebe kommt: VDSM spuckt von konfigurierten VMs fertige Sniplets aus, die sich auf den einzelnen Hosts in die laufende Libvirt laden lassen. Anschließend startet VDSM sie und verwendet Libvirt auch dazu, sich über den Status der VMs auf den Hosts auf dem Laufenden zu halten. Geht zwischendurch etwas schief, erfährt der Admin das durch den »Alerts« -Button im GUI. An dieser Stelle kommt auch der »ovirt-guest-agent« ins Spiel: Er ist in Python geschrieben, läuft auf sämtlichen virtuellen Maschinen und kommuniziert über ein serielles Virtio-Device mit VDSM.

Der Vorteil dieser Konstruktion ist, dass die Kommunikation mit dem Agenten kein Netzwerk in der VM voraussetzt. Der Agent informiert VDSM über verschiedene Aspekte innerhalb der virtuellen Maschine einerseits und erlaubt es VDSM andererseits, Geräte per Plug&Play hinzuzufügen oder Befehle in einer VM auszuführen. Er unterstützt derzeit neben diversen Linux-Distributionen auch viele Versionen von Windows.

Ovirt besteht keineswegs darauf, dass alle Kommandos vom Admin über das Web-GUI den Weg zur Ovirt-Engine finden. Red Hat hat Mitleid mit geplagten Technikern, die gelegentlich Befehle auch in Form von Shellskripten absetzen wollen. Die Engine kommt mit einem vollständigen RESTful-Interface daher, sodass sich Befehle letztlich sogar mittels »wget« absetzen lassen und dennoch das gewünschte Ziel erreichen.

Roadmap, HA, Sicherheit

Zwar sind die Ovirt-Funktionen schon jetzt beeindruckend, doch die Ovirt-Entwicklung kommt gerade erst in Schwung. Anfang November gaben sich die einschlägigen Red-Hat-Entwickler beim ersten Ovirt-Meeting ein kleines Stelldichein mit Big Playern der IT-Branche [12]. Wie schon erwähnt diente die Veranstaltung auch als PR-Coup, um der Veröffentlichung der vormaligen RHEV-Quellen einen etwas feierlichen Rahmen zu verpassen.

Zeit zum Verschnaufen bleibt nach Version 1.0 aber angesichts der vollgepackten Roadmap kaum: Allein die To-do-Liste für VDSM füllt mehrere Bildschirmseiten und umfasst Punkte wie ein besseres Monitoring und ein umfassendes RESTful-Interface (Representational State Transfer, [13]) für VDSM, wie die Ovirt-Engine es bereits besitzt.

Bestehende Funktionen wollen die Entwickler weiter ausbauen: Für frühere Versionen von Ovirt gab es bereits experimentelle Gluster-FS-Unterstützung, aber damals gehörte Gluster noch nicht zum Red-Hat-Konzern. Es ist unschwer zu erraten, dass Gluster in Ovirt in naher Zukunft eine prominentere Stellung einnehmen wird.

Hochverfügbarkeit ist ebenfalls ein Thema, mit dem die Entwickler sich noch beschäftigen müssen. Die gängige Clusterlösung Pacemaker kommt in Ovirt gegenwärtig nicht zum Einsatz, allerdings steht zu vermuten, dass sich das auf Host-Ebene bald ändern wird. Denn insbesondere der Host, auf dem die Engine läuft, braucht Hochverfügbarkeit, weil ohne ihn die gesamte Umgebung in der Luft hängt.

Auch in den virtuellen Maschinen spielt die Sicherheit der Daten eine besondere Rolle. Unterstützung für SE Linux gehört bei Ovirt genauso zum Lieferumfang wie vom Admin einstellbare Einschränkungen für virtuelle Maschinen. Außerdem propagieren die Programmierer die Vorteile von KVM: Weil das schon länger gut in den Kernel integriert sei, unterliege die Virtualisierung ständiger Kontrolle und mache es Angreifern sehr schwer, auf andere VMs des gleichen Gastgebers zuzugreifen.

Interessierten Entwicklern bietet Ovirt ein eigenes SDK: Das “Ovirt Engine Software Development Kit” gibt Programmierern vollständigen Zugriff auf alle Ovirt-Funktionen der Engine. Python hält nach Open Stack bei dieser Gelegenheit Einzug in eine weitere Cloudsuite mit Enterprise-Ansprüchen.

Sterne-Küche mit Macken

Red Hat katapultiert Ovirt mit den neuen Komponenten in die erste Klasse der Lösungen fürs Virtualisierungsmanagement. Die Umgebung positioniert sich geschickt in einer Lücke: Sie bietet funktionierende und ansehnliche Verwaltung virtueller Maschinen auf Grundlage von quelloffener Software, insbesondere KVM. Ovirt rüttelt insofern kräftig an der Vormacht von VMware und Citrix.

So erfreulich die Entwicklung von Ovirt ist, so viele Punkte gibt es auch, die noch einiges an Arbeit benötigen. Doch ist es lobenswert, dass Red Hat bei Ovirt auf die vorhandene Funktionalität der Libvirt setzt statt dem “Not invented here”-Syndrom zu erliegen und eine neue Lösung für die Interaktion mit VMs auf tiefster Ebene zu schaffen.

Libvirt mit Tunnelblick

Ovirt profitiert deutlich von der Stabilität der Libvirt, die seit einigen Jahren kontinuierlich gepflegt und weiterentwickelt wird. Bei vielen anderen Themen fällt der Sponsor Red Hat aber in alte Gewohnheiten zurück: Wirklich problemlos installierbar ist Ovirt bis dato beispielsweise nur auf Fedora. Red Hat demonstriert hier einmal mehr einen Tunnelblick, der fast schon zur Konzernpolitik gehört, und ignoriert die Existenz anderer Distributionen hartnäckig. Mittel- und langfristig muss dieses Problem aus der Welt, wenn Ovirt sich wirklich als Alternative etablieren soll.

Abgesehen davon wäre es wenig sinnvoll, Ovirt erst um die Komponenten von RHEV zu erweitern und anschließend nicht von den Vorteilen, die die Freigabe unter einer offenen Lizenz mit sich bringt, auch zu profitieren. Zweifellos sind hier auch die Anbieter anderer Distributionen gefragt, denn ihre Aufgabe wird es sein, qualitativ hochwertige Pakete von Ovirt zur Verfügung zu stellen.

Angesichts des frühen Stadiums, in dem das neue Ovirt sich noch befindet, lässt sich über dieses Problem allerdings hinwegsehen. Wer sich mit der neuen Lösung fürs VM-Management unter Linux befassen möchte, der nehme sich ein paar Stunden Zeit und mindestens zwei Server zur Hand und experimentiere mit den Ovirt-Komponenten auf einem Fedora-System. Self-contained Setups, also solche mit nur einem Server, der gleichzeitig Gastgeber und Gast spielt, funktionieren derzeit nicht und andere Distributionen machen noch keinen Spaß.

Fazit

Bleibt die Lösung in der Spur, wird sie Linux-Admins noch viel Freude bereiten und eine Alternative zu Open Stack & Co. werden, zumindest was kleine Setups angeht. Ovirt macht auch deutlich, dass die Grenzen zwischen Virtualisierungsumgebungen und den gängigen Cloudlösungen fließend sind.