Unbekannte Disk aus vSAN Cluster entfernen

Eine defekte Capacity-Disk wurde aus einem vSAN 7 Cluster entfernt bevor diese logisch aus der Diskgruppe gelöst werden konnte. Das Ergebnis ist ein zurückbleibendes unbekanntes Disk Device in der Diskgruppe, das sich im vSphere-Client nicht mehr entfernen lässt.

In solchen Fällen ist esxcli mitunter das mächtigere Schwert.

Wir verbinden uns per SSH auf den betroffenen vSAN-Knoten.

Datenerfassung

Zunächst prüfen wir alle im Knoten registrierten Disk Devices.

esxcli vsan storage list

Es wird eine detaillierte Liste aller Cache- und Capacity-Devices dieses Hosts ausgegeben.

Ausgabe der Disk Devices (Auszug)

Unter den 24 aktiven Disks befand sich auch das unbekannte Zombie Device. Das einzug verbleibende Merkmal war die vSAN UUID. Mit deren Hilfe kann das Device aus der Konfiguration gelöst werden.

Physisch entferntes Device Relikt in der vSAN Konfiguration

Extraktion

Die UUID des fehlenden unbekannten Devices lautete “52b17786-183b-e85f-f7f3-4befb19f67b0”. Mit dieser Info können wir es aus der Konfiguration entfernen.

esxcli vsan storage remove --uuid 52b17786-183b-e85f-f7f3-4befb19f67b0

Der Vorgang dauert einige Sekunden. Eine erneute Kontrolle mit dem Befehl esxcli vsan storage list zeigte, dass das Device entfernt war.

ESXi Coredump Files verwalten

Zugegeben, das ist kein neues Thema, aber es kostete mich etwas Zeit in einem Kundenprojekt. Da dieser Blog auch als Swap-Partition meines Gehirns fungiert, habe ich es für die Zukunft niedergeschrieben. Wichtig ist die korrekte Abfolge der Schritte, damit die Änderung auch nach einem Bootvorgang erhalten bleibt.

Wofür wird ein Coredump-File benötigt?

Moderne ESXi Installationen ab Version 7 verwenden ein neues Partitions-Layout des Bootdevices. Darin werden auch Coredumps abgelegt. Jedoch nur wenn das Bootmedium kein USB-Flashmedium und keine SD-Card ist. In solchen Fällen wird der Coredump ausgelagert auf einen VMFS-Datenspeicher mit mindestens 32GB Kapazität.

Genau einen solchen Fall fand ich in einer Kundenumgebung vor. Das System wurde von vSphere 6.7 migriert und hatte daher noch das alte Boot-Layout auf einem (damals noch voll unterstützten) SD-Card RAID1. Wir fanden einen Ordner vmkdump mit Files für jeden Host auf einem der gemeinsamen VMFS-Datenspeicher. Dieser (VMFS5) Datenspeicher sollte aufgelöst und durch einen VMFS6 Datenspeicher ersetzt werden. (Randbemerkung des VCI: Es gibt keinen online Migrationspfad von VMFS5 nach VMFS6). 😉 Also mussten die vmkdump Files von dort weg.

Ablauf

Zunächst verschaffen wir uns eine Übersicht der Coredump-Files.

esxcli system coredump file list

Hier werden alle Coredump-Files aller ESXi-Hosts gelistet. Jede Zeile enthält neben dem Pfad auch die Stati Active und Configured (true oder false). Active bedeutet, dass dies das aktuelle Coredumpfile dieses Hosts ist. Wichtig ist, dass der Wert bei Configured ebenfalls den Status ‘true’ hat. Ansonsten übersteht die Einstellung keinen Reboot. Nur das Coredump-File des aktuellen Hosts hat den Status ‘active’. Alle anderen Files gehören zu anderen Hosts und sind daher active=false.

Im Standard wählt der Host den ersten passenden VMFS-Datenspeicher. Das ist nicht unbedingt der erwünschte.

Aktuelles Coredump-File entfernen

Zunächst löschen wir das aktive Coredump-File des Hosts. Wir müssen die Löschung erzwingen, da es als active=true gesetzt ist.

esxcli system coredump file remove --force

Führen wir das list Kommando von oben nochmals aus, so sollte eine Zeile weniger erscheinen.

Neues Coredump File erzeugen

