VMware vSphere-Umgebungen lassen sich auf drei Arten administrieren, nämlich per vSphere Web Client, mit dem C#-Windows-Client sowie per Kommandozeile (PowerCLI, RemoteCLI, beziehungsweise direkt am der Host.-Shell oder via SSH). Außerdem lässt sich vSphere per vSphere-API steuern. Nichts anderem machen letztendlich die genannten grafischen Clients.
Hat man keinen zentralen vCenter-Server, muss man auf den Web Client verzichten, weil dieser ein vom vCenter bereit gestellter Service ist. Es dürfte aber in der Praxis nur wenige Nutzer geben, die nur einen einzigen ESXi-Host ohne vCenter betreiben. Dies ist zwar bei ganz kleinen Setups und schmalem Budget theoretisch möglich, allerdings verzichtet man dann auf nahezu alle erweiterten Features, die die Server-Virtualisierung beziehungsweise Server-Konsolidierung für Unternehmen überhaupt erst interessant machen. Dazu zählten Funktionen wie Live-Migration (bei VMware "vMotion" genannt) oder Hochverfügbarkeit und Distributed Ressource Scheduling, die allesamt mindestens einen zweiten ESXi-Host (oder mehr) im Cluster voraussetzen.
Oder anders ausgedrückt: wenn das Budget zur Anschaffung eines vCenter Servers ein Problem darstellt, sollte man den Einsatz der Essentials Versionen (mit funktionslimitierten vCenter) erwägen.
Der vCenter Web Client
Hat man einen vCenter Server, hat man auch zwangsläufig den Web Client; trotzdem kann auf den herkömmlichen/traditionellen, in C# geschriebenen vSphere-Client unter Umständen nicht ganz verzichtet werden. Er stellt zum Einem die offiziell einzige Möglichkeit dar, einen einzelnen ESXi-Host direkt per grafischer Oberfläche zu verwalten, sieht man mal vom Host-Client, einem unsupporteten Fling ab. Hierbei handelt es sich um eine HTML5-basierte Web-Anwendung zur Administration eines einzelnen ESXI-Hosts, die man relativ einfach nachinstallieren kann.
Außerdem ist er der vSphere Client z. B. für den Einsatz des Update Manager unerlässlich. Da VMware zudem die Weiterentwicklung dieses nur unter Windows installierbaren Clients mit der Virtual Machine Version 8 (also mit vSphere 5.0) eingefroren hat, fehlen ihm alle seitdem hinzu gekommenen Funktionen.
Zwar ist der vSphere-Client die einzige Möglichkeit zum Verwalten einzelner ESXi-Hosts, nichsdestotrotz spricht natürlich nichts dagegen, sich mit ihm gegen einen vCenter Server zu verbinden. Die weitaus meisten vSphere-Admins ziehen diese Art der Verwaltung dem Einsatz des Web Clients vor, weil der wiederum andere Nachteile ausweist, die aber zum Teil mit der neuen Version 6 beseitigt wurden. VMware ist der Umstand, dass der native Windows-Client auf Grund der Schwächen des Web-Clients von vielen Admins noch immer bevorzugt wird, durchaus bewusst und hat daher bei der neuen Version 6.0 des vSphere-Clients entgegen den ursprünglichen Plänen doch noch einmal nachgebessert. So wurde er so weit überarbeitet, dass er jetzt VMs auf Basis der aktuellen virtuellen Hardware-Version 11 erstellen und verwalten kann. Allerdings bleibt er dabei auf Funktionen beschränkt, die VMware vor vSphere 5.5 eingeführt hat.
Nachteile des WebClient
Die Ablehnung des Web-Clients vieler vSphere Admins ist (zumindest was die Versionen 5.1 und 5.5 des Web Client betrifft) nicht unbegründet.
• Er ist mit dem Adobe Flex-Entwicklungsframework zum Erstellen von Rich Internet Applications (RIAs) geschrieben, basiert also auf Adobe Flash. Dies ist den Augen vieler Admins nicht nur ein Sicherheitsproblem, Flash war zumindest in Version 5.5 auch der Grund für das träge Verhalten und die spürbaren Performance-Probleme. Performance und Stabilität hat VMware allerdings in Version 6.0 massiv verbessert, so dass dieser Kritikpunkt in der aktuellen Version wegfallen
• Flash ist aber auch der Schuldige, weshalb man den Web Client leider nicht als plattformunabhängiges Werkzeug zur vSphere-Administration bezeichnen darf, denn Plattformunabhängigkeit auf Client-Seite ist ja meist einer der wesentlichen Gründe, überhaupt eine Webanwendung zu entwickeln. Dies liegt daran, dass die gängigen Browser unter Linux den Einsatz von Adobe Flash nicht mehr erlauben, da die Linux-Flash-Version von Adobe seit geraumer Zeit nicht mehr weiter entwickelt wird. Für Chrome gibt es zwar mit Pepperflash eine von Google voran getriebene Alternative, trotzdem ist Flash sicher keine Zukunftstechnologie.
• Ein weiteres Problem des Web Clients besteht darin, dass zum Öffnen der eingebauten VMware Remote Console (VMRC) für einen Konsolen-Zugriff auf virtuelle Maschinen im Vollbildmodus, zum Ausrollen von OVF/OVA-Templates und zum Öffnen des Storage-Browsers für das direkte Hoch- oder Runterladen von Dateien das "VMware vSphere Client Integration Plugin" (CIP) erforderlich ist, das seinerseits noch auf Basis der veralteten NPAPI-Plugin-Architektur entwickelt wurde, die sowohl Chrome als auch Firefox spätestens im kommenden Jahr überhaupt nicht mehr unterstützen werden.
Remote Console mit und ohne HTML5
Unter Linux ist es schon heute schwierig bis unmöglich (bzw. mit nur mit erheblichen Aufwand und Know How), das CIP zu installieren sowie durch Patchen der Browser-Quellcodes i. V. mit Pepperflash für Chromium und einem Wrapper den Web Client überhaupt vollumfänglich nutzen zu können. Die ist zwar nur ein theoretisches Problem, da in komplexen vSphere-Umgebungen im Unternehmen sicher genügend Windows-Maschinen existieren, es passt aber nicht zu Open-Source-Affinität eines Hochtechnologie-Konzerns wie VMware und viele Systemadministratoren schätzen Ihren Linux-Arbeitsplatz. Seit der vSphere-Version 5.5 Update 2b basiert die Remote-Console allerdings auf HTML5 und funktioniert daher auch ohne Installation des CIP. Trotzdem fordern Chrome, Firefox und IE unter Windows beim Aufruf des Web Clients zum Herunterladen und Installieren des CIP auf. Man braucht es ja auch nach wie vor für den Storage-Browser und das OVF-Deployment.
Neue Remote Console VMRC 7.0
Die VMRC (VM Remote Console) selbst hat übrigens im Laufe Ihrer Entwicklung verschiedene Inkarnationen "durchlebt", angefangen von einer Standalone-Windows-Applikation, über ein integriertes Browser-Plugin (Vollbildmodus nur mit CIP) bis hin zum aktuellen HTML5-basierten Browser-Plugin ab vSphere 5.5 Update 2b.
Das geschilderte Problem der NPAPI-Abhängigkeit des CIP im Zusammenhang mit dem alten Browser-Plugin lässt sich auch noch anders aus dem Weg räumen. So bietet VMware die VMRC-Version 7.0 seit einiger Zeit optional als native Standalone-Variante an, die Nutzer von VMwares Downloadseite herunterladen und installieren können.
Die aktuelle Version 7.0 ersetzt zum Beispiel zufriedenstellend die CIP-Abhängigen (Fullscreenmode der alten Flash-Konsole) in älteren Versionen des Web Clients und unterstützt sogar VM-Power-Operationen, d. h. die VM muss im Vergleich zur "alten" Lösung nicht laufen, bevor ein Connect möglich ist, sondern bietet selbst Funktionen zum Steuern der VM in einem separaten Fenster. Darüber hinaus bietet VMRC auch Management-Funktionen, wie das Installieren der VMware-Tools. Anwender können diese Funktion zum Beispiel nutzen, ohne dass Ihnen der Admin Zugriffsrechte im Web Client einräumen muss.
In der Version 6.0 des Web Clients kann man die VMRC-Konsole mit einem Klick auf "Launch Remote Console" im Reiter Summary (Übersicht) der in der Bestandsliste markierten VM direkt öffnen oder - falls sie noch nicht installiert ist - direkt darunter mit dem Link "Download Remote Console" als MSI-Datei herunterladen. Dies hat den Vorteil, dass man den Download-Pfad vorher nicht mühsam im VMware Downloadcenter heraussuchen muss. Ohne native Windows-VMRC-Version-7 startet der Web-Client die eingebaute HTML5-Console in einem Browser-Tab. Das passiert auch, wenn man direkt auf das miniaturisierte Vorschaufenster der VM klickt.
Wann kommt ein neuer Web Client ?
Während also das "Problem" einer Console im Vollbild-Modus auch ohne CIP-Plugin in der einen oder anderen Weise als gelöst betrachtet werden kann (HTML5-Version Mac, VMRC 7.0.1) und mangelnde Performance sowie Stabilität bei der aktuellen Version 6.0 des Web-Clients nicht mehr beklagt werden müssen, bleibt die ungeliebte Flash-Abhängigkeit. Unter Linux gibt es zwar krude Workarounds, langfristig gibt es aber keine Alternative zu einem kompletten HTML5-Web-Client. VMware hat zwar bisher nie bestätigt, an einem Solchen zu arbeiten, angesichts der massiven Kritik ist aber davon auszugehen, dass spätestens beim nächsten größeren vSphere-Update ein neuer Web-Client kommt.
Die Vorteile des Web Clients
Dafür muss man VMware und dem Web Client zugute halten, das es sich hierbei spätestens seit der vSphere-Version 5.1 aus dem Jahr 2012 um eine komplexe und mächtige Software mit (z. B. gegenüber dem vSphere Client) riesigen Funktionsumfang handelt, die (man könnte durchaus sagen "Dank" Flash) - "von Anfang" über eine im Vergleich zu ähnlichen komplexen Web-Anwendungen aus dieser Zeit hervorragenden Usability handelt, die sich in Look&Feel nicht hinter einer nativen Anwendung verstecken muss.
Übrigens hatte VMware auch schon "vor" vSphere 5.1 einen Web Client, allerdings war dieser mit seinem rudimentären Funktionsumfang damals nur als Ergänzung gefacht. Seit vSphere 5.1 steht er aber ganz klar im Zentrum von VMware Management-Philosophie und wird sowohl funktional, also auch hinsichtlich der Performance, Stabilität und Usability stetig weiterentwickelt, während die Arbeiten am vSphere Client in dieser Hinsicht auf Eis liegen. Wer also den vollen Funktionsumfang von VMware vSphere, insbesondere der Enterprise- und Enterprise-Plus-Versionen nutzen will, wie etwa HA/DRS-Cluster, Fault Tolerance, vMotion, Storage vMotion usw. kommt um den Web-Clienten nicht herum.
Da der Web Client in seiner jetzigen Form erstmals 2012 auf der Bildfläche erschien kann davon ausgegangen werden, dass VMware schon einige Jahre vor 2012 mit den Arbeiten an der Software begonnen hat. Insofern steht seine Leistungsfähigkeit trotz oder wegen dem verwendeten Flash Flex in einem anderen Licht dar, denn damals gab es kaum einer Alternative, wollte man eine Software mit einer solchen Usability schaffen.
Neben den erwähnten konzeptionellen und funktionalen Vorteilen kommen folgende weitere Punkte hinzu:
1. Der Web Client kann das Inventar effektiver durchsuchen und bietet an vielen Stellen z. B. im Reiter "Related Objects" die Möglichkeit, Datenspeicher, Netzwerke, VMs oder andere Objekte die beispielsweise zu einem bestimmten Host gehören, schnell und einfach anzuzeigen.
2. Es ist sehr komfortabel möglich, virtuelle Maschinen auf Basis ihres Status oder ihrer Konfiguration zu filtern. Die folgende Abbildung zeigt, wie man einen Filter setzt.
3. Wer eine bestimmte Liste von Objekten häufiger benötigt, z. B. eine bestimmte Gruppe von VMs, kann seine Suchen mit der Schaltfläche "Save" rechts des Suchfelds speichern.
4. Der Web Client unterstützt zudem Tags. Angenommen ein Administrator nutzt die Funktion des Web Clients, seine VMs mit Hilfe von Ordnern zu strukturieren - eine Funktion, die übrigens auch der native Client unterstützt. Leider kann eine VM dabei immer nur einem Ordner angehören. Möchte nun ein Admin seine Ordner-Hierarchie anhand von Abteilungen, Gast-Betriebssystemen oder was auch immer aufbauen und ein anderer bevorzugt die jeweiligen Rollen als Strukturierungsmerkmal, kann man im Web Client, die Tag-Funktion nutzen, sodass sich eine VM problemlos in mehrere unterschiedlichen Strukturierungsschemata einfügt. Das Zuweisen von Tags kann ganz komfortabel über das Kontextmenü "Tags & Custom Attributes" mit dem Menüeintrag "Assign Tag" erfolgen. Anfangs ist die Tag-Liste leer. Mit dem entsprechenden Symbol links oben legt der Admin ein neues Tag, sowie einer neue Tag-Kategorie an. Im zugehörigen Dialog "New Tag" lassen sich wahlweise ein Tag pro Objekt oder mehrere Objekte an ein Tag zuweisen. Dass eine VM oder ein anderes Objekt getaggt ist, erkennt man dann in der Übersichtsanzeige des in der Bestandsliste markierten Objekts.
5. Darüber hinaus lässt sich die Funktion "Enhanced vMotion", also das Verschieben von VMs von einem Host mit lokalem Storage zu einem Anderen nur mit dem Web-Client bewerkstelligen.
6. Der Web-Client erlaubt zudem das Speichern und spätere Fortsetzen bestimmter Arbeiten, bzw. merkt sich im Gegensatz zum nativen Client bereits vorgenommene Einstellungen. Ein konkretes Beispiel: erstellt man beispielsweise eine VM oder plant eine andere Assistenten-geführte Aufgabe, in der mehrere Fenster "abzuhandeln" sind und man muss zwischenzeitlich anderswo Einstellungen übernehmen oder ändern, bleibt einem im nativen Client nichts anderes übrig, als den Assistenten erst abzuschließen, die gewünschten Änderungen vorzunehmen und den Assistenten dann erneut durchzuhangeln.
7. Ein weiterer Vorteil des Web-Clients besteht darin, dass sich nur mit ihm virtuelle Maschinen von Hardware-Version 9 auf 10 oder 11 aktualisieren lassen.
Den Web-Client in Betrieb nehmen
Der Web-Client unterliegt einer klassischen Client-Server-Architektur und besteht daher aus zwei Komponenten, eine die auf dem Server (vCenter Server ausgeführt wird) und dem Teil, der am Browser im Client läuft. Um das Installieren der Web-Anwendung muss man sich nicht selbst kümmern, denn sie ist ein fester Bestandteil des vCenters, auf dem sie bei Bedarf entweder per CLI-Kommando oder im Web Client selbst als Service gestoppt oder neu gestartet werden kann. Das Starten und Stoppen von Services der vCenter Appliance erledigt man im Web Client unter Home / Administration / System Configuration / Services. Mit einem Rechtsklick auf VMware vSphere Web Client lässt sich der Dienst entsprechende Rechte vorausgesetzt - beenden oder neu starten.
Foto: Thomas Drilling
VAMI
Übrigens gab es bei Version 5.5 der vCenter Appliance (vcva) noch eine webbasierte, VAMI (Virtual Appliance Management Interface) genannte Konfigurationsoberfläche, über die man die komplette Konfiguration der Appliance im Anschluss an das Ausrollen vornehmen sowie unter anderem auch den Web-Client per Mausklick starten und stoppen konnte. Version 6 wird dagegen nahezu vollständig im Verlauf des Deployments konfiguriert und auch der Service für den Web Client automatisch gestartet, sodass VMware in der im April veröffentlichten Version von vCenter Virtual Appliance 6 das VAMI-Interface zunächst wegoptimiert hatte. Details zur Installation der vCenter Applicance Version 6 finden sich übrigens hier (Link auf meinen Artikel). Offenbar auf vielfachen Nutzerwunsch ist VAMI in etwas hübscherer Version allerdings mit dem ersten Update der vCenter Appliance 6 mit der Build-Nummer Kunden 3018523 wieder auf HTTPS-Port 5480 erreichbar, bietet aber (vorerst) nur wenige Konfigurationsmöglichkeiten, da die Appliance ja bereits beim Ausrollen eingerichtet wurde. Zum Anmelden ist im Unterschied zum eigentlich Web Client hier der Linux-Root-Account zu verwenden, der im Verlauf der Installation festgelegt wurde. Im Wesentlichen lässt sich hier die Netzwerkkonfiguration anzeigen oder überprüfen, die Zeiteinstellung anpassen - das Anmelden an einer AD-Domäne erfordert beispielsweise wegen des involvierten Kerberos-Protokolls eine zum Domänencontroller absolut synchrone Systemzeit, weshalb man bei "Uhrzeit einen NTP-Server eintragen sollte - sowie bei "Update" die Appliance bei Bedarf auf den neusten Stand bringen.
Finale
Ist alles soweit eingerichtet, kann man sich unter der URL https://<vcva-name>:9443/vsphere-client am Web Client anmelden und soweit noch nicht geschehen ein Datacenter anlegen, seine Hosts zum Datacenter hinzufügen und ggf. weitere Storages einrichtet. Übrigens ist das Angeben der Portnummer 9443 eine Konzession an die Kompatibilität zu den Vorgängerversionen. Schon seit geraumer Zeit reichte es aus, direkt den SSL-Port 443 anzugeben. Mit Version 6 kann man auf Angabe einer Portnummer auch ganz verzichten und sich unter der URL https://<vcva-name>/vsphere-client am Web Client anmelden. Alternativ kann der Nutzer auch mit https://<vcva-name> die Portalseite der Appliance anlaufen und dann dem Link zum Web Client folgen. (hal)