Tipps zur Lösung der häufigsten VMware ESX-Probleme

Fehlerbehebung bei einem Purple Screen of Death

Wenn ein PSOD auftritt ist das erste, was Sie tun sollten, die auf dem Bildschirm angezeigten Informationen zu betrachten. Idealerweise fotografieren Sie den Bildschirm auch einfach und verwenden das Foto als Informationsquelle, wenn Sie sich nicht mehr an alle Details des Fehlers erinnern.

Außerdem können Sie das Foto an externe Dienstleister oder andere Administratoren senden, welche bei der Problemlösung behilflich sein können. Die PSOD-Nachricht besteht unter anderem aus der ESX-Version und Build-Nummer, dem Ausnahmetyp und Registry-Dump sowie Back-Trace, Server-Betriebszeit und Informationen zum Memory Core Dump. Die Informationen werden häufig für Sie nicht nützlich sein, aber der VMware-Support oder andere VMware-Experten können die Informationen entschlüsseln und dabei helfen, die Ursache des Absturzes zu finden.

Leider haben Sie an dieser Stelle keinerlei Möglichkeiten mehr, in das System einzugreifen. Sie können die Informationen auf dem Bildschirm fotografieren, das war es dann aber schon. Ansonsten können Sie danach eigentlich nur noch Server aus- und wieder einschalten, damit Sie weiter mit dem System arbeiten können. 

Sobald der Server neu gestartet wird, sollten Sie eine VMkernel-zdump-*-Datei in Ihrem Server/root-Verzeichnis finden. Diese Datei wird noch wertvoll bei der weiteren Bestimmung der Fehlerursache sein. Sie können das vmkdump-Dienstprogramm verwenden, um die VMkernel-Protokolldatei aus der Datei zu extrahieren. 

Dazu verwenden Sie den Befehl vmkdump - l. Suchen Sie nach Hinweisen für die Ursache des PSOD. Der VMware-Support wird diese Datei in der Regel ebenfalls anfordern, da hier wichtige Informationen hinterlegt sind. Eine häufige Ursache des PSOD wäre zum Beispiel ein defekter Server-Speicher. Die Dump-Datei kann dazu beitragen, das Speichermodul das Problem verursacht hat zu identifizieren. Anschließend können Sie das Modul einfach ersetzen. Der Fehler sollte danach nicht mehr auftreten.

Überprüfen Sie Ihre RAM-Module auf Fehler

Wenn Sie vermuten, dass der Arbeitsspeicher des Systems Fehler verursacht, können Sie ein integriertes Dienstprogramm verwenden, um den Arbeitsspeicher im Hintergrund zu überprüfen.  Dabei werden die virtuellen Maschinen des Servers nicht beeinflusst. Das RAM-Check -Dienstprogramm läuft im VMkernel und kann durch Einloggen in die Verwaltungskonsole gestartet werden. Geben Sie dazu den Befehl Service Ramcheck Start ein.

Während des RAM-Checks werden alle Aktionen und auch alle Fehler in das Verzeichnis /var/log/vmware in die Dateien ramcheck.log und RAMCHECK- err.log geschrieben. Ein Nachteil dieser Vorgehensweise ist jedoch, dass es schwer ist, den kompletten Arbeitsspeicher mit diesem Programm zu testen, wenn virtuelle Maschinen aktiv sind. Das Tool kann nur freien Arbeitsspeicher im ESX-System testen, nicht aber den Speicher, den die einzelnen VMs belegen. Ein gründlicheres Verfahren zum Testen des Arbeitsspeichers des Servers ist das Herunterfahren von ESX und das Booten einer Rettungs-CD mit Memtest86.

vm-support-Dienstprogramm verwenden

Wenn Sie den VMware-Support kontaktieren, werden sie in der Regel gebeten, das vm-support-Dienstprogramm zu verwenden. Dieses fasst alle ESX Server-Log- und Konfigurationsdateien in einem einzigen Paket zusammen. Dieses Paket versenden Sie anschließend an den Support, der die Daten auslesen kann und Lösungsvorschläge ausarbeitet. 

Um dieses Dienstprogramm zu verwenden, melden Sie sich einfach an der Service-Konsole mit Root-Zugang an und geben vm-support ohne weitere Optionen ein. Das Dienstprogramm beginnt mit der Arbeit und erstellt eine Datei in der Form „esx---..tgz“. Diese Datei können Sie anschließend per FTP zum VMware-Support senden. Achten Sie darauf, diese Datei nach dem Versenden auf dem Server zu löschen, um Platz zu sparen. Achten Sie zudem darauf, dass Sie diese unter Umständen später wieder benötigen. Sichern Sie diese daher auf einen externen Datenträger oder einer Arbeitsstation.