Der folgende Befehl legt ein neues Coredump-File am Zielort an. Falls noch nicht vorhanden wird ein Ordner vmkdump erzeugt und darin das Dumpfile. Wir übergeben den gewünschten Filenamen ohne Endung, da diese (.dumpfile) automatisch erzeugt wird.

esxcli system coredump file add -d <Name | UUID> -f <filename>

Beispiel: Name des Hosts ist “ESX-01” und der VMFS-Datenspeicher hat den Namen “Service”. Der Datenspeicher darf entweder als Anzeigename oder Datastore_UUID übergeben werden.

esxcli system coredump file add -d Service -f ESX-01

Auf dem benannten Datenspeicher wird nun ein Ordner vmkdump erzeugt und darin ein File namens ESX-01.dumpfile. Wir können dies prüfen über das list Kommando.

esxcli system coredump file list

Es erscheint eine neue Zeile mit dem vollen Pfad zum neuen Dumpfile. Der Status ist jedoch noch active=false und configured=false. Es ist sinnvoll diesen kompletten Pfad in die Zwischenablage zu kopieren, denn wir benötigen ihn im nächsten Schritt.

Dumpfile aktivieren

Wir setzen im folgenden Schritt das neu erzeugte Dumpfile aktiv. Somit bleibt die Einstellung auch nach einen Host-Reboot erhalten. Wir übergeben dabei den vollständigen Pfad zum Dumpfile. Hier eignet sich die Kopie aus der Zwischenablage und vermeidet Tippfehler.

esxcli system coredump file set -p <path_to_dumpfile>

Beispiel:

esxcli system coredump file set -p /vmfs/volumes/<UUID>/vmkdump/ESX-01.dumpfile

Ein abschließender List Befehl bestätigt das Ergebnis.

Links

vSAN Cluster Live-Migration in ein neues vCenter

Was kann man tun, wenn die produktive vCenter Server Appliance beschädigt ist und man einen vSAN-Cluster auf eine neue vCenter Appliance übertragen muss?

Im heutigen Beitrag werde ich zeigen, wie man einen laufenden vSAN-Cluster unter vollen Segeln von einer vCenter-Instanz auf ein neues vCenter übertragen kann.

Bei jedem der mit vSAN arbeitet, wird sich bei diesem Gedanken ein flaues Gefühl in der Magengegend verbreiten. Warum sollte man so etwas tun? Wäre es nicht besser, den Cluster komplett in den Wartungsmodus zu fahren? – Prinzipiell, ja. In der Praxis treffen wir aber immer wieder auf Einschränkungen, die in absehbarer Zeit kein Wartungsfenster erlauben.

Normalerweise sind vCenter Server Appliances robuste und wartungsarme Einheiten. Entweder sie funktionieren, oder sie sind völlig zerstört. In letzterem Fall könnte eine neue Appliance bereitgestellt und vom Backup ein Konfiguration-Restore eingespielt werden. Nichts davon traf auf ein kürzlich durchgeführtes Projekt zu. Die VCSA 6.7 funktionierte noch halbwegs, jedoch waren wichtige vSAN-Funktionalitäten im UI nicht mehr verfügbar. Eine erste Idee, das Problem mit einem Upgrade auf vCenter v7 und somit auf eine neue Appliance zu beseitigen scheiterte. Auch eine Cross-vCenter Migration der VMs (XVM) auf einen neuen vSAN-Cluster war nicht möglich, da erstens dieses Feature erst mit Version 7.0 Update 1c integriert wurde und zweitens auch nur zwei neue Ersatzhosts zur Verfügung standen. Zu wenig für einen neuen vSAN-Cluster. Zu allem Überfluss war auch der Quellcluster an seiner Kapazitätsgrenze.

Es gab nur einen Ausweg: Den Cluster stabilisieren und unter voller Last auf ein neues vCenter übertragen.

Zu diesem Thema gibt es einen alten, aber immer noch wertvollen Beitrag von William Lam. Damit, und mit dem VMware KB 2151610 Artikel konnte ich eine Strategie entwickeln, die ich hier skizzieren möchte.

Das Verfahren funktioniert, da ein vSAN-Cluster nach Einrichtung und Konfiguration autonom vom vCenter arbeiten kann. Das vCenter wird lediglich für Monitoring und Konfigurationsänderungen benötigt.

„vSAN Cluster Live-Migration in ein neues vCenter“ weiterlesen

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

„Belegte vSAN Disks im ESXi Host freigeben (unclaim)“ weiterlesen