© french_03, Photocase.com

Der Lateiner kennt “Virtus” als die Tugend, die es oft vorzutäuschen gilt, genau wie moderne Virtualisierungslösungen die Hardware. Jetzt droht auch Red Hat, mit dem Produkt RHEV mit- und die Konkurrenz aufzumischen. Doch die rote Tugend hat so manchen dunklen Fleck .

Das lateinische “Virtus” steht für Tugend oder die Tugendhaftigkeit allgemein. Bildungsbürgerliche Kreise zitieren daraufhin gerne Ciceros “Quam non est facilis virtus! Quam vero difficilis eius diuturna simulatio!” (“Wie ist doch die Tugend nicht leicht! Wie schwer aber ist erst ihr ständiges Vortäuschen!”) und schlagen dabei ungewollt eine Brücke zur Virtualisierungstechnologie der IT.

Viele Anbieter

Das ständige Simulieren von Eigenschaften erfordert auch von einem nichtmenschlichen Hypervisor eine gehörige Portion Know-how. Aber richtig eingesetzt, lassen sich damit imposante Setups zusammenbauen, wie es auch der letzte Schwerpunkt im Linux-Magazin zum Thema Cloud Computing zeigt [1]. In der Unternehmens-IT ist Virtualisierung ein Dauerthema, nicht nur bei Infrastruktur-Betreibern, ISPs und Hostern.

Seit VMware mit der Workstation Ende der neunziger Jahre faszinierende neue Nutzungsszenarien vorstellte und sich zum Trendsetter erhob, ist das Thema ein Massenmarkt geworden.

