© Adam Wolszczak, 123RF.com

Mit dem Nachfolger der Virtual Infrastructure 3, unter dem neuen Namen Vsphere 4 [1] auf dem Markt, betreibt der Platzhirsch unter den Virtualisierungen sichtbar seine Revierpflege. Hinter dem Namen verbirgt sich eine Suite von Produkten: von den Essentials für Einsteiger über Standard und Advanced bis zur Enterprise-Plus-Version für große Umgebungen. Die Unterschiede liegen vor allem in der Flexibilität beim Zuweisen virtueller Hardware und natürlich im Preis. Den VMware Vsphere 4 ESXi Single Server gibt\’s zwar kostenlos zum Testen, mittlere Setups rangieren aber schnell bei 100000 Euro und mehr [2].

Vsphere setzt bei ihren ESX-Systemen auf einen Typ-1-Hypervisor, der direkt auf der Hardware läuft, im Gegensatz zu Produkten wie Xen oder KVM, die als Typ-2-Hypervisor auf einem Betriebssystem aufsetzen. Der Nachteil ist offensichtlich: VMwares ESX muss sich selbst um Hardwaretreiber kümmern, ist dafür aber unabhängig von etwaigen Fehlern des Betriebssystems darunter.

Eine VMware-Cloud (Vcloud) besteht dabei aus mehreren ESX-Servern, die ein zentrales Vcenter (Abbildung 1) verwaltet. Als Stadardwerkzeug dafür dient dem Admin der Vsphere-Client (Abbildung 2). Der wiederum steuert die ESX-Server beispielsweise über deren Servicekonsole, einem mitgelieferten, abgespeckten Red-Hat-Linux als virtuellem Host.

Abbildung 1: Vsphere bietet Verwaltungstools, mit denen Administratoren – allerdings nur unter Windows – auch große ESX-Server-Farmen verwalten.

Abbildung 2: Der umfangreiche Vsphere-Windows-Client beherrscht auch komplexeste Funktionen.

HA und Green IT

Die Vsphere 4 kann ihren Gästen 255 GByte RAM und bis zu acht virtuelle CPUs zuweisen. Sowohl Speicher als auch Prozessoren lassen sich den Hosts im laufenden Betrieb on the Fly zuordnen – wenn das Gastsystem solche Operationen unterstützt.

Für die HA-Anwender interessant ist das als Fehlertoleranz (Fault Tolerance, FT) bezeichnete Feature, mit dem VMware einen Gast auf zwei Wirtsmaschinen gleichzeitig betreibt und beim Ausfall automatisch umschaltet. Die Technik unterliegt dabei allerdings einigen Einschränkungen: Ein FT-Gastsystem muss mit einem einzigen virtuellen Prozessor auskommen und seine Daten auf einem externen Speicher ablegen. Das Erstellen von Snapshots ist in derartigen Szenarios nicht möglich.

Ein Alleinstellungsmerkmal von Vsphere sind die Green-IT-Features. Das Distributed Power Management verschiebt die Gastsysteme einerseits bei hoher Last zwischen physikalischen Servern, um die Hardware-Ressourcen möglichst gleichmäßig auszunutzen. Sinkt andererseits die Last auf den Servern, zum Beispiel wenn die Mitarbeiter abends die Arbeitsplätze verlassen, konzentriert der Ressourcen-Verteiler automatisch die laufenden Gastsysteme auf so wenige Wirtssysteme wie möglich und schaltet die überzähligen Maschinen ab. Steigt die Last wieder, weckt er die schlafenden Server selbstständig.

APIs, Storage und PCI

Unter der Bezeichung VM-Safe erlaubt VMware den Herstellern von Antivirus- und sonstiger Sicherheitssoftware über drei Schnittstellen die direkte Integration in die Hypervisor-Schicht. Die APIs kümmern sich um unterschiedliche Datenströme:

• Das V-Compute-API ermöglicht es, Speicherzugriffe und den
  CPU-Status zu inspizieren.
• Das V-Network-Appliance-API, auch DV-Filter genannt, bildet
  einen Paketfilter zwischen der virtuellen Netzwerkkarte und dem
  virtuellen Switch. Mit DV-Filtern ist jede Art der
  Paketmanipulation möglich, beispielsweise lässt sich an
  dieser Stelle eine Firewall platzieren.
• Das Virtual-Disk-Development-Kit-API (VDDK-API) und das
  zugehörige Entwicklungsframework erlauben Antivirus-Software,
  die nicht mehr in der virtuellen Maschine selbst installiert sein
  muss.

