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

ESX physische Uplinks gegen Pfadausfall sichern (Teil 2)

Was ist beacon probing?

In meinem kürzlich veröffentlichten Blog-Artikel „ESX physische Uplinks gegen Pfadausfall sichern„, habe ich „Link State Tracking “ diskutiert. Eine Methode mit der man den LAN Datenverkehr gegen physische Ausfälle härten kann. Heute möchte ich eine andere Methode der Ausfallsicherung beschreiben, mit der man Uplinks identifizieren kann, die entweder fehlerhaft oder isoliert sind.

Gründe für solche Fehler können zum Beispiel Treiber / Firmware Unverträglichkeiten sein, oder schlicht ein defektes Kabel auf dem Weg zum Coreswitch.

Beacon probing

Beacon probing ist ein Mechanismus, bei welchem der ESX Host im Sekundenabstand Pakete über alle Uplink Ports sendet und kontrolliert, auf welchen anderen Uplink Ports diese empfangen werden. Beacon bedeutet „Leuchtfeuer“ und ist eine treffende Bezeichnung. Jeder Uplink sendet Leuchtfeuer aus und empfängt die Signale der anderen Uplinks.

 

„ESX physische Uplinks gegen Pfadausfall sichern (Teil 2)“ weiterlesen

ESXi – Zuordnung vmnic zu physischem Adapter testen

who is who?

Dieses Problem kennt jeder, der ESXi Server auf neuer Hardware ausrollt: Welcher physische LAN-Adapter entspricht welchem vmnic?
Eine pragmatische, aber mühsame Prozedur besteht darin, zunächst nur einen LAN-Adapter zu verbinden und dann in der DCUI den Linkstatus aller vmnics zu kontrollieren. Das Verfahren wird so lange wiederholt, bis alle Adapter mit dem Switch verbunden sind. Dumm nur, dass sich die LAN-Adapter auf der Server Rückseite und die Konsole bestenfalls auf der Server Vorderseite, oder gar in einem anderen Raum befinden. Das heißt Teamwork und Telefon ist gefragt…. Wer schon einmal versucht hat, hinter einem Server zu telefonieren, wird bestätigen dass dies kein gutes Verfahren ist.
Bei laufenden Systemen kann es aber auch sein, dass ein Entfernen der Patchkabel nicht möglich ist. Was also tun?

Ethtool

Hier kommt ein praktisches Bordmittel des ESXi zum Einsatz. Mit dem ethtool kann man physische NICs zum blinken bringen.

ethtool -p <device> <t in sec>

Um beispielsweise vmnic1 für 30 Sekunden blinken zu lassen, gibt man folgenden Befehl ein:

ethtool -p vmnic1 30

Eine Liste der im System vorhandenen vmnics und der korrespondierenden Hardware erhält man mit den Befehl

esxcfg-nics -l

Dies ist nur eine von vielen Möglichkeiten, die uns das ethtool an die Hand gibt. So kann man beispielsweise auch die Firmware eines physischen NICs abfragen.

ESX – HBA und NIC Firmware Status ermitteln

Zur Gewährleistung von Kompatibilität und bei Supportanfragen ist es gelegentlich notwendig, den aktuellen Firmware Status von Netzwerkadapter oder HBA zu ermitteln. Natürlich kann man theoretisch den Server neu booten und dabei in die BIOS Einstellungen des Adapters gehen, aber dies ist gerade bei ESX Servern mit viel Aufwand verbunden. VM müssen auf andere Hosts im Cluster migriert werden, ein Konsolenzugang oder eine Remotekonsole wird benötigt. Dies alles kostet viel Zeit.

Viel schneller geht es mit ein paar Kommandos auf der ESXi Shell, ohne den Host zu beeinträchtigen. Dazu benötigt man nur einen Zugang per SSH. „ESX – HBA und NIC Firmware Status ermitteln“ weiterlesen