Die Konkurrenzprodukte schossen wie Pilze aus den Boden: Das Spektrum reicht von Microsofts Virtual PC, Parallels [2], Virtual Box [3], User Mode Linux [4], Open VZ [5], Virtuozzo ([6], Linux Vserver [7], Citrix/Xen [8] bis zur im Linux-Kernel enthaltenen Virtual Machine KVM [9]. Und jetzt, Jahre später kommt Red Hat und verlautbart überraschenderweise, viele Unternehmen hätten noch nicht einmal mit Virtualisierung begonnen, geschweige denn darüber nachgedacht.

Rote Hüte im Anmarsch

Natürlich haben die Marketingspezialisten mit den roten Hüten auch ein passendes Produkt im Gepäck. Ende 2008 hatte der Distributionsanbieter den KVM-Management-Hersteller Qumranet übernommen, frisch überarbeitet und angepasst kam 2009 dessen Managementsuite als Red Hat Enterprise Virtualization RHEV auf den Markt (Abbildung 1, [10]). Die integriert Werkzeuge zum Konvertieren und Importieren von VMware-Containern und Xen-Domains. Red Hat versteht sie als moderne Cloud, ähnlich wie der Platzhirsch VMwares Vsphere. Bei Redaktionsschluss war die RHEV-Version 2.1 aktuell, aber deren Nachfolger 2.2 soll bald kommen. Noch gibt es zwar nur eine Beta mit der neuen Desktop-Virtualisierung, aber unter der Haube hat Red Hat bereits einiges aufgebohrt. Die Arbeitsspeichergrenze für eine VM von 64 Gbyte ist auf 256 GByte angehoben, das Hypervisor-OS basiert jetzt auf dem Kernel von RHEL 5.5. Im Gastgeber unterstützt RHEV jetzt bis zu 96 CPU-Kerne und 1 TByte RAM.

Abbildung 1: Das RHEV-Management-Interface bietet in der Host-Liste unter »Powermanagement« die Möglichkeit, den Status aller laufenden virtuellen Maschinen abzufragen und neue zu starten.

KVM von Qumranet

Die Intention ist klar: Red Hat will sich nach dem Kauf des KVM-Spzialisten Qumranet mit der fieberhaften Weiterentwicklung von RHEV in eine strategisch günstige Position bringen, vor allem da sich das Open-Source-Projekt KVM technologisch als die wohl vielversprechendste Konkurrenz zu den etablierten kommerziellen Konkurrenten VMware, Citrix und Microsoft erwiesen hat.

Im KVM-Kernelcode sind große Teile von Qemu enthalten, die die Flexibilität eines Emulators mit der Eigenschaft kombinieren, die Virtualisierung als eine Betriebssystemfunktion zu implementieren. Etwaige Geschwindigkeitsnachteile kompensiert der Zugriff auf die VT- oder AMD-V-Befehlssätze moderner CPUs, was eine aufwändige und zeitraubende MMU-Emulation obsolet macht (Abbildung 2).

Abbildung 2: Aus Sicht des Kernel implementiert KVM neben dem User- und dem Kernel-Mode eine weitere Betriebsart, in der es virtualisierte Gastsysteme erzeugt, ausführt und verwaltet.

Der wichtigste Nachteil von KVM bestand bisher darin, dass für Windows-Gastsysteme nur wenige Virt-I/O-Treiber existierten. PCI-Passthrough ist durch die vorhandene Hardware eingeschränkt, sodass für die Treiberversorgung am Windows-Gast häufig die langsamere Emulation herhalten muss. Durch das Engagement von Red Hat stehen immerhin einige paravirtualisierte Gastsystemtreiber für Windows-Gäste zur Verfügung.

Ebenbürtig

Dabei nimmt es KVM in Sachen Geschwindigkeit durchaus mit Systemen wie Xen oder VMware ESX auf, lässt sich aber viel einfacher handhaben. Schon das Installieren des Paketes »kvm« genügt im Prinzip, um ohne Reboot oder aufwändige Konfiguration aus einer beliebigen Linux-Distribution einen Hypervisor zu machen (Kasten “KVM mit Libvirt”) Der kann auf Wunsch viel mehr leisten als bei Xen oder VMware ESX, weil nach wie vor ein vollwertiger Linux-Kernel zur Verfügung steht und keine abgespeckte Mini-Variante. Energiespar- und Powermanagement und NUMA-aware Scheduling funktionieren Out-of-the-Box.

Die Red Hat Enterprise Virtualization baut voll auf KVM. Sie gibt es zum Kampfpreis von etwa 500 Euro (plus RHEL-Lizenzen), wobie das Produkt aus einem Standalone-Hypervisor, als Host für virtuelle Linux- und Windows-Server, sowie dem Virtualization Manager for Server besteht. Mit dessen Hilfe lassen sich sich virtuelle Umgebungen einrichten, verwalten und überwachen. Suchfunktionen, Reports und Auswertungen sind ebenso integriert wie umfangreiche Filterfunktionen für Events (Abbildung 3 und 4).

Abbildung 3: Mit der Suchfunktion im Managementinterface RHEV-M lassen sich virtuelle Maschine gezielt filtern, etwa nach OS-Typ und Speicherverbrauch.

Konvertierungstools

Als eine der Neuheiten kann RHEV 2.2 die von VMware und Microsoft verwendeten Imageformate (Vmdk und Vhd) konvertieren, was umstiegswilligen Nutzern anderer Virtualisierungen den Wechsel zum neuen Hypervisor ebnet. Die Red Hat Enterprise Virtualisierung bringt dazu das Konvertierungstool V2V (Virtual-to-Virtual) mit, das auf der Open-Source-Library »libguestfs« [11] basiert.V2V wandelt Virtual-Machine-Images von VMware oder Xen in das Open-Virtualization-Format (OVF) um, das RHEV anschließend problemlos importiert. Dabei beherrscht es zurzeit VMs mit Red Hat Enterprise Linux (RHEL) 3, 4 und 5, Microsoft Windows XP, Server 2003 und 2008. Darüber hinaus existiert in RHEV eine Export-Funktion, mit der Admins VMs und Templates zwischen verschiedenen Installationen transferieren können, die auch als Backup-Lösung taugt.

Das Management gibts nur für Windows-Server

Abbildung 4: Auch das Systemprotokoll in RHEV-M ist umfangreich und einfach zu bedienen. Ereignisse, die den Benutzer »rhev« betreffen, zeigt beispielsweise der Suchstring »Events: user.name = rhel« in der URL.

Zwar besteht Red Hats Lösung im Grunde aus der Qemu-Kernel-Erweiterung, es ergänzt diese aber um eine vollständige Enterprise-Lösung aus mehreren tief integrierten Komponenten.Der Virtualization Manager (RHEV-M) bildet die Kernkomponente und fungiert als Management-Plattform zum Installieren, Konfigurieren und Verwalten von Hypervisors und virtuellen Server- oder Desktopinstanzen. Mit dem im RHEV-Manager eingebauten Data Warehouse (Abbildung 5) lassen sich außerdem mit jedem SQL-Tool Performance-Daten für Hosts, VMs und Speicher sammeln und auswerten.

Abbildung 5: Das eingebaute Data-Warehouse ermöglicht vielfältige Reports und Auswertungen im Management-Interface, hier die CPU-Last der Hosts und Virtuellen Maschinen.

Die eigentlichen Hypervisors (RHEV-H) sind nur minimalistische Red-Hat-Linux-Systeme mit KVM. Der Original-RHEV-H zum Beispiel ist ein rund 100 MByte kleines Thin-Client-Linux, das auch auf einen USB-Stick passt. Alternativ greift der Admin dafür auf ein vorhandenes RHEL 5.4 oder 5.5 zurück. Zur Konfiguration meldet er den RHEV-H an der Management-Konsole RHEV-M an und registriert ihn dort.

Schier unglaublich peinlich für den führenden Linux-Hersteller Red Hat ist jedoch die Tatsache, dass die RHEV-M immer noch eine seinerzeit von Qumranet mit Active Server Pages (ASP) als Solid-ICE-Plattform entwickelte Webapplikation ist, die zwingend einen Microsoft Server 2003 R2 mit Active Directory, einen Microsoft SQL-Server sowie eine .NET-Umgebung verlangt.

Wenn viele Enterprise-Umgebungen auch diese Voraussetzungen erfüllen, bedeutet das doch: Derzeit läuft die Adminoberfläche nur unter Windows. Außerdem müssen alle Benutzer, die sich an RHEV-M anmelden, einen Account im Active Directory haben. Red Hat arbeitet an einer Java-Lösung, wie Gert Janssen beteuert (siehe Kasten “Nachgefragt”).

Ist der Management-Server erst einmal eingerichtet, lassen sich sämtliche logischen und physischen Ressourcen unter der URL [https://localhost/RHEVManager] im Webinterface verwalten, wozu der RHEV-Manager ein eigenes Data Center (Abbildung 6) einrichtet. Anfangs gibt es nur einen davon, es lassen sich aber weitere hinzufügen.

Abbildung 6: RHEV verwaltet sämtliche – logische und physische – Ressourcen in so genannten Data-Centers. Die kann der Admin nach Belieben hinzufügen, nach der Installation gibt es zunächst nur einen davon.

Storage Domains

RHEV-Ressourcen können nicht nur virtuelle Server und Desktops sein, sondern auch Hypervisors, physische RHEL-Hosts, Cluster aus mehreren Hypervisors und/oder RHEL-Hosts, Speicher-Domänen, -Pools oder Netzwerke. Bei beiden Typen von Hostsystemen (RHEV-H Hypervisors und RHEL-Maschinen ab Version 5.4) kommt das KVM-Kernel-Modul zum Einsatz.

Speicher-Domänen sind entweder Data- oder ISO-Domänen. Erstere enthalten die ISO-Images der eigentlichen virtuellen Maschinen entweder in Form virtueller Festplatten-Abbilder im OVF-Format oder als Volume-Snapshots, während ISO-Domänen echte ISO-Dateien zur Installation weiterer virtueller Systeme besitzen.

Als Backend für Speicher-Domänen sind I-SCSI-SANs oder Fibre-Channel-Systeme möglich, wobei LVM zur Verwaltung der Festplatten, Volumes und Partitionen dient. Der physikalische Host mit alleiniger Kontrolle über den Speicherpool heißt im Red-Hat-Jargon Storage Pool Manager (SPM) und muss das erste System im Data-Center-Cluster sein. Nach der Installation des Virtualization Managers gibt es zunächst nur ein Netzwerk mit der Bezeichnung »rhevm«. RHEV unterstützt auch logische Netzwerke in Form von VLAN-Devices.

Virt-I/O-Treiber

Die zweite wichtige Kernkomponente der RHEV-Infrastruktur neben dem Virtualization Manager sind die physikalischen Hostsysteme mit RHEV-H oder RHEL 5. Zur Emulation der I/O-Hardware fungiert bei KVM stets ein modifiziertes Qemu, das Gastsysteme auf drei verschiedene Arten Zugriff auf die Host-Hardware erlaubt. Der performanteste Zugriff erfolgt neben echtem PCI-Passthrough über die angesprochenen Virt-I/O-Devices. Diese paravirtualisierten Treiber existierten im größerem Umfang allerdings bisher nur für Linux-Gastsysteme und sind bei den meisten Distributionen in den Paketquellen enthalten. Für Windows-Systeme gab es vor dem Engagement von Red Hat nur Virt-I/O-Treiber für wenige Netzwerkkarten, die auf der KVM-Treiber-CD [13] zu finden sind.

Im Zuge der Entwicklungsarbeiten an RHEV hat Red Hat weitere paravirtualisierte Netzwerk- und Storage-Treiber zum Betrieb von Windows-Gastsystemen unter KVM freigegeben ([14], Kasten “Nachgefragt”). Außerdem lädt und installiert RHEL ab Version 5.3 die paravirtualisierten KVM-Treiber automatisch, sodass der Admin hier keine weitere Maßnahmen treffen muss. Mit den Virt-I/O-Treibern im Gastsystem liegt die Performance nur marginal hinter der nativen Zugriffsgeschwindigkeit des Hosts, emulierte Treiber dagegen bremsen das System um Größenordnungen aus. Übrigens unterstützt Windows XP als Gastsystem den paravirtualisierten Blocktreiber (»virtio block driver«) nicht, sondern nur den Netzwerktreiber.

RHEV-Hypervisor einrichten

Admins sollten das RHEV-Hypervisor-ISO-Image einem RHEL-System vorziehen, weil das Mini-System optimal an RHEV angepasst ist. So ist zum Beispiel ein optimierter SE-Linux-Kontext an Bord, der einen fein abgestimmten Zugriff der VMs auf alle existenten Ressourcen über die Berücksichtigung der reinen Benutzer- und Prozessidentitäten hinaus (Mandatory Access Control) erlaubt.

Der Admin kann die mitgelieferte ISO-Datei »rhev-hypervisor.iso« wahlweise auf einen USB-Stick, auf eine CD oder auf einen PXE-Server kopieren. Passende Werkzeuge dazu finden sich in allen Red-Hat-basierten Live-CDs. »livecd-iso-to-disk« kopiert es auf einen USB-Stick, »live-iso-to-pexeboot« dagegen extrahiert Kernel und Initrd aus der ISO-Datei und kopiert sie auf einen PXE-Server. Das ISO bannen Standardtools wie Cdrecord auf den Rohling:

cdrecord -v -dev=/dev/cdrom /usr/share/U
rhev-hypervisor/rhv-hypervisor.iso

Zum Installieren von RHEV-H auf dem Host steht ein Setupprogramm zur Verfügung, dem der Admin eine Reihe von Parametern am Bootpromt übergibt. Alternativ dazu hangelt er sich manuell durch die Menüstruktur der GUI (Abbildung 7), etwa um das Netzwerk und das Dateisystem des Hosts zu konfigurieren. Auch muss er dem Host hier das für ihn zuständige Management-System bekanntgeben, wobei das Setup-Programm fast überall sinnvolle Defaultwerte vorschlägt. Ist die Konfiguration vollständig, lässt sich die eigentliche Installation mit »Install locally and Reboot« einleiten. Nach dem Reboot sollte das neue System in der Liste der virtuellen Gäste auf dem Management-System auftauchen.

Noch ein paar Pakete

Soll ein gewöhnlicher RHEL-5-Host als Hypervisor dienen, dann braucht er eine CPU mit Virtualisierungserweiterung (»egrep ‘(vmx|svm)’ /proc/cpuinfo«) und einige zusätzliche Pakete. Neben dem per Default installierten KVM sind das vor allem »kvm-tools«, »bridge-utils« und optional »fence-agents« für Red-Hat-Cluster, in denen jeder ausgefallene Host automatisch rebooten soll.

Da der Hypervisor beim RHEV im Gegensatz zu KVM über das eigens entwickelte Vdsm-Protokoll mit dem Managementsystem kommuniziert, sind neben »vdsm« auch die Pakete »vdsm-reg« und »vdsm-cli« zu installieren. Ersteres sorgt für das Registrieren beim Virtualization Manager, letzteres ermöglicht die Steuerung des Hosts über die Kommandozeile. Damit das auch aus der Ferne funktioniert, muss der Admin außerdem einen SSH-Server installieren.

Dass Red Hat hier noch nicht die Libvirt implementiert, liegt an deren Funktionsumfang (Kasten “Nachgefragt”) und ist nach Aussage von Red Hat nur eine Frage der Zeit. Die Libvirt hat Red Hat ja eigens für KVM und Xen entwickelt, mit ihr kann der Admin virtuelle Maschinen in XML-Dateien konfigurieren und sie dann mit dem Kommando »virsh« bedienen, aber leider noch nicht in RHEV.

Benötigte Ports

Sind die genannten Pakete installiert, sollte der Admin sicherstellen, dass die zugehörigen Dienste »vdsm«, »vdsm-reg« und »sshd« laufen. Letzterer ist auch für die erstmalige Registrierung im Virtualization-Manager erforderlich. Steht zwischen RHEL-Hypervisor und Managementsytem eine Firewall, muss diese die Ports 22 (SSH), 16509 (Libvirt), 54321 (Vdsm), 5634 und 6166 für den Konsolenzugriff auf virtuelle Maschinen sowie 49152 und 49216 für die Live-Migration von VMs zwischen den verschiedenen Hosts weiterleiten.

Nachdem er den oder die Hostsysteme installiert und gestartet, und das Management-System eingerichtet hat, muss der Admin zum Registrieren der Hostsysteme das RHEV-M-Interface »https://RHEV-M-Host/RHEVManager« aufrufen und das System im Menü »Hosts | New« in die Hostliste aufnehmen.

Management

Dabei gibt er neben der IP-Adresse des RHEL- oder RHEV-Hosts auch gleich das Root-Passwort und die Vdsm-Portnummer an. Außerdem muss er den Host einem RHEV-Cluster zuordnen. Ein finaler Klick auf »Ok« leitet den eigentlichen Registrierungsprozess ein, wobei der Host die passende Bootstrap-Datei (ein Python-Skript) vom Managementsystem herunter lädt und ausführt. Danach taucht das System in der Hostliste des Managers auf und kann auf sämtliche Ressourcen des Clusters zugreifen.

Virtuelle Maschinen erstellt der Admin dann im Menü »Virtual Machines | New«. Hier stehen wie in Abbildung 7 verschiedene Templates zur Verfügung, die auf typischen Konfigurationen für CPU, Arbeitsspeicher, Speicher-Domäne, oder Netzwerk basieren. Nach dem Erstellen einer virtuellen Maschine startet diese über den Menüeintrag »Run once«. Zum eigentlichen Installieren eines Gastsystems greift die VM zum Beispiel auf eine ISO-Datei aus der zugehörigen Speicher-Domäne (»Attache-CD«) zurück. Wer einen Red-Hat-Network-Satellite-Server (RHNS) sein eigen nennt, kann hier auch PXE-basierte Installationen nutzen. Verlief das Installieren einer virtuellen Maschine erfolgreich, erscheint die VM anschließend in der Hostliste im Management-Interface.

Abbildung 7: Virtuelle Maschinen lassen sich unter RHEV bequem im Management-Interface erstellen, bearbeiten, starten, verschieben, migrieren und sichern, getrennt nach Servern und Desktops.

Desktop-Virtualisierung

Red Hats Enterprise Virtualisation für Desktops [15] befindet sich derzeit in der Beta-Phase, wobei die nächste RHEV-Version 2.2 das Management für Desktops und Server zusammenführen soll. Der Zugriff auf die Desktops der virtuellen Systeme erweist sich erfahrungsgemäß oft als problematisch und wenig performant, erst recht, sobald Multimedia ins Spiel kommt.

VNC übeträgt bekanntlich den kompletten Bildschirminhalt der virtuellen Desktopinstanz zwischen Server und Thin-Client per Remote Framebuffer Protocol. Das macht VNC zwar plattformunabhängig, aber relativ träge. Für Microsofts Terminalserver RDP gibt es zwar auch Client-Implementierungen für Linux, das Protokoll ist aber genauso wenig für Multimediainhalte geeignet wie VNC. Mediastreaming oder VoIP ist da schier unmöglich, externe Hardware am lokalen Arbeitsplatz anschließen und nutzen geht ebenfalls nicht. Deshalb implementiert Red Hat in RHEV gerade neben den etablierten Standards VNC und RDP das ebenfalls von Qumranet entwickelte Simple Protocol for Independent Computing Environments, kurz Spice [16]. Damit gehören laut Red Hat all diese Probleme künftig der Vergangenheit an.

Es besteht aus einer Mehrschichtarchitektur mit Server, Client und einem Treiber, der innerhalb des virtuellen Desktops installiert ist. Red Hat arbeitet daran, Spice plattformunabhängig zu machen, zurzeit kann es sich beim Client entweder um einen Red Hat Enterprise Linux 5 Desktop oder Windows XP handeln.

Die Serverkomponente von Spice ist ein VDI-Gerät im Hostsystem, das ein PCI-Gerät emuliert. Am Thin-Client kommt entweder ein Browser-Frontend oder eine dedizierte Clientanwendung zum Einsatz. Dabei regelt die Connection-Broker-Komponente im RHEV-M, ob der jeweilige Benutzer Zugriff auf einen dedizierten Desktop oder auf einen Arbeitsplatz aus dem Desktop-Pool erhält.

Diese Zuordnung muss der Admin allerdings schon beim Anlegen der virtuellen Maschinen treffen, indem er jedem virtuellen Desktop explizit die ihm erlaubten Benutzer oder Benutzergruppen zuordnet.

Geduld, Geduld

Red Hat ist auf einem guten Weg, aber den Linux-Admin und Open-Source-Evangelisten wird RHEV an einigen Stellen noch herb enttäuschen. Dass es keine Möglichkeit gibt, unter Linux die Management-Konsole zu benutzen, ist ärgerlich. Aber auch andernorts lauern noch Baustellen (Libvirt/Vdms, Spice), hier ist einfach Warten angesagt.

Dennoch ist RHEV schon jetzt der Beschäftigung Mühe wert: Das Einrichten und die Administration von virtuellen Servern und Desktops gelingt mit Hilfe des Management-Systems wesentlich eleganter als bei einem rein kommandobasierten KVM/Qemu-System. Dass das Ganze nahtlos mit Red Hats Clusterprodukten zusammenspielt, verleiht dem Paket im Open-Source-Bereich einige Alleinstellungsmerkmale. Doch leider braucht es halt auch einen Windows-Server (ab 2003 R2), Active Directory sowie Microsofts SQL-Server und eine .NET-Umgebung.

Wahrscheinlich ärgert es die Bosse in Raleigh selbst am meisten, dass sie seit Jahren nicht in der Lage sind, eine vollständig Linux-basierte Enterprise-Virtualisierung vorzustellen. Trotzdem: Die Richtung stimmt, und Geduld ist schließlich auch eine Tugend.(mfe)