VMware-Forum

Hallo,

ich habe zuhause seit einiger Zeit das Problem, dass ich eine VMDK nicht verwenden kann.

Die ganze Geschichte:
Von meinem Monitoring erhielt ich Anfang August die Meldung, dass die Kühlung im "Serverraum" ausgefallen ist.
Die Temperatur des Servers (Fujitsu TX300S6 mit ESXi 6.5UkeineAhnung) stieg dann auf ~40 Grad. Da ich auf DIenstreise war konnte ich wenig machen.
Nach ein paar Tagen habe ich dann festgestellt, dass eine VM nicht mehr erreichbar ist.
Sie ließ sich auch über das Webinterface nicht rebooten, und auch nicht hart ausschalten.
Also habe ich den ganzen ESX rebootet.
Leider hat die Hitze wohl dem USB-Stick geschadet.
- no operating system found

Nach meiner Rückkehr habe ich dann einen neuen Stick gesteckt und VMWare 6.7 (<- vielleicht der erste Fehler?) installiert.
Nach der Grundkonfiguration (welche Karte steckt wo im Switch, welche IP, etc) liefen meine DCs wieder. Nur der Mailserver hat ein Problem.
Ich habe ihn hochgefahren und C funktioniert soweit, nur D wird als unformatiert angezeigt.
Ich habe ihn dann gleich runtergefahren, da ich erst einmal eine kopier der VMDK für D machen wollte.
Das geht leider nicht über das Webinterface, und auch nicht über SSH.
Die Meldung interpretiere ich so, dass da gerade nicht zugegriffen werden kann.

<quote>
Destination disk format: VMFS thin-provisioned
Cloning disk 'HMAIL - Windows Server 2016_1.vmdk'...
Clone: 10% done.Failed to clone disk: Input/output error (327689).
</quote>

Leider hat die Hitzewelle im "Serverraum" auch dem NAS für das Backup zu gesetzt, so dass es nicht einfach ein "zurücksichern" ist.
Hat jemand eine Idee?

Steht doch alles drin:

Silece hat geschrieben:Failed to clone disk: Input/output error

und just vor drei Tagen veroeffentlichte contiunuum dies am hiesigen Orte...

Hallo,

danke!
Ich habe vor einer Woche das Forum durchsucht und nichts gefunden, dann eine Woche mit den Kindern verbracht und dann, war da einfach ein neuer Post...
Schande über mich.

Nee, nicht Schande

Das weist einfach auf die weise Voraussicht von User "continuum" hin!

Hallo,

Ich habe mit dem ersten Schritt begonnen:
dd bs=1M if="HMAIL - Windows Server 2016_1-flat.vmdk" of="HMAIL - Windows Server 2016_1-flatclone.vmdk"
DA kam dann der Abbruch bei 146MB(von 104GB).
Also dieses MB ausgeklammert.
Puh, nur eine Lücke, weil, läuft durch.
Jetzt : vmkfstools -p 0 vmkfstools -p 0 "HMAIL - Windows Server 2016_1-flat.vmdk" > mapping-name.txt

Liefert eine Text-Datei.
Das einzige spannende ist

Mapping for file HMAIL - Windows Server 2016_1-flat.vmdk (107374182400 bytes in size):
[ 0: 1048576] --> [VMFS -- LVID:59037ee4-7683f61a-7f67-001999b8ed06/59037ee3-73427c72-dea2-001999b8ed06/1:( 663054450688 --> 663055499264)]
[ 1048576: 134217728] --> [NOMP -- 0 --> 134217728)]
[ 135266304: 40894464] --> [VMFS -- LVID:59037ee4-7683f61a-7f67-001999b8ed06/59037ee3-73427c72-dea2-001999b8ed06/1:( 673254998016 --> 673295892480)]

Aber leider sagt das tutorial nur

If that works we can use the mapping-name.txt file to create a dd-command that copies the vmdk fragment by fragment.
Unfortunately it is very rare that this command will work at this stage.

Blöd, dann bin ich wohl ein Sonderfall

Und was jetzt? Was mache ich mit dieser Mapping-Datei?

Das einfachste wäre, mit "continuum" zu skypen.

Dem moechte ich beipflichten
Mit undokumentierten Parametern und dem Inhalt der Mapping Table bin ich aussen vor.

Meinereiner wuerde bei "nur einem Defekt" eher versuchen, mit der MOA und ddrescue (oder mit viel Muehe und eigenen iterativen dd-Aufrufen im ESXi) auch von dem ausgeklammerten MB noch so viel als moeglich zu erhalten. Vielleicht ist der fehlerhafte Block ja noch viel kleiner als das ganze MB, und fuer die MAILBOX-Software gar nicht notwendig...

Andererseits muss ich gestehen, dass das ZIEL meiner Recovery-Versuche in wirklich KEINEM Fall einfach derselbe Datentraeger gewesen waere. Ich hoffe, Du hast bei Deinem Post fuer "of=" den Pfad auf einen anderen Datentraeger einfach aus Uebersichtlichkeitsgruenden weggelassen.

Mapping for file HMAIL - Windows Server 2016_1-flat.vmdk (107374182400 bytes in size):
[ 0: 1048576] --> [VMFS -- LVID:59037ee4-7683f61a-7f67-001999b8ed06/59037ee3-73427c72-dea2-001999b8ed06/1:( 663054450688 --> 663055499264)]
[ 1048576: 134217728] --> [NOMP -- 0 --> 134217728)]
[ 135266304: 40894464] --> [VMFS -- LVID:59037ee4-7683f61a-7f67-001999b8ed06/59037ee3-73427c72-dea2-001999b8ed06/1:( 673254998016 --> 673295892480)]

Diese mapping Datei zeigt uns ....
Das erste MB der thin provisioned VMDK ist schon belegt - klar - das ist der MBR / GPT ...
Das naechste Stueck ist 127 MB gross und bis jetzt noch nicht beschrieben. ESXi nutzt daher statt einem Fragment auf dem VMFS-volume sozusagen einen Verweis auf /dev/zero.
Das ist natuerlich deulich platz-sparender.
Die naechsten 4 MB sind dann wieder belegt ... und so weiter.

Kurz gesagt - der Auschnitt der mapping.txt ist voellig in Ordnung - kein Grund zur Sorge