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

Problem mit Emulex OneConnect OCe14000 NIC LoM

Troubleshooting mit Treiber, Firmware und ESXi Versionen

Hardware Ausfälle sind in vSphere Clustern in der Regel keine große Sache. Nahezu jede Komponente ist redundant ausgelegt und bei Ausfall springt ein Ersatz ein. Schwieriger wird es, wenn eine Komponente nicht komplett ausfällt, sondern Fehlfunktionen zeigt. Ein so genannter Zombie ist viel kritischer, als ein Ausfall. Die Ersatzkomponente wird unter Umständen nicht einspringen, so lange noch irgendwelche Lebenszeichen von der gestörten Komponente kommen.

Ein solches Szenario erlebte ich bei dem geplanten Neustart eines Top-of-Rack (ToR) Switches. Der angeschlossene 10 Gbit Port eines ESXi Servers wurde nachhaltig gestört, aber er ist nicht ausgefallen.

Die aktiven Link-LEDs trotz entferntem Kabel sind ein untrügliches Kennzeichen, dass hier etwas nicht in Ordnung ist.

„Problem mit Emulex OneConnect OCe14000 NIC LoM“ weiterlesen

Upgrade ESXi 6.5 mit Fujitsu Custom Image

Konflikt mit VIB

Host Upgrade mit angepassten ESXi Images (sog. Custom Images) bieten ein erweitetes Angebot an Treibern und Hardware-spezifischen Agenten. Somit werden etwa Treiber bereitgestellt, die im VMware Standard (“Vanilla”) Image nicht vorhanden sind, oder ein erweitetes Monitoring der Hardware mit Agenten ist möglich. Führt man Upgrades von Customized Installationen durch, kommt es immer wieder zu Konflikten mit existierenden Paketen. Ein bekanntes Beispiel aus der Vergangenheit war der LSI-Provider in Fujitsu-Images beim Upgrade auf Version 5.1 oder der Tod durch Upgrade auf Version ESXi 6.0 mit Fujitsu Custom Images. Die Hall of Shame ließe sich beliebig erweitern. Auch andere OEM Hersteller sind hier nicht beser. „Upgrade ESXi 6.5 mit Fujitsu Custom Image“ weiterlesen