Warum ein USB-Stick als Coredump-Laufwerk?
In einer VMware vSphere-Farm mit multiplen Servern gibt es ein Host, der in unregelmäßigen Abständen immer mal wieder einen Bluescreen bzw. Purplescreen erzeugt. Die Hardware an sich scheint laut den verfügbaren Diagnose-Möglichkeiten in Ordnung zu sein, ein Update von Firmware und Treibern ist schon (leider erfolglos) durchgeführt worden. Die erste Vermutung, dass dieses Verhalten nur unter Last auftritt, hat sich leider nicht bestätigt, da der Server auch im Wartungsmodus ohne aktive VMs ausgestiegen ist. Aus diesem Grund möchte der VMware-Support ein erweitertes Diagnose-Log haben, um hier vielleicht sehen zu können, wo das Problem liegt. Da die Server alle von zwei internen SD-Karten booten, werden die Informationen (scheinbar) in einer RAM-Disk abgelegt und sind somit bei einem Purplescreen nicht auswertbar.
Aktivierung der USB-Nutzung für den Host
Damit der Host auf USB-Geräte zugreifen kann, muss der USB Arbitrator-Dienst beendet werden. Läuft dieser Dienst, können USB-Geräte in VMs durchgereicht werden. Dies bedeutet auch, dass mögliche USB-Geräte auf diesem Host nach dem Beenden des Dienstes nicht mehr zur Verfügung stehen. Da der Host allerdings eh im Wartungsmodus sein sollte, sollte dies kein Problem darstellen. Der Dienst kann auf der Konsole mit folgendem Befehl beendet werden:
/etc/init.d/usbarbitrator stopNun kann der USB-Stick in den Server gesteckt werden. Das erneute Einlesen von möglichem Storage kann ebenfalls per Konsole gemacht werden:
esxcli storage core adapter rescan --allDas korrekte Laufwerk herausfinden
Es gibt unterschiedliche Möglichkeiten, die verfügbaren Storage-Geräte an einem VMware-Host herauszufinden. Ein
ls -la /vmfs/devices/disks/zeigt einige Datenträger auf.
Eine deutliche bessere und detailliertere Ansicht zeigt allerdings der Befehl
esxcli storage core device list
Hier wird sehr genau und gut angezeigt, dass es sich bei dem Gerät um einen USB-Stick handelt, dass dieser nicht zum Booten genutzt wird und wir sehen den Namen, unter dem man das Gerät ansprechen kann.
Formatierung des USB-Sticks
Der von mir eingesetzte USB-Stick kam direkt aus der Verpackung und war vom Hersteller vor-formatiert. Dies lässt sich sehr gut erkennen, wenn man den Befehl
partedUtil getptbl /dev/disks/naa.<ID>eingibt.
Diese Partition kann nicht für die Ablage von einem Diagnose-Dumpfile genutzt werden, heißt wir müssen den USB-Stick anpassen und formatieren. Im ersten Schritt wandeln wir das Dateisystem um in einen GPT-Datenträger:
partedUtil mklabel /dev/disks/naa.ID gptDieser Befehl entfernt die eine Partition 1 (siehe Screenshot, ganz vorne steht eine 1). Nun müssen wir eine neue Partition anlegen, hierfür benötigen wir einige Informationen.
Die Größe der Partition
Da man die Größe nicht in MB oder GB angeben kann, sondern in Sektoren, muss dieser Wert errechnet werden. Weitere Informationen hierzu findet man in der VMware-Knowledgebase: Using the partedUtil command line utility on ESXi and ESX (1036609)
Die Ausgabe von
partedUtil getptbl /dev/disks/naa.IDzeigt mir die folgenden Werte an:
Die Rechnung ist in meinem Fall die folgende:
(1919 * 255 * 63) - 1 = 30828734Die Art der Partition
Bei der Erstellung einer Partition muss mit angegeben werden, um was für eine Art von Partition es sich handelt. Man kann sich die verfügbaren Möglichkeiten anzeigen lassen:
partedUtil showGuids
In unserem Fall benötigen wir die GUID
9D27538040AD11DBBF97000C2911D1B8, um ein vmkDiagnostic-Laufwerk zu bekommen.
Die Erstellung der Partition
Haben wir nun alle Informationen zusammen, können wir die eigentliche Partition erstellen. Der Befehl dazu lautet:
partedUtil setptbl /dev/disks/naa.ID gpt "1 2048 30828734 9D27538040AD11DBBF97000C2911D1B8 0"Eine kurze Erklärung der Werte:
partedUtil = Tool zur Erstellung der Partition
setptbl = Erstellung einer neuen Partition
/dev/disks/naa.<ID> = Datenträger, in meinem Fall der USB-Stick
gpt = das Format
1 = Nummer der Partition
2048 = Startsektor
30828734 = Endsektor
9D27538040AD11DBBF97000C2911D1B8 = GUID (siehe vorheriger Absatz)
0 = Attribute der Partition (128 z.B. wäre bootbar, normalerweise 0)
Konfiguration der Coredump-Laufwerke
Um sich die aktuellen Einstellungen anzeigen zu lassen, kann der folgende Befehl genutzt werden:
esxcli system coredump partition list
Wir können erkennen, dass das neu erzeugte Laufwerk nun auftaucht, allerdings ist es noch nicht Aktiv und noch nicht als Speicherort für den Coredump eingestellt. Dies können wir mit den zwei folgenden Befehlen ändern:
esxcli system coredump partition set --partition="naa.ID:1"
esxcli system coredump partition set --enable trueGanz wichtig: Vergessen Sie nicht die Nummer der Partition am Ende des ersten Befehls!
Eine erneute Ausgabe der Laufwerke zeigt nun, dass der USB-Stick Aktiv und Konfiguriert ist.
Nun müssen wir nur noch warten, bis der Host ein weiteres Mal aussteigt und haben hoffentlich einen Dump, der dem Support bereitgestellt werden kann.
Weiterführende Links und Informationen
Ich habe in diesem Artikel die folgenden Seiten genutzt und mir von dort die benötigten Informationen zusammengesammelt:
VMware.com: Performing a rescan of the storage on an ESX/ESXi host (1003988)
VMware.com: Identifying disks when working with VMware ESXi/ESX (1014953)
VMware.com: Configuring a diagnostic coredump partition on an ESXi 5.x/6.x host (2004299)
VMware.com: Using the partedUtil command line utility on ESXi and ESX (1036609)
