Ich arbeite in der Zwischenzeit viel mit virtuellen Maschinen, damit ich einzelne Kundenprojekte, Steuer/Banking und die ganzen anderen Dinge die man so hat, sauber voneinander getrennt sind. Das hält auch die Probleme und Installationsorgien im Griff, wenn ein neues Update Probleme verursacht.
Den privaten Steuer-Krempel braucht man ja nur -wenn’s gut läuft- nur einmal im Jahr. Warum soll man sich alle paar Tage mit nervigen Update Meldungen herumschlagen? Ab in eine virtuelle Maschine damit und einmal im Jahr damit rumschlagen. Vor jedem Update einen Snapshot machen, damit man nach einem Update noch ein sauberes Backup hat. Gemacht, getan am Wochenende alle Steuerdaten eingegeben und fertig gestellt. Nur noch drucken und fertig. Am nächsten Morgen der Schock beim Start der VirtualBox:
Could not open the medium 'C:VirtualBoxWin7-32-bit-lokalSnapshots/{a8d8e472-bde6-40b9-851a-352a3959df17}.vmdk'.
VMDK: descriptor does not start as expected in 'C:VirtualBoxWin7-32-bit-lokalSnapshots/{a8d8e472-bde6-40b9-851a-352a3959df17}.vmdk' (VERR_VD_VMDK_INVALID_HEADER).Das hatte ich noch nie! Und ich habe bis jetzt – nach der Lösung des Problems – keine Ahnung wie das Problem zustande kam, oder was passiert ist.
Mein wöchenrliches Backup läuft am Freitag Mittag und gemacht habe ich alle Änderungen natürlich – wie das Leben halt so ist – am Freitag Abend und Samstag.
Die einzige Möglichkeit ist also die kaputten VMDK HEADER von VirtualBox bzw. VMWare reparieren. Kann ja nicht so schwer sein.
Für die virtuelle Maschine Win7-32-bit-lokal konnte keine neue Sitzung eröffnet werden.
Could not open the medium ‘C:VirtualBoxWin7-32-bit-lokalSnapshots/{a8d8e472-bde6-40b9-851a-352a3959df17}.vmdk’.
VMDK: descriptor does not start as expected in 'C:VirtualBoxWin7-32-bit-lokalSnapshots/{a8d8e472-bde6-40b9-851a-352a3959df17}.vmdk' (VERR_VD_VMDK_INVALID_HEADER).VD: error VERR_VD_VMDK_INVALID_HEADER opening image file 'C:VirtualBoxWin7-32-bit-lokalSnapshots/{a8d8e472-bde6-40b9-851a-352a3959df17}.vmdk'
(VERR_VD_VMDK_INVALID_HEADER).
Fehlercode:E_FAIL (0x80004005)
Komponente:MediumWrap
Interface:IMedium {4afe423b-43e0-e9d0-82e8-ceb307940dda}Wenn man nach dem Fehler “VERR_VD_VMDK_INVALID_HEADER” oder “VMDK Datei reparatur” sucht landet man kurioserweise immer auf den gleichen Seiten mit Erstellungsdaten ab 2008. Das Problem scheint also schon länger zu bestehen. Wobei fast keiner eine Lösung für das Problem hat.
Auch die knowledge base von VirtualBox und VMWare lieferten keine brauchbaren Ergebnisse.
Die einzigen Links, die das Problem behandeln sind:
- https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1015634
- https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1002511
Die haben mir aber beide nicht weitergeholfen.
Die meisten die laut Foren das Problem mit “” gelöst haben, verwendeten das Tool “vmware-vdiskmanager.exe” mit der Kombination
vmware-vdiskmanager.exe -R kaputte_datei.vmdk
Das Tool wird aber leider von VMWare ni
cht einzeln angeboten sondern nur im Zusammenhang mit dem ESXi-Server, der VMWare Workstation Pro, VMWare Fusion, VMWare Converter und so weiter. Wenn man -wie ich- keine Lust auf diese Monster Installationen hat die Möglichkeit den “Virtual Disk Development Kit” herunterzuladen.
Google Suche nach
Virtual Disk Development Kit 6.0 site:vmware.com
Nach einer “kurzen” Suche und einer nervigen Registrierung bei VMWare (Hey, VMWare hört endlich auf Eure Kunden mit solchen Prozessen zu nerven) kann man das Development Kit endlich herunterladen.
Warum VMWare diese Tools so versteckt und es den Usern so schwer macht an die Tools zu kommen ist mir ein Rätsel.
Wenn der Download dann endlich auf der eigenen Platte ist kann man das oben genannte Programm probieren.
vmware-vdiskmanager.exe -R kaputte_datei.vmdk
Nach einer “kurzen” Suche und einer nervigen Registrierung bei VMWare (Hey, VMWare hört endlich auf Eure Kunden mit solchen Prozessen zu nerven) kann man das Development Kit endlich herunterladen.
Warum VMWare diese Tools so versteckt und es den Usern so schwer macht an die Tools zu kommen ist mir ein Rätsel.
Wenn der Download dann endlich auf der eigenen Platte ist kann man das oben genannte Programm probieren.
vmware-vdiskmanager.exe -R kaputte_datei.vmdk
Bei mir kam
vmware-vdiskmanager.exe -R kaputte_datei.vmdk
zu folgendem Ergebnis:
Yeah – make my day – tolle Rettungstools – Wieder mal ein paar Stunden umsonst.
Ich habe dann noch stundenlang andere Tools und Tipps ausprobiert. Leider ohne jeglichen Erfolg 🙁
Die Löung
VMDK Header reparieren wie ein Profi
Achtung ab jetzt sollte man nochmal ein Backup alle(!) Dateien machen!
Also back to basics – Was sagt die Fehler-Meldung eigentlich aus?
VMDK: descriptor does not start as expected VERR_VD_VMDK_INVALID_HEADER).VD: error VERR_VD_VMDK_INVALID_HEADER
Im Prinzip doch, dass der Date-Header kaputt ist und VirtualBox die VMDK Datei nicht mehr erkennt.
Schauen wir uns das dich mal an. Dafür braucht man zunächst mal einen HexEditor der mit Dateien größer 30GB umgehen kann, ohne zu versuchen die Datei in den RAM zu laden. Mein Tipp ist: http://www.wxhexeditor.org/ aus dem stammen auch die folgenden Screenshots.
Achtung ab jetzt sollte man nochmal ein Backup alle(!) Dateien machen!
Also back to basics – Was sagt die Fehler-Meldung eigentlich aus?
VMDK: descriptor does not start as expected VERR_VD_VMDK_INVALID_HEADER).VD: error VERR_VD_VMDK_INVALID_HEADER
Im Prinzip doch, dass der Date-Header kaputt ist und VirtualBox die VMDK Datei nicht mehr erkennt.
Schauen wir uns das dich mal an. Dafür braucht man zunächst mal einen HexEditor der mit Dateien größer 30GB umgehen kann, ohne zu versuchen die Datei in den RAM zu laden. Mein Tipp ist: http://www.wxhexeditor.org/ aus dem stammen auch die folgenden Screenshots.
Dem geneigten Leser fällt sofort der Unterschied auf. Aus irgendeinem mir nicht ansatzweise nachvollziehbaren Grund ist der Beginn der Datei total kaputt. Enthält Null-Bytes, Sonderzeichen und mitten im String Schmutzzeichen.
Total merkwürdig sind auch die Zeichen vor der Magic Number “52 B3” … um die einzufügen müsste eigentlich die ganze 30GB Datei verschoben werden?!?
Ich habe nun folgenden Block (blau) aus dem Backup, der ja die richtigen Geometriedaten enthält in die defekte Datei kopiert und die Datei gespeichert. Wichtig ist, der alte Block muss überschrieben werden nicht eingefügt.
Nach dieser “Reparatur” der Header war es möglich aus dem Snapshot und der Basisdatei ein einziges VDI Dateisystem zu erzeugen.
Dazu habe ich das Tool CloneVDI verendet: https://forums.virtualbox.org/viewtopic.php?t=22422
Wenn der Balken anfängt zu laufen ist das der erste Schritt
Gewonnen