Von diesen, angeblich sehr mächtigen Schnittstellen ist aber nur das VDDK-API öffentlich zugänglich, die Nutzung der V-Compute- und DV-Filter-APIs ist auf ausgewählte Partnerfirmen beschränkt. Welche Nutzungsmöglichkeiten die Partner noch aus dem Hut zaubern, bleibt offen. In einem Blog schrieb VMwares Sicherheitsarchitekt Michael Haynes vor wenigen Wochen, dass zumindest für das DV-Filter-API Pläne existieren, “die deutlich über den Einsatz als Sicherheits-Bordmittel hinausgehen” [3].

PCI und GUIs

Seit Vsphere 4 können Admins auch eine im Wirtssystem steckende PCI-Karte an das Gastsystem durchreichen, wie das Xen oder KVM ebenfalls beherrschen [4]. Das bietet beispielsweise die Möglichkeit, einen Faxserver über Remote-Capi und mit Hilfe einer im Server eingebauten ISDN-Karte zu virtualisieren.

Die Liste der technischen Features von Vsphere ist lang, für Linux-Admins bleibt ein großer Haken: Die Standardoberflächen für die Administration, also Vcenter und der Vsphere-Client sind reine Windows-Applikationen, die auch nicht unter Wine zum Laufen zu bringen sind. Zwar können Admins freier Betriebssysteme auf das Vsphere-Web-GUI zurückgreifen (Abbildung 3). Mit diesem sind aber viele Funktionen wie Vmotion, Storage Motion, Cloning oder Updates nicht möglich, sodass die Open-Source-Welt ausgesperrt bleibt.

Abbildung 3: Das Web-GUI ist nur ein schwacher, weil nicht vollständiger Ersatz einer Applikation für Linux-Administratoren. Der Funktionsumfang lässt wenig mehr als das Starten und Stoppen der VMs zu.

Windows only

Mindestens eine virtuelle Maschine mit Windows ist also notwendig, um alle Funktionen zu nutzen. Mit dieser kann sich der Linuxer per RDP verbinden und das GUI so zumindest übers Netz nutzen. Immerhin lassen sich auf den Service-Konsolen der ESX-Server (Abbildung 4) mit dem installierten VMware-CLI auch die Scripting-Funktionen nutzen.

Abbildung 4: Auch wenn die mitgelieferte virtuelle Linux-Maschine es vermuten lässt: Das Betriebssystem des ESX-Hypervisors ist kein Linux, sondern eine VMware-Eigenentwicklung.

CLI-Scripting

Dem reinen Linux-Anwender bleibt nur das Scripting der einzelnen ESX-Server mit den umfangreichen CLI-Tools (Abbildung 5). Diese mit »vmware-« beginnenden Kommandos erweisen sich als mächtig und gestatten es, auf einzelne Hosts in einer Vsphere remote zuzugreifen. Folgendes Kommando installiert sie auf Centos 5.5 (zusammen mit dem notwendigen Perl-SSLeay-Modul):

yum install perl-Crypt-SSLeay
tar xzvf VMware-vSphere-CLI-4.0.0-161974.
i386.tar.gz
cd vmware-vsphere-cli-distrib/
./vmware-install.pl

Der Befehl »vmware-cmd -l« listet dann alle registrierten VMs auf, »vmware-cmd -s un|register« fügt neue Hosts hinzu oder entfernt diese aus dem Verwaltungsbereich. »-H« definiert den Server, »-T« den Targethost in einem Virtual Center. »-O« und »-Q« bestimmen Port und Protokoll, »-U« und »-P« Usernamen und Passwort für den Login. »-v« aktiviert den Debugging-Modus. Das Kommando in Abbildung 5 verbindet den Benutzer mit »Vcenter4« und weiter auf den Targethost »esx02«. Tabelle 1 zeigt einen Ausschnitt aus den umfangreichen Fähigkeiten. Mehr Details, auch zu vielen nützlichen Modulen wie »vlcfg-iscsi« oder »vlcfg-snmp«, bietet das Onlinehandbuch [5].

Abbildung 5: Das CLI funktioniert auf einem frisch installierten Centos 5.5, macht aber Probleme mit dem Perl-SSLeay-Modul. Obwohl dies die neueste Version ist, meckert das VMware-CLI schon bei der Installation.

Ein kapitaler Hirsch

Vmwares Sphäre ist derzeit das mächtigste Virtualisierungsmanagement, gerade für umfangreiche Setups. Im Rechenzentrum Niederrhein verwalten die Admins 25 ESX-Server mit 530 virtuellen Windows-, SLES- und Ubuntu-Hosts. Schade nur, dass ohne Windows die meisten Features nicht nutzbar sind.

Tabelle 1: »vmware-cmd«