Alternativ können Sie die gleiche Datei mit dem VMware Infrastructure Client (VI Client) generieren. Klicken Sie hierzu auf Administration und dann auf Export Diagnostic Data. Wählen Sie Ihren Host oder Ihr Virtualcenter aus und ein Verzeichnis auf Ihrem lokalen PC, indem der Client die Daten speichern kann. Danach wird die gleiche Datei erstellt, die Sie ebenfalls zum VMware-Support senden können.

Mit Protokolldateien auf Fehlersuche gehen

Log-Dateien sind in der Regel bei jeder Art von Problem Ihre besten Werkzeuge zur Fehlersuche. Das gilt insbesondere für ESX. Welche Protokolldateien Sie überprüfen sollten hängt natürlich davon ab, welches Problem bei Ihnen auftritt. 

Unten sehen Sie eine Liste der ESX-Protokolldateien, die häufig wertvoll bei der Problemlösung bei ESX-Problemen sein können. Der VMkernel und die gehosteten Protokolldateien sind dabei die Protokolle, die Sie zuerst überprüfen sollten:

• VMkernel - /var/log/vmkernel – Zeichnet Aktivitäten bezüglich der virtuellen Maschinen und des ESX-Servers auf. Die Protokolldatei erhält eine numerische Erweiterung, deren Bezeichnung ständig rotiert. Das aktuelle Protokoll hat keine Erweiterung, das vorletzte erhält eine .1-Erweiterung.
• VMkernel Warnungen - /var/log/vmkwarning – Zeichnet Aktivitäten der virtuellen Maschinen auf. Hierbei handelt es sich um eine Teilmenge des VMkernel-Protokolls. Es verwendet das gleiche Rotationsschema.
• VMkernel Zusammenfassung - /var/log/vmksummary – Dieses Protokoll enthält vor allem Statistiken zur Betriebszeit und Verfügbarkeit für ESX-Server. Sie erhalten eine lesbare Zusammenfassung in der Datei / var / log / vmksummary.txt.
• ESX Server-Host Agent-Protokoll - /var/log/vmware/hostd.log – Enthält Informationen über den Agenten, der die ESX-Server-Hosts und virtuellen Maschinen verwaltet und konfiguriert. Suchen Sie nach dem Datum/Zeitstempel der Datei, um die aktuelle Log-Datei zu finden. Alternativ öffnen Sie die Datei hostd.log, die mit der aktuellen Protokolldatei verknüpft ist.
• ESX Firewall-Protokoll - /var/log/vmware/esxcfg- firewall.log – Protokolliert alle Firewall-Ereignisse.
• ESX-Update-Log - /var/log/vmware/esxupdate.log – Protokolliert alle Updates über das esxupdate-Tool.
• Service Console - /var/log/messages – Enthält alle allgemeinen Protokollmeldungen der virtuellen Maschinen oder ESX-Server.
• Web Access - /var/log/vmware/webAccess – Speichert Informationen zu Web-basierten Zugriffen auf ESX-Server.
• Authentifizierungsprotokoll- /var/log/secure – Enthält Aufzeichnungen von Verbindungen, die eine Authentifizierung erfordern, wie z. B. VMware-Daemons und Maßnahmen, die der xinetd-Daemon startet.
• Vpxa log - /var/log/vmware/vpx – Enthält Informationen über den Agenten, der mit Virtualcenter kommuniziert. Suchen Sie die Datei nach Datum/Zeitstempel, um die  aktuelle Log-Datei zu finden. Alternativ öffnen Sie die Datei hostd.log. Diese ist mit dem aktuellen Protokoll verknüpft.

Im Rahmen der Fehlersuche müssen Sie  häufig die Version von ESX und der verschiedenen Komponenten wissen. Auch die Patches, die installiert wurden, müssen Sie häufig in Erfahrung bringen. Unten finden Sie einige Befehle, die Sie auf der Service-Konsole ausführen sollten, um diese wichtigen Informationen herausfinden:

Geben Sie vmware –v ein, um die ESX Server-Version anzuzeigen.

Geben esxupdate –l ein, um die installierten Patches anzuzeigen.

Geben Sie vpxa –v ein, um die aktuelle VMware Management-Version anzuzeigen.

Geben Sie rpm –qa | grep VMware-esx-tools ein, um die installierte Version der ESX Server-VMware Tools anzuzeigen.

Wenn alles andere fehlschlägt, starten Sie den VMware-Host-Agent-Dienst neu

Viele ESX-Probleme werden meistens schon einfach durch einen Neustart des VMware-Host-Agent-Dienstes gestartet (vmware-hostd). Dieser Dienst ist für die Verwaltung der meisten Operationen auf dem ESX-Host verantwortlich ist. Startet er neu, beheben sich viele Probleme schon von alleine. Dazu melden Sie sich in der Service-Konsole an und geben den Befehl service mgmt-vmware restart ein.

Achten Sie aber darauf, dass in manchen Umgebungen auch virtuelle Server neu gestartet werden müssen, wenn Sie den Agenten neu starten. In den meisten aktuellen Umgebungen spielt dieses Problem keine Rolle. Aber Sie sehen auch bei diesem Vorgang, dass Sie genau darauf achten sollten, was Sie tun. Nicht immer lösen Sie damit ein Problem, sondern schaffen häufig neue, wenn Sie unbedacht vorgehen.

In einigen Fällen hilft auch der Neustart des vmware-vpxa-Dienstes, wenn Sie den Host-Agent neu gestartet haben. Dabei werden Probleme, die zwischen ESX und VI-Client sowie Virtualcenter bestehen, behoben. Dieser Dienst ist der Management- Agent, der die gesamte Kommunikation zwischen ESX und seinen Client verwaltet. 

Treten hier Fehler auf, lassen sich diese durch einen Neustart oft beheben.  Um den Dienst neu zu starten, melden Sie sich am ESX-Host an und geben über die Dienste-Konsole service vmware-vpxa restart ein. Normalerweise treten bei einem Neustart dieser Dienste keine Fehler auf und auch die virtuellen Server werden davon nicht beeinträchtigt.

Was tun bei einer abgestürzten Service-Konsole?

Ein weiteres Problem, das auftreten kann, ist der Absturz der Service-Konsole. Diese kann sich teilweise aufhängen. In diesem Fall ist es nicht mehr möglich, sich an diesem Server anzumelden. Dies kann durch Hardware-Abstürze oder einen abgestürzten Systemdienst verursacht werden. Ihre VMs laufen in diesem Fall normal weiter. Wenn nur die Konsole abgestürzt ist, gibt es ansonsten keine Probleme. Ein Neustart von ESX ist bei diesen Fehlern in der Regel der einzige Weg, diesen Zustand zu beheben.

Bevor Sie das tun, versuchen Sie aber zuerst, die Gast-VMs herunterzufahren oder mit VMotion auf einen anderen ESX-Host zu migrieren. Dazu verwenden Sie den VI-Client über eine Remote-Verbindung mit SSH oder mit einer der alternativen Notfall-Konsole, über die Sie mit den Tastenkombinationen „Alt + F2“ bis „Alt + F6“ zugreifen können sollten. Sie können auch mit „Alt + F12“ die VMkernel-Meldungen auf der Konsole anzeigen und so mehr Informationen auslesen.

Wenn Sie in der Lage sind, Ihre VMs herunterzufahren oder zu verschieben, können Sie anschließend versuchen, den Server neu starten. Dazu geben Sie den Befehl reboot über den VI-Client oder über alternative Konsolen ein. Wenn das nicht möglich ist, besteht Ihre einzige Option darin, den Server auszuschalten und danach wieder hochzufahren.

Verlorene Netzwerkkonfigurationen

Ein Problem, dass ab und zu auftritt, ist,  dass Sie einen Teil oder sogar alle Ihre Netzwerkkonfigurationen verlieren. Wenn das geschieht, müssen Sie Ihr Netzwerk mit Hilfe der lokalen ESX-Service-Konsole neu erstellen. Ohne Netzwerk können Sie auch auf keine Verwaltungskonsolen über das Netzwerk zugreifen. 

Wenn Sie nicht mehr in der Lage sind eine Verbindung mit dem VI-Client aufzubauen, können Sie mit einigen VMware Knowledgebase-Artikeln unter Umständen das Problem beheben und das Netzwerk neu erstellen. Der  erste Artikel erklärt detailliert, wie Sie Ihr Netzwerk aufbauen, indem Sie mit esxcfg-Befehlen in der Service-Konsole Ihre Netzwerkeinstellungen neu konfigurieren. Ein weiterer Artikel erklärt, wie Sie die Konfiguration überprüfen können.

Folgen Sie SearchDataCenter.de auch auf Facebook, Twitter und Google+!