vSwitch Wiederherstellung mit dem CLI

Virtuelle Distributed-Switches (vDS) haben zahlreiche Vorteile gegenüber Standard vSwitches. Durch die zentrale Verwaltung und einheitliche Konfiguration über alle Hosts, ist weniger Raum für Konfigurationsfehler im Vergleich zu Standard vSwitches. Nennt mich altmodisch, aber ich habe dennoch gerne das Management Interface des Hosts an einem klassischen Standard vSwitch. Wenn irgendetwas dummes passiert kann man dann immer noch den Host erreichen und Änderungen vornehmen.

Kürzlich ist der Host eines Kunden ausgefallen. Nach der Wiederherstellung und Rückspielung der Konfiguration war die Nummerierung der vmnics aus noch nicht geklärter Ursache vertauscht. Der Host war daher weder über vCenter, noch über Hostclient ansprechbar. Der Kunde hatte nicht genügend vmnics im Host und konfigurierte daher das Management Network über eine Portgruppe auf dem vDS. Das ist erlaubt und in der Regel kein Problem. In diesem speziellen Fall war es jedoch durchaus ein Problem. Ich war im wörtlichen Sinn vom Host ausgesperrt. Normalerweise könnte man über das Direct Console User Interface (DCUI) die Zuordnung der vmnics zum Management Netzwerk neu organisieren. Das funktionierte jedoch nicht, da alle vmnics von Distributed vSwitches beansprucht waren. Sie konnten daher keinem Standard vSwitch und somit auch nicht dem Management Kernelport zugeordnet werden.

Was nun?

Es gibt einen Ausweg aus dieser Lage. Dazu muss man Zugang zum CLI des DCUI haben. Über eine lokal angeschlossene KVM-Konsole, ILO oder iRMC kann man sich auf dem Host anmelden und wählt im Hauptmenü „Troubleshooting Options“.

„vSwitch Wiederherstellung mit dem CLI“ weiterlesen

ESXi Host Recovery mit Hindernissen

Verbindung mit EVC Cluster scheitert nach ESXi Host Restore

Der Austausch von defekten ESXi Bootmedien wurde inzwischen leider zur Routine. Der Gund sind Flashmedien von schlechter Qualität und daher kurzer Lebensdauer. Man muss hier allerdings fairerweise anfügen, daß einige Kunden günstige USB-Sticks als Bootmedium verwenden. Im Homelab ist das praktisch, im Produktivcluster eine schlechte Idee.

Die übliche Prozedur dafür ist recht einfach:

  • Host Konfiguration exportieren
  • Host räumen und herunterfahren
  • Neues Bootmedium vorbereiten mit einem ISO, das den selben oder einen niedrigeren Patchlevel hat, als die ursprüngliche Installation.
  • Frisch installierten Host booten
  • IP Adresse (temporär) vergeben, falls kein DHCP Server erreichbar ist
  • Hostkonfiguration wiederherstellen
  • Mit Cluster verbinden
  • Fehlende Patches nachinstallieren

So weit, so gut. Aber letzte Woche wurde die Routineaufgabe zur Herausforderung.

„ESXi Host Recovery mit Hindernissen“ weiterlesen

SNMP Agent auf ESXi aktivieren

In einem der letzten Beiträge habe ich über die freie Monitoring Lösung Netdisco berichtet. Neben den Informationen der Hardware-Switches wäre es doch praktisch, auch Informationen zu den virtuellen Switches der ESX Server zu erhalten. Hierfür muss der SNMP Agent auf dem ESX Server aktiviert, und eine Community definiert werden. Die Konfiguration erfolgt entweder über vSphereCLI, oder SSH.

„SNMP Agent auf ESXi aktivieren“ weiterlesen

Problem beim Upgrade auf ESXi 6 mit Customized Images

Einige Server-Hersteller bieten für die ESX Installation auf ihrer Hardware sogenannte Customized Images an, die Common Information Model (CIM) Provider und Treiber enthalten. Damit können Hardwaredaten an den host und vCenter weitergegeben werden.

Bis auf ein Problem mit dem LSIprovider vor einigen Jahren, gab es mit den Customized Images praktisch keine Probleme. Das änderte sich mit dem Upgrade auf ESXi Version 6.

Tod durch Upgrade

Erst kürzlich berichtete mir ein Kollege von einem sehr unerfreulichem Upgrade-Versuch einer ESXi 5.5 Installation (FTS Customized) mit dem Customized Image für ESXi 6.0. Es endete in einer blanken Neuinstalltion mit dem Original VMware Image ESXi 6.

Dadurch gewarnt, wagte ich kürzlich ebenfalls ein ähnliches Upgrade eines ESXi 5.5 mit Fujitsu CIM Providern und Treibern. Allerdings nicht mit einem Customized ESXi 6 Image, sondern gleich mit dem sogenanten „Vanilla“ Image von VMware. Das Ergebnis war ein ESXi 6 Host, der nach dem Reboot praktisch nicht administrierbar war. Alleine ein Login auf der DCUI dauerte Minuten und auch sonst reagierte das System nahezu überhaupt nicht mehr. Auch hier half mir nur die komplett frische Installation mit einem aktuellen VMware Image.
„Problem beim Upgrade auf ESXi 6 mit Customized Images“ weiterlesen