Ein Beispiel für gezielte Fehleranalyse.
vMotion funktioniert nicht mehr
Ohne erkennbaren Anlass funktionierte die Verschiebung von VMs zwischen zwei ESX Servern nicht mehr. Der Prozess brach immer nach 14% Fortschritt ab. Beide Server, sowie deren Gastsysteme waren erreichbar und liefen fehlerfrei. Der vMotion Datenverkehr wurde über ein eigenes VLAN und dedizierte vmnics (Multi NIC vMotion) geleitet. Die Tabelle unten gibt eine Zusammenfassung der Kernelport Konfiguration.
| Host | Kernelport | IP | active | stdby |
|---|---|---|---|---|
| ESX1 | vmk1 | 10.0.0.11 | vmnic2 | vmnic3 |
| vmk2 | 10.0.0.12 | vmnic3 | vmnic2 | |
| ESX2 | vmk1 | 10.0.0.21 | vmnic2 | vmnic3 |
| vmk2 | 10.0.0.22 | vmnic3 | vmnic2 |
Fehlersuche
Zunächst wurden alle LAN Adapter und Kabelverbindungen geprüft. Alle oben genannten NICs hatten elektische Verbindung und aktive Links zum Switch. Die Switchports befanden sich im richtigen VLAN.
vmkping
Ein nützliches Hilfsmittel zur Kontrolle der Verbindung ist vmkping. Damit lassen sich PING Anfragen zu unterschiedlichen Kernelports senden. Dazu aktivierte ich die ESXi Shell an der ESXi Konsole (DCUI).
- DCUI > Troubleshooting Options > Enable ESXi Shell
- Wechsel zur Shell mit Alt + F1 (Alt F2 wechselt zurück zur DCUI)
- Login als root
vmkping -I <source vmk> <IP dest. vmk>
Seit vSphere 5.1 kann man den Quellport der ICMP Pakete wählen., indem man den -I Parameter (Capital i) übergibt. Ein PING von vmk1 (ESX1) zu vmk2 (ESX2) sähe damit so aus:
vmkping -I vmk1 10.0.0.22
Wird vmkping ohne den Quellport <source vmk> abgesetzt, so wird der Defaultport verwendet. Im dargestellten Fall war das vmk1 und lieferte keine hilfreiche Ergebnisse.
Ergebnisse
vmkping ohne Angabe des Quellports
- ESX1 nach ESX2 vmk1 – keine Antwort
- ESX1 nach ESX2 vmk2 – keine Antwort
- ESX2 nach ESX1 vmk1 – keine Antwort
- ESX2 nach ESX1 vmk2 – OK
Das Eergebnis führt nicht zur Ursache des Problems, spiegelt aber das Verhalten bei vMotion wieder. Durch Angabe des Quellports für die ICMP Pakete wird das Bild schärfer:
- ESX1 vmk1 nach ESX2 vmk1 – keine Antwort
- ESX1 vmk1 nach ESX2 vmk2 – keine Antwort
- ESX1 vmk2 nach ESX2 vmk1 – OK
- ESX1 vmk2 nach ESX2 vmk2 – OK
Hier zeichnet sich schon ab, dass ein Problem mit ESX1 vmk1, oder dessen aktiven NIC vmnic2 besteht. Machen wir aber die Gegenprobe:
- ESX2 vmk1 nach ESX1 vmk1 – keine Antwort
- ESX2 vmk1 nach ESX1 vmk2 – OK
- ESX2 vmk2 nach ESX1 vmk1 – keine Antwort
- ESX2 vmk2 nach ESX1 vmk2 – OK
Immer wenn vmk1 auf ESX1 involviert ist, kommt es zu Problemen. Zur Unterscheidung, ob der Kernelport vmk1, oder der zugeordnete vmnic2 ein Problem hat, macht man eine Änderung in der Failover Reihenfolge von vmk1 auf ESX1. Ich setze dazu vmnic3 von Standby zum aktiven Adapter und vmnic2 wird auf inaktiv gesetzt (vgl Tabelle oben). Danach wiederholte ich die PING Tests von oben. Alle lieferten positive Antworten und auch vMotion funktionierte wieder. Somit zeigte sich, dass eine Störung des physischen NICs vorliegen musste.
Kaltstart
Der Port des LAN Adapters (vmnic2) war nicht richtig “down”, daher sprang auch nicht der als Standby definierte Adapter vmnic3 ein. Aber eine Störung verhinderte die Weiterleitung von Paketen. Ich hoffte, daß der Adapter nicht defekt sei und versuchte es mit einem Kaltstart von ESX1. Dazu muss der Server herunter gefahren, und komplett von der Stromversorgung getrennt werden (bis alle Lichter aus sind). So manches elektrische Problem kann man auf diese Art lösen.
Nach dem Kaltstart machte ich die Änderungen an der Failover Einstellung von ESX1 vmk1 wieder rückgängig und wiederholte den Pingtest. Alle Kernelports antworteten nun auf PING Anfragen.
Links
- VMware KB – Testing VMkernel network connectivity with the vmkping command
- VMware KB – Diagnosing a vMotion failure at 10% or higher in vCenter Server
- ElasticSky.de – Multi NIC vMotion