Troubleshooting bei vmnic Störungen

Fehlfunktionen sind schlimmer als Ausfälle

Redundanz ist elementar wichtig in virtuellen Umgebungen. Wenn eine Komponente ausfällt, muss eine zweite einspringen und die Funktion übernehmen. Aber was passiert, wenn eine Komponente nicht gänzlich ausfällt, sondern nur nicht mehr richtig funktioniert? In diesem Fall läßt sich die Störung nur schwer erkennen.

Ich wurde kürzlich von einem Freund alarmiert, als er plötzlich den Zugriff auf alle Freigaben seines (virtuellen) Fileservers verlor. Ich verband mich mit einer Service Workstation und begann mit dem Troubleshooting. Dies sind die ersten Diagnose-Ergebnisse:

  • Der Fileserver reagierte nicht auf ping
  • Ping zum Gateway funktionierte
  • DNS Auflösung zu den virtuellen Domaincontrollern funktionierte
  • Eine Browser-Session zu vCenter scheiterte und die vCenter Appliance antwortete nicht auf ping.

Es handelte sich hier um einen kleinen 2-Knoten Cluster auf vSphere 6.5 U2. Vielleicht war ein ESX ausgefallen? Aber dann hätte HA alle betroffenen VMs auf dem verbleibenden Host neu starten müssen. Und das war offensichtlich nicht der Fall. Ich schickte ping Anfragen an beide ESXi Hosts und erhielt von beiden Antwort. Nein, das sah nicht nach einem Host Crash aus.

Als nächstes verband ich mich mittels Hostclient direkt zu den ESXi Hosts. Alle VMs waren aktiv. Ich öffnete eine vSphere-Konsole zur Fileserver VM, konnte mich aber nicht mit Domänen-Login anmelden. Mit einem lokalem Konto funktionierte es. Der Fileserver sah von innen gesund aus munter aus und alle Freigaben waren vorhanden.

Spätestens jetzt wurde klar, dass es sich um ein Netzwerk Problem handeln musste. Jedoch waren alle Uplinks aktiv und verbunden. Wo ist also das Problem?

Ich fand eine VM, welche auf ping reagierte und Verbindung zum Internet hatte und sich auf dem selben Host befand wie Fileserver und vCenter. Ich öffnete eine RDP Sitzung zu dieser VM und konnte von dort alle anderen VMs des Hosts über ping erreichen. Sogar der Webclient von vCenter war erreichbar. Jetzt wurde das Bild klarer. Einer der physischen Uplinks musste ein Problem haben. Nur welcher?

„Troubleshooting bei vmnic Störungen“ weiterlesen

esxtop – die Referenz

ESXTOP ist nicht wirklich neu, aber wenn es um die Analyse von Leistungsengpässen geht, ist es immer noch ein wirkungsvolles Werkzeug. Ich bin es aber leid, jedesmal nach einer Dokumentation zu suchen. Dieser Blogeintrag dient mir als Bookmark zur esxtop-Referenz.

Ausgabe in CSV-Datei

Möchte man die Werte nicht nur live betrachten, sondern zur späteren Analyse mit z.B. Perfmon speichern, kann man die Resultate in eine CSV-Datei (hier: esxtop_esx1.csv) umleiten.

esxtop -b -d 5 -n 48 > esxtop_esx1.csv

Erklärung der Parameter:

-b (Batchmode): Die Werte werden im CSV Format ausgegeben, wobei die erste Zeile die Namen der Parameter enthält und jede folgende Zeile die durch Komma getrennten Werte.

-d (Delay): Verzögerung in Sekunden (hier 5) zwischen den Messungen.

-n (Iterationen): Durchläufe (hier 48). Wir erhalten in unserem Beispiel 12 Messungen pro Minute. D.h. die Messung läuft bei 48 Zyklen 4 Minuten.