Tip: Editieren von VMFS-metadaten
Verfasst: 25.04.2018, 18:38
Das direkte Editieren von VMFS-metadaten ist eine heikle Angelegenheit.
Das Thema ist meines Wissens komplett undokumentiert und daher ziemlich experimentell.
Also wird man es direkt am ESXi eher nicht probieren.
Extrahiert man die VMFS-metadaten und arbeitet mit dem Dump ist das eine sehr mühsame Geschichte weil man ausser vmfs-tools und dd und hexdump kaum Tools zur Verfügung hat.
Ich habe jetzt eine Möglichkeit entdeckt, die die Sache deutlich erleichtert.
Dazu setzte ich eine Workstation 12 auf, die dann entweder von einer ESXi-Installation oder von einer Linux LiveCD gebootet werden kann.
Diese VM wiederum arbeitet dann mit einer VMDK die das defekte Datastore des Kunden simuliert.
Natürlich arbeite ich dann nicht mit einer kompletten Kopie des defekten Datastores, sondern mit einer leeren, partitionierten wachsenden WS-VMDK.
In diese VMDK setze ich den Metadaten-dump direkt ein - ohne es unter Linux hinein zu kopieren wie ich es früher gemacht hätte.
Damit kann man dann ein defektes Datstore von 10TB vom Kunden zu hause in einer WS VM und einer VMDK mit ein paar GB Platzbedarf simulieren.
Die maximale Grösse kann ich derzeit noch nicht sagen.
Der Trick dabei ist die Verwendung einer handgemachten WS 12 VMDK mit folgender Beschreibungsdatei:
# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=12345678
parentCID=ffffffff
isNativeSnapshot="no"
createType="twoGbMaxExtentSparse"
# Extent description
RW 2048 FLAT firstmb.vmdk 0
RW 3145728 FLAT "vmfs.dump" 0
RW 4261412864 SPARSE "vmfs-s001.vmdk"
RW 4261412864 SPARSE "vmfs-s002.vmdk"
RW 4261412864 SPARSE "vmfs-s003.vmdk"
RW 4261412864 SPARSE "vmfs-s004.vmdk"
RW 4261412864 SPARSE "vmfs-s005.vmdk"
RW 2048 FLAT lastmb.vmdk 0
# The Disk Data Base
#DDB
Die Datei vmfs.dump entsricht dem Output von
dd if=/dev/disks/naa.blablabla:1 bs=1M count=1536 of=/tmp/vmfs.dump
Die Dateien firstmb.vmdk und lastmb.vmdk erstellt man sich einmal mit
dd if=/dev/zero bs=1M count=1 of=firstmb.vmdk
dd if=/dev/zero bs=1M count=1 of=lastmb.vmdk
Durch die Ausführung dieser 3 Dateien als FLAT-segmente kann man sie in einer kleinen VM zuhause editieren und dann 1:1 beim Kunden injizieren - wenn man mit seinen Edits zufrieden ist.
Die Dateien vmfs-s001.vmdk und vmfs-s002.vmdk muss man sich einmal mit WS 12 erstellen.
Danach kann man sich mit Kopien dieser beiden Files (254 MB ) VMFS-datastores in beliebiger Grösse konstruieren.
Dazu kopiert man
vmfs-s001.vmdk und vmfs-s002.vmdk
und duplizert dann vmfs-s002.vmdk nach vmfs-s003.vmdk, vmfs-s004.vmdk und soweiter - bis die gewünschte Grösse erreicht ist.
Die gesamte VMDK kann man dann unter WS mit ESXi LiveCDs oder Linux LiveCDs nach belieben analysieren oder editieren.
Wenn das Ergebnis gut aussieht kann man sich die Dateien firstmb.vmdk, lastmb.vmdk und vmfs.dump mit zum Kunden nehmen und ausprobieren.
Falls jemand etwas ähnliches macht oder Interesse hat das Thema zu vertiefen - ruft doch einfach mal an.
Das Thema ist meines Wissens komplett undokumentiert und daher ziemlich experimentell.
Also wird man es direkt am ESXi eher nicht probieren.
Extrahiert man die VMFS-metadaten und arbeitet mit dem Dump ist das eine sehr mühsame Geschichte weil man ausser vmfs-tools und dd und hexdump kaum Tools zur Verfügung hat.
Ich habe jetzt eine Möglichkeit entdeckt, die die Sache deutlich erleichtert.
Dazu setzte ich eine Workstation 12 auf, die dann entweder von einer ESXi-Installation oder von einer Linux LiveCD gebootet werden kann.
Diese VM wiederum arbeitet dann mit einer VMDK die das defekte Datastore des Kunden simuliert.
Natürlich arbeite ich dann nicht mit einer kompletten Kopie des defekten Datastores, sondern mit einer leeren, partitionierten wachsenden WS-VMDK.
In diese VMDK setze ich den Metadaten-dump direkt ein - ohne es unter Linux hinein zu kopieren wie ich es früher gemacht hätte.
Damit kann man dann ein defektes Datstore von 10TB vom Kunden zu hause in einer WS VM und einer VMDK mit ein paar GB Platzbedarf simulieren.
Die maximale Grösse kann ich derzeit noch nicht sagen.
Der Trick dabei ist die Verwendung einer handgemachten WS 12 VMDK mit folgender Beschreibungsdatei:
# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=12345678
parentCID=ffffffff
isNativeSnapshot="no"
createType="twoGbMaxExtentSparse"
# Extent description
RW 2048 FLAT firstmb.vmdk 0
RW 3145728 FLAT "vmfs.dump" 0
RW 4261412864 SPARSE "vmfs-s001.vmdk"
RW 4261412864 SPARSE "vmfs-s002.vmdk"
RW 4261412864 SPARSE "vmfs-s003.vmdk"
RW 4261412864 SPARSE "vmfs-s004.vmdk"
RW 4261412864 SPARSE "vmfs-s005.vmdk"
RW 2048 FLAT lastmb.vmdk 0
# The Disk Data Base
#DDB
Die Datei vmfs.dump entsricht dem Output von
dd if=/dev/disks/naa.blablabla:1 bs=1M count=1536 of=/tmp/vmfs.dump
Die Dateien firstmb.vmdk und lastmb.vmdk erstellt man sich einmal mit
dd if=/dev/zero bs=1M count=1 of=firstmb.vmdk
dd if=/dev/zero bs=1M count=1 of=lastmb.vmdk
Durch die Ausführung dieser 3 Dateien als FLAT-segmente kann man sie in einer kleinen VM zuhause editieren und dann 1:1 beim Kunden injizieren - wenn man mit seinen Edits zufrieden ist.
Die Dateien vmfs-s001.vmdk und vmfs-s002.vmdk muss man sich einmal mit WS 12 erstellen.
Danach kann man sich mit Kopien dieser beiden Files (254 MB ) VMFS-datastores in beliebiger Grösse konstruieren.
Dazu kopiert man
vmfs-s001.vmdk und vmfs-s002.vmdk
und duplizert dann vmfs-s002.vmdk nach vmfs-s003.vmdk, vmfs-s004.vmdk und soweiter - bis die gewünschte Grösse erreicht ist.
Die gesamte VMDK kann man dann unter WS mit ESXi LiveCDs oder Linux LiveCDs nach belieben analysieren oder editieren.
Wenn das Ergebnis gut aussieht kann man sich die Dateien firstmb.vmdk, lastmb.vmdk und vmfs.dump mit zum Kunden nehmen und ausprobieren.
Falls jemand etwas ähnliches macht oder Interesse hat das Thema zu vertiefen - ruft doch einfach mal an.