Auswertung eines VMFS-header-dumps

Ein VMFS-header-dump (die ersten 2 GB eines VMFS-volumes) enthaelt alle Informationen die man benoetigt um zB. folgende Fragen zu beantworten:

1. liegt ein Problem mit einem fehlgeschlagenem Raid-rebuild vor ?
2. ist eine versehentliche geloeschte VM / VMDK noch vorhanden und evtl. wieder herstellbar ?
3. warum laesst sich das Volume nicht mounten ?
4. lohnt sich ein Versuch eine neue Signatur zu schreiben ?
5. liegt eventuell Sabotage vor ?

Aus einem Headerdump lassen sich mit einfachen Mitteln Dateien extrahieren die oft von ESXi selber nicht mehr gelistet werden.
Die Erstellung eines Headerdumps habe ich hier beschrieben:

Create a VMFS-Header-dump using an ESXi-Host in production

Fuer eine Schnell-auswertung liest man den Dump mit dem Tool strings aus und schreibt die Ausgabe in eine Textdatei.

Die Textdatei die dabei herauskommt kann in der Groesse betraechtlich schwanken  – die Bandbreite reicht dabei von ein paar MB bis zu mehreren hundert MB.
Diese Textdatei schaut man sich dann in einem geeigneten Texteditor an und nutzt die Suchfunktion …

 

Schnellanalyse Headerdump – fuer Admins ohne Recovery-knowhow

Disclaimer:
Dieser Test soll bei der Frage helfen die auftaucht, wenn sich ein VMFS-volume nicht mounten laesst.
Soll ich weitere Zeit und evtl Geld in die Reparatur dieses Datastores investieren oder soll ich zu Plan B wechseln und neu aufsetzen ?
An dieser Stelle kann man leicht Stunden und Tage verwenden bis man eine brauchbare und belastbare Aussage hat.
Der Schnelltest beantwortet die Frage ein einer halben Stunde.
Ich kann als Referenz hier nur auf meine eigene Erfahrung verweisen.
Ich nutze dieses Verfahren in dieser Form seit mehreren Jahren und die Resultate bestaetigen die Methode.


Test: sind VMFS Strukturen zu erkennen ?

Hierbei schaut man sich den Anfang der Datei an. Ein lesbares VMFS 6-volume sollte etwa so aussehen:

*FLOGICA
u~q
u~q
5b52f30c-f0a26dd2-5c39-ecebb8951ea0
u~q
u~q
naa.600508b1001c144412240480e2072a46:1
R[6
Datastore SSD
192.168.1.198
dmfr
dmcr
dmcr
dmcr
dmcr
dmcr
dmcr
dmcr
dmcr
dmdf
dmdf
dmdf
dmdf
dmdf
dmdf
dmdf
dmdf
dmdf
.fbb.sf
.fdc.sf
.pbc.sf
.sbc.sf
.vh.sf
.pb2.sf
.sdd.sf
.jbc.sf
dmfr
dmfr

Uns interessieren hier die rot markierten Eintraege.
Fuer die Schnellanalyse nutzen wir jetzt:

Fehlt die UUID, die naa-nummer , der friendly name oder die Liste der versteckten VMFS-metadaten (Eintraege mit *.sf )dann kann mit ausreichender Sicherheit davon ausgegangen werden, dass dieses Volume unter ESXi nicht mehr reanimiert werden kann.

Fehlt nur der Eintrag .jbc.sf dann handelt es sich um ein VMFS 5 Volume.

Sind die *.sf Eintaege doppelt vorhanden liegt sehr wahrscheinlich ein Raid Rebuild-problem vor.
Das bedeutet dass eine Recovery in jedem Fall teuer und langwierig sein wird.

 

Test: Wurde das Volume ueberschrieben ?

Sieht der Anfang der Textdatei aehnlich aus wie:

t&fh
fas
u;f
TCPAu2
r,fh
fSfSfUfh
fah
Invalid partition table
Error loading operating system
Missing operating system
EFI PART
Microsoft reserved partition
Basic data partition
NTFS
NTFSu
u-f
TCPAu$
fSfSfU
fY[ZfYfY
A disk read error occurred
BOOTMGR is compressed
Press Ctrl+Alt+Del to restart
BOOTMGR

so kann man davon ausgehen dass dieses Volume zumindest teilweise unter Windows ueberschrieben wurde.
Andere Dateisysteme hinterlassen andere Spuren – sind aber meist aehnlich einfach und deutlich zu erkennen.

Das bedeutet: nicht mountbar unter ESXi und eine Recovery ist langwierig und wenig erfolg versprechend.

 

Test:  Werden VMs oder wird nur ein leeres VMFS angezeigt ?

Ordner die im Datastorebrowser angezeigt wuerden tauchen in der Textdatei direkt nach der Liste der *.sf Dateien auf.

Das sieht dann zB so aus:


.fbb.sf
.fdc.sf
.pbc.sf
.sbc.sf
.vh.sf
.pb2.sf
.sdd.sf
.jbc.sf
MY-DATABASE-1-server
DC-prod
Install-ISOs
...

Nutzen kann man dies um zB schnell heraus zu finden ob dieses Volume die Install-ISOs hatte.

Findet man den gesuchten Ordnernamen frei stehend hinter den *.sf files dann ist die Prognose gut.
Findet man den Ordnernamen nicht dann sieht es nicht so gut aus.

Test: kann die vmx-datei der VM Waldfee  wieder hergestellt werden ?

Jetzt suchen wir die Textdatei nach dem String .encoding = “UTF-8 ab
und finden dann Stellen wie

.encoding = "UTF-8"
config.version = "8"
virtualHW.version = "11"
nvram = "Waldfee.nvram"
pciBridge0.present = "TRUE"
svga.present = "TRUE"
displayName = "Waldfee"

Bei VMFS 3 und 5 findet man vmx-dateien auch oft noch Wochen spaeter.
Bei VMFS 6 wird besser geloescht und die Hinweise verschwinden viel schneller.

So gefundene vmx-dateien sollten komplett in einem Stueck vorliegen – wenn nicht liegt evtl. ein Raid-rebuild-problem vor.

 

 

Test: kann die VMDK Waldfee-flat.vmdk  wieder hergestellt werden ?

Jetzt suchen wir die Textdatei nach dem String “Waldfee-flat.vmdk” ab.
Finden wir dabei folgende Eintraege:

RW 314572800 VMFS "Waldfee-flat.vmdk"
Waldfee-flat.vmdk

dann bedeutet dass, das ein Recovery-versuch Sinn macht und ein Versuch gestartet werden kann.
Findet man beide Eintraege nicht sind schnelle Ergebnisse einer Recovery nicht zu erwarten.

 

Frage: kann die komplette VM Waldfee so wiederhergestellt werden, dass sie startbar ist ?

Diese Frage laesst sich per Schnelltest nicht ausreichend sicher beantworten.
Der Versuch lohnt sich wenn die VMX datei gefunden wurde und die beiden  Eintraege fuer jede flat.vmdk.
Falls die VM Sesparse snapshots nutzte ist eine komplett startbares Resultat eher unwahrscheinlich.
Ansonsten gilt: alle kleinen config-dateien einer VM lassen sich neu erstellen.
Entscheidend sind die flat und delta/ sesparse VMDKs

 

Frage: Lohnt sich der Einsatz von Recoverytools ?

Es gibt derzeit 2 brauchbare kommerzielle Tools die VMFS-volumes lesen koennen.

Diskinternals VMFS Recovery
UFSexplorer

Zur Wiederherstellung von Thin-provisioned VMDKs und Snapshots benoetigt man zwingend die minimalen VMFS Metadaten.
Ohne
.fbb.sf
.fdc.sf
.pbc.sf
.sbc.sf
.vh.sf
.pb2.sf
.sdd.sf
.jbc.sf

bei VMFS 6 oder ohne

.fbb.sf
.fdc.sf
.pbc.sf
.sbc.sf
.vh.sf
.pb2.sf
.sdd.sf

bei VMFS 5 ist ein Auslesen von Thin-provisioned VMDK und Snapshots so gut wie sinnlos.

Bei Eager-zeroed-thick provisioned VMDKs lohnt ein Versuch immer.

 

Frage:  Sabotage ???

Manchmal findet man in der Textdatei eine cli.log oder andere log Dateien.
Bei Sabotage-verdacht ist daher eine genaue Untersuchung sinnvoll.

 

Frage: Was kann man sonst noch mit einem Headerdump anstellen ?

Im Idealfall ruft jemand an, der gerade seine wichtigste VM verloren hat.
Eine Stunde spaeter kann ich ein dd-script bereitstellen mit dem der Kunde sich die VM wieder extrahieren kann.

In allen “Ich habe aus versehen … geloescht” Anfragen sollte sofort ein Dump erstellt werden um die Chancen fuer eine Wiederherstellung zu verbessern.

Bei Problemen mit locked VMDKs und VMDKs mit I/O errors kann der Dump helfen um eine Loesung zu finden.

 

Frage: Mein VMFS-volume ist nicht mountbar – was kann ich ausser Resignature noch probieren ?

In der Praxis laeuft es immer auf dasselber heraus:
Wenn ein Resignature nicht hilft wird das Volume fuer tot erklaert – eventuell werden noch VMDKs extrahiert aber weitere
Reparatur-versuche kommen praktisch nicht vor.
Es empfiehlt sich solche Volumes einmal komplett mit Nullen zu ueberschreiben, bevor es weiter verwendet wird.