Troubleshooting bei vSphere 5, Teil 1

Die Kommandozeile ist der Freund des Administrators beim Troubleshooting in vSphere-5–Umgebungen. Sie bietet weitaus mehr Werkzeuge und somit Funktionalität als der „vSphere Client“ (auch als „vClient“ bezeichnet) allein. Zudem erarbeitet sich ein Systembetreuer über die Kommandozeile mehr Details zu einem ESX(i)-Servers. Damit geht ihm die Fehlerbehebung leichter von der Hand. Der ersten Teil dieser Beitragsreihe zum Troubleshooting dreht sich um die Tools, die sich für diese Aufgabenstellung in der VMware-Welt eignen: den vSphere Client, die PowerCLI, die lokale Kommandozeile auf den ESX(i)-Servern (vCLI), dem SDK für Perl und der „virtual Management Appliance“ (vMA).

Generell stehen dem Systembetreuer mehrere Werkzeugarten auf eine vSphere-5-Umgebung zur Verfügung. Ein vClient lässt sich auf Windows PC installieren und kann dann auf alle im Netzwerk erreichbaren ESX(i)-Server zugreifen. Dieses Tool gilt als das Standard-Interface des Administrators für die Bewältigung der meisten täglichen Aufgaben. Damit wird er etwa 80 bis 95 Prozent der nötigen Aktionen abdecken. Aber auch beim Troubleshooting deckt der vClient einige Herausforderungen ab.

Auf jedem ESX(i)-Server gibt es auch die lokale Kommandozeile (virtual Command Line Interface, „vCLI“). Ihr Funktionsumfang ist eingeschränkt und nur für einige Aspekte im Bereich der Fehlerbehebung gedacht. Doch die tägliche Arbeit sollte der Administrator besser über den vClient abwickeln.
Bei der PowerCLI handelt es sich um Powershell Commandlets für Windows. Sie lässt sich auch auf einem vCenter Server installieren – doch der Administrator kann sie auch auf einem normalen Windows-Arbeitsplatz einsetzen.

Als besser erweist sich allerdings die Wahl des vCenter Server, ist er doch typischerweise besser erreichbar als ein normaler Client-PC: Denn der ist üblicherweise nur dann eingeschaltet, wenn der Administrator auf ihm angemeldet ist und darauf arbeitet.

Die PowerCLI bringt Befehle mit und eignet sich auch dazu, kleine Workflows mit Hilfe der Powershell zu programmieren. Dabei wird die komplette Charakteristik der Powershell von Windows übernommen. In den kommenden Versionen von Windows wird sich die Powershell mit noch mehr Funktionalität als eine wichtige Arbeitshilfe für Administratoren etablieren. Das Schöne an diesem Ansatz ist, dass Microsoft auch Erweiterungen zulässt, wie sie eben auch von VMware geschrieben wurden, um die ESX-Familie damit zu kontrollieren.

Was die PowerCLI nicht abdeckt, sind einige klassische „Linux-/Unix-oide“ Programme, die von der Servicekonsole her bekannt sind. Die Servicekonsole gibt es ab vSphere 4.5 nicht mehr. Und ab Vsphere 4.4.1 sollte man sich von dem klassischen ESX-Server trennen und den Umstieg zum ESXi machen. Die Servicekonsole hatte in der Vergangenheit durchaus ihre Berechtigung.

Denn nur über sie war der Zugriff direkt auf die physikalische Hardware möglich. Und wenn man den physischen Host zu überwachen hatte, wie etwa Netzteile, Lüfter und ähnliches, da musste man das über Treiber machen, die man in der Servicekonsole installiert hatte.

Dazu gab es von den jeweiligen Hardware-Herstellern die klassischen Treiber für Linux, und in der Regel haben die dann erkannt, dass sie auf der Servicekonsole von VMware laufen und dann die nötigen Treiber installiert.

Das fällt beim ESXi weg, weil man keine vollständige Servicekonsole mehr hat. Trotzdem bringt ESXi auch „Hardware-Kommandos“ mit: Über die IPMI-Schnittstelle wird ein CIM-Provider mit installiert, der über Hardware-spezifische Treiber der jeweiligen Hardware-Hersteller auf die IPMI-Schnittstelle der Server zugreifen kann und darüber Vitaldaten des Hosts in Erfahrung bringt:

Dazu gehören zum Beispiel die Lüfterdrehzahlen, Netzwerk-Links, Temperatur der Prozessoren und so weiter. Das muss nicht mehr über proprietäre Treiber und einen proprietären Verwaltungs-Server mehr erfolgen. Damit kann man auch das Alarming über den vCenter Server abwickeln, wenn es Probleme gibt.

Sicher wird der ein oder andere „VMware-Recke“ die Servicekonsole vermissen. Bis vSphere 4.4.0 wurde den Anwendern geraten, in der Umgebung mindestens noch einen ESX-Server voll zu installieren, damit man eine komplette Servicekonsole und somit eine Kommandozeile zur Verfügung steht, in der man auch Linux-Befehle absetzen kann  und man somit das Troubleshooting auch komplett angehen kann.

Das gibt es aber ab ESX 4.5 nicht mehr, da steht nur mehr der ESXi-Server zur Verfügung. Doch VMware bietet im weitesten Sinn eine „Maschine“ als Ersatz, der für die Servicekonsole im weitesten Sinne herhält: die „virtual Management Appliance“ (kurz vMA). Es handelt sich dabei um ein 64-bittige Linux-VM, die auch alle VCI-Kommandos enthält und die somit als zentrale Servicekonsole fungiert. Die vMA kann der Administrator kostenfrei von der VMware-Site herunterladen. Sie wird als ein OVF-Template geliefert und lässt sie sich dann auch entsprechend ausrollen.

Powershell Commandlets der PowerCLI

Die PowerCLI steht als kostenloser Download von der VMware-Website zur Verfügung (im Download-Bereich zu vSphere, dann Reiter Drivers & Tools, Automation Tools und SDKs, dort  die PowerCLI for Windows).

Dazu gibt es noch den VMware Orchestrator, der für die Automatisierung hilft. Damit  besteht die Möglichkeit, über Skriptlets ganze Workflows zu erstellen. Diese Abläufe sind nicht allein auf die virtuelle Infrastruktur beschränkt, Denn es lassen sich beliebige Programmier- oder Skriptsprachen einbinden. Daher lassen sich auch Workflows abbilden, die die physische Infrastruktur betreffen.

Kommandosyntax der vCLI

Auf dieser Website steht auch die vCLI zum Herunterladen bereit: Sie ist im SDK (Software Development Kit) für Perl enthalten. Die Kommandos der vCLI sind noch vom früheren ESX-Server bekannt. Damals musste man sie mit ESXCFG und einem Zusatz aufrufen – also nach dem Motto:

ESXCFG-xxxx

etwa mit ESXCFG-VSWITCH, um mit den virtuellen Switches oder ESXCFG-VMK um mit dem VMware-Kernel zu arbeiten. Doch in der neueren vSphere-Umgebung heißen die Befehle nun VICFG – und danach auch wieder die zugehörige Kategorie.

Da diese Befehle nun auf einem zentralen System abgesetzt werden, muss der Administrator dem jeweiligen Kommando mitteilen, auf welchen Host sie die Aktionen ausführen sollen. Das bedeutet für die Syntax, dass ein Parameter (das –server) anzugeben ist, der diese Information übermittelt.

Zudem sind noch ein Benutzername (für ein entsprechendes Administratorkonto: –username) und das zugehörige Kennwort (–password) für dieses Benutzerkonto zu übergeben. Das ist in der Regel ein vCenter Windows-Benutzer (der administrative Berechtigungen auf dem vCenter Server hat), beim ESXi ist das unter Umständen auch ein lokaler Benutzer.

Die vMA basiert auf einer virtuellen Maschine mit dem Gastbetriebssystem Suse Enterprise Linux 11 (64 Bit VM). Darin sind die VMware Tools, das vSphere SDK für Perl, eine Java Runtime Engine (JRE), ein SNMP Agent, die CIM vSphere Profiles sowie die vCLI enthalten.

Eine vMA kann über den vCenter Server Aufgaben auf einen oder auch auf mehreren ESXi-Servern ausführen. Dabei ist auch ein Skripting der Befehlsabfolgen machen. Generell funktionieren bei der vMA die meisten vCLI-Befehle. Zudem lassen sich bestehende Skripts, die der Administrator früher auf der Service Konsole erstellt hat, mit geringen Modifikationen zur Ausführung bringen.

Im nächsten Teil dieser Serie wird das Arbeiten mit der vMA gezeigt.

Rainer Huttenloher

Dieser Beitrag basiert auf dem Vortrag von Sven Gmelin (AddOn Systemhaus), der auf dem Morning Event Ende Januar 2012 zum Thema VMware Troubleshooting gehalten wurde.