vmdk's 'zerschossen'

[Rene_Mhm]

Ich habe mir ein fürchterliches Ei gelegt ...
Da mein ESXi wg. aktueller Maschinenumstellungen (alte noch und neue schon aktiv) aktuell übervoll ist, habe ich, statt Snapshots zu machen, eine für mich wichtige Platte per FileZilla vor einer Installation lokal gesichert. Die Installation ging schief, und ist spiele dann natürlich eine der beiden Sicherungen wieder hoch.
Tja, aber nun wird die Platte (bestehend aus xx.vmdk & xx-flat.vmdk) nicht mehr als solche erkannt. Es sei kein gültiges File.
Ein kurzer Blick in die xx.vmdk und Nachrechnen ergab, dass die -flat zumindest rechnerisch jeweils zu klein sind.

Befürchte mal, dass ich mir diesen Horror durch das Kopieren per FileZilla statt 'ordentlichem' DownLoad aus der Web-GUI heraus eingehandelt habe.

Gibt es noch irgend etwas, wie ich die vmdk's wieder an's Laufen bringen kann ???
Bin da momentan mehr als nur etwa verzeifelt (ist kein Firmen-Produktivsystem, aber für mich privat sehr wichtig).

[Rene_Mhm]

Glaube, das Problem erkannt und gelöst zu haben:
Offenbar wurde nur das FlatFile im heruntergefahrenen Zustand kopiert, nicht aber der Rest incl. der verweisenden vmdk.
Und damit stimmte einfach die in der vmdk hinterlegte Größe nicht mit jeder des FlatFiles überein.
NunJa, ich brauche wohl überaus dringendst 'etwas' Weihnachtsurlaub!

(Hoffe, dass ich mich nicht zu früh freue, da ich den Spaß bisher nur hier local auf meiner VM-WS testen konnte. An den ESXi komme ich erst in rd. 12h.)

[irix]

Ohne mal ein df -h aus dem VM Verzeichnis sowie den Dateien welche du gesichert glaubst zu haben kann dir hier kaum einer Folgen.

Eine VMDK besteht im Normalfall aus 2 Dateien. Der FLAT und einem kleinen Descriptor. Sollte die FLAT vom Typ "thinprovisioning" sein so haengt es vom verwendetem CMD Befehl ab ob die logische oder pyhs. Dateigroesse angezeigt wird. Analog verhaelt sich auch die GUI.

Ob eine Thinprovisining vDisk beim kopieren/Export aufgeblasen wird haengt dann von anderen Faktoren ab.

Kompliziert wird es wenn:
- Die VM mehrere vDisks in unterschiedlichen Datastores hat
- Die VM Snaps hat
- Die Dateienamen nicht gleich dem VM Namen sind


Veeam Community Edition ist kostenfrei fuer bis zu 10 VMs. Bedingt aber einen lizensierten ESX. Denn gibt es fuer 200,- als Teil der VMUG Adv. Mitgliedschaft oder 470 + 60 als Essentials. Letzteres ist natuerlich fuer Zuhause und Hobby eine Menge Holz.

Gruss
Joerg

[irix]

Einen fehlenden Descriptor kann man jederzeit wieder "von Hand" erstellen da es eine fuer den Menschen lesbare Datei ist. Fuer alle welche aber die Gesetzmaessigkeiten nicht kennen, so wie mich, der Tipp einfach eine "dummy" vDisk mit den gleichen Parametern wie SCSI Kontroller und Groesse anlegen und dann kann man dieses Kopieren und den Namen auf die FLAT einfach anpassen. Es gibt aber auch einen VMware KB zu diesem Thema.

Vor 10 Jahren hat unser Foren Mitglied dafuer extra ein Windows Utility "Oh'dear i lost my descriptor.exe" programmiert gehabt.


Gruss
Joerg

[Rene_Mhm]

Eine VMDK besteht im Normalfall aus 2 Dateien. Der FLAT und einem kleinen Descriptor.

Genau. Und da FlatFile und DescriptorFile nicht vom selben Zustand her rührten, stimmte die im DIscriptorFile eingetragene Anzahl der Sektoren nicht mit der tatsächlichen Größe des FlatFiles überein. Nachdem ich den Zusammenhang begriffen hatte, dass unter "Extent description" die Sektorenanzahl steht, war das Thema zum Glück dann wirklich sehr schnell erfolgreich erledigt.

Vielen Dank natürlich trotzdem für Eure Hilfe!

[continuum]

Wenn eine vmdk Beschreibungsdatei verloren gegangen ist - bitte nicht der VMware KB folgen !!!!

Statt dessen nimmt man besser einfach diese Sample-datei:

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=12345678
parentCID=12345678
createType="vmfs"

# Extent description
RW XXXX VMFS "BBBB"

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "CCCC"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"


Danach ersetzt man XXXX durch <Groesse der flat in bytes / 512> Anzeige in putty oder WinSCP ist ok
BBBB ersetzt man durch den vollen Namen der flat.vmdk.
CCCC ersetzt man durch XXXX / 16065 abgerundet.

Den Parameter fuer Thin-provisioning braucht man nicht von Hand zu setzen.
Virt. Hardware Version muss auch nicht gesetzt werden.
Adapapter-type ist mittlerweile auch optional.

Dadurch erspart man sich das Erstellen einer Dummy VMDK - was sehr nuetzlich ist, da man damit einigen Schaden anrichten kann.

Ulli