Mit dem Nachfolger der Virtual Infrastructure 3, unter dem neuen Namen Vsphere 4 [1] auf dem Markt, versucht sich der Platzhirsch im Virtualisierungsrevier zu behaupten. 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 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. VMwares ESX muss sich daher selbst um Hardwaretreiber kümmern, ist aber unabhängig von etwaigen Fehlern des Betriebssystems.
Eine VMware-Cloud (Vcloud) besteht dabei aus mehreren ESX-Servern, die ein zentrales Vcenter (Abbildung 1) verwaltet. Als Standardwerkzeug dafür dient dem Administrator der Vsphere-Client (Abbildung 2). Der wiederum steuert die ESX-Server beispielsweise über deren Servicekonsole, einem mitgelieferten, abgespeckten Red-Hat-Linux als virtuellem Host.
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.
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:
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].
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 die 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.
Mindestens eine virtuelle Maschine mit Windows ist also notwendig, um alle Funktionen zu nutzen. Mit dieser kann sich der Linuxer per RDP verbinden und die 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 Skripting-Funktionen nutzen.
Dem reinen Linux-Anwender bleibt nur das Skripting 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 Cent OS 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].