esxcli Archives - Seite 2 von 5

31. Oktober 20193. Mai 2020

Belegte vSAN Disks im ESXi Host freigeben (unclaim)

Bei Experimenten mit der neuesten ESXi / vSAN Beta trat ein Problem auf. Ich war gerade dabei, eine vCenter Server Appliance (VCSA) auf einen einzelnen ESXi Host auszurollen, der dann mit anderen Hosts einen neuen vSAN (beta) Cluster bilden sollte. Bei der Basiskonfiguration der VCSA (Phase 2) stürzte der Assistent ab. (Muss ich erwähnen, dass es ein DNS Problem war?) 🙂

Dieser Teil der vCenter / vSAN Installation ist heikel. Geht hier etwas schief, bedeutet das in der Regel “Game Over”. Man darf das ganze nochmal von vorne beginnen. Wenn man dann den Installer erneut startet (und das DNS Problem inzwischen hoffentlich beseitigt hat) wird man wahrscheinlich keine Speichermedien im Host sehen. Ganz offensichtlich sind diese noch im Host eingebaut und verfügbar, jedoch wurden diese beim ersten Installationsversuch von vSAN beansprucht und formatiert. Bei einer Neuinstallation dürfen die Spechergeräte jedoch weder vSAN, noch VMFS Dateisysteme enthalten. Falls doch, werden diese ignoriert und nicht angezeigt.

Wie kann man die Disks wieder freigeben?

Im Prinzip kann man Diskgroups im vCenter entfernen. Leider haben zu diesem Zeitpungt noch kein vCenter. Also ein Henne-Ei Problem. Aber wir haben einen Host, eine Shell und ESXCLI. Wir müssen dazu SSH auf dem Host aktivieren und eine Verbindung aufbauen (z.B. mit Putty).

23. September 201923. September 2019

Mikro-Tipp: esxcli Kommandoliste

Es sind gelegentlich die einfachen Dinge, die einem das Leben erleichtern. Kürzlich war ich auf der Suche nach einer Übersicht der verfügbaren esxcli Kommandos. Dafür gibt es erfreulicherweise auch einen esxcli Befehl. Die komplette Liste aller esxcli Kommandos kann man sich ausgeben lassen mit:

esxcli esxcli command list

24. August 201924. August 2019

HBA Driver und Firmware Version ermitteln

Vor Upgradevorgängen ist es ratsam, einen Blick in die VMware HCL zu werfen und Hostsystem und IO-Devices auf Kompatibilität zu prüfen. Hierbei ist das Zusammenspiel von Treiberversion, Firmware und VMware ESXi Version entscheidend. Auch kleinere Updates können mit dem Verlust der HCL Kompatibilität einhergehen. Ein System, das bei Installation noch HCL-konform war, muss es nach dem dritten Update nicht mehr zwingend sein. Durch Updates aktualisierte Treiber können möglicherweise eine höhere Firmware erfordern.

Nun kann man sich glücklich schätzen, wenn man eine Software im Einsatz hat, die einem die mühevolle Suche abnimmt. Runecast Analyzer leistet hier sehr gute Dienste und zeigt auf einen Blick bestehende Inkompatibilitäten. Darüber hinaus kann man ein Upgrade zu einer beliebigen vSphere-Version simulieren und den HCL-Status ermitteln.

Leider haben viele Kunden keine derartige Software im Einsatz und so muss man auf die Bordmittel der ESXi Shell zurückgreifen. Dafür muss SSH auf den Hosts aktiviert werden. Entweder über den vSphere-Client, oder sehr schnell und elegant über ein PowerCLI Kommando.

18. Juli 201921. Juli 2019

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”.