VMware-Forum

Hallo Forum,

Ich habe folgende Situation mit meiner VM: Ich habe auf WS9/Win7 einen Windows 2003 Server Guest. Dieser hatte urprünglich einen Snapshot auf dem ich gerabeitet habe. Gestern fing die Maschine an sich seltsam zu Verhalten (Fehlende Dateien, u.ä.). Darufhin habe ich sofort noch einen Snapshot gemacht (was ziemlich sinnlos war) und habe die Maschine runtergefahren. Da ich dringende Arbeiten zu erledigen hatte, habe ich mit dem Backup weitergearbeitet, das kurz darauf ähnliche Probleme hatte. Da beide VMs auf der gleichen Platte lagen (ja, saudämlich), wird die vermutlich defekt sein, obwohl sie ansonsten keine Probleme macht. Ich konnte eine der VMs ohne Probleme auf eine saubere Platte schieben. Die Situation ist jetz folgende: Die ursprüngliche VM (ohne Snapshot) lässt sich starten und benutzen. Für mich interessanter sind aber die Daten im Snapshot: Hier bekomme ich beim Versuch sie zu starten: "The file specified is not a virtual disk" und beim versuch das VMDK zu mounten: "Error reading volume information. Please select another disk file". Ein Versuch mit OSFMount war ebenso erfolglos.

Gibt es noch etwas, was ich versuchen kann? Die VM ist mir fast egal, aber ein paar Daten hätte ich gerne wieder, ein erfolgreicher Mount würde mir daher reichen.

Ich habe mal ein ZIP mit einer Dateiliste und mit allen mir sinnvoll erscheinenden Dateien hier hinterlegt: https://www.dropbox.com/s/yn3s0o9wymbax ... _files.zip

Vielen Dank im Voraus!

Du benutzt erstmal den vDISK-Type Sparse mit 2GB-Häppchen (s001 - s026) mit 50GB Grösse. Darauf hast du laut "vmware.log" jetzt noch zwei aktive Snapshots (000001 und 000002) angelegt.
Snapshots sind kein Backup Sie sind ohne alle Mitglieder der Snapshotkette nicht lauffähig, da ein Snapshot nur die Änderungen zu jeweiligen Basis-VMDK enthält. Damit deine VM überhaupt lauffähig ist und auch alle Daten enthält, mußt du folgende VMDK-Dateien im Ordner haben:

Da Snapshots nur mittel zum Zwecke eines Backups sind, verstehe ich auch beim besten Willen nicht, weshalb du auf einem Snapshot monatelang arbeitest. Snapshots nimmt man entweder um ein Backup der laufenden VM machen zu können, um bei kurzzeitigen SW-Tests im Fehlerfall schnell zu dem Stand davor zurückkehren zu können oder wenn man "Linked Clones" nutzen will. Bei dir kommt scheinbar nichts davon zum Tragen und das könnte sich böse in Form von Datenverlusten rechen.
Sparse-Disk belegen zwar nur den in der VM belegten Platz, neigen aber zu starker Fragmentierung, da bei Schreib-IO in der VM erstmal beim Host-OS irgend ein freier Sektor auf dem gesamten Host-Datenträger angefragt werden muß. Das erklärt dann auch Log-Einträge folgender Art:

2014-01-14T17:26:56.677+01:00| vmx| I120: scsi0:0: Command WRITE(10) took 4.367 seconds (ok)
2014-01-14T17:26:56.765+01:00| vmx| I120: scsi0:0: Command WRITE(10) took 4.209 seconds (ok)
2014-01-14T17:26:56.788+01:00| vmx| I120: scsi0:0: Command WRITE(10) took 4.232 seconds (ok)

Diese 4 Sekunden machen sich je nach weiterer Host-Gast-Auslastung in der VM bereits deutlich bemerkbar. Die VM ruckelt irgendwie oder bei starker Hostlast springt manchmal auch der Mauszeiger. Glücklicherweise sind alle VMDK-Zugriffe mit (ok) abgeschlossen, VMware hat zwar einen wenig potenten oder auch einfach ausgelasteten Host-Datenträger festgestellt, konnte aber noch rechtzeitig die IO-Anforderungen der VM auf dem Host ausführen. Je nachdem wie lange diese Ausführung dauert, sind auch BSODs bzw Kernel-Oops eines Gastes möglich.


Die verlinkte Dateiliste ist für mich ohne Datum- und Grössenangaben wertlos und die Sache mit dem Backup mußt du auch mal genauer erklären. An deiner Stelle hätte ich bei Datenproblemen auch mal einen Dateisystemcheck sowohl auf Host als auch Gast durchlaufen lassen. Sparse-Disks sind durch die starke Fragmentierungsneigung extrem anfällig, da sämtliche IO-Anforderungen immer in 4KB-Schritten getätigt werden. Eine Datenrettung bei Sparse-Disks oder Snapshot allgemein ist nur in dieser Grösse möglich oder du mußt viel Glück haben.

Hi, Danke schonmal für die schnelle Antwort.

Zu deinen Punkten:

Als Backup waren die Snapshots nicht gedacht, ich habe irgendwann eine Konfigurationsänderung gemacht und vorher einen Snapshot gemacht. Da alles erfolgreich war bin ich beim Snapshot geblieben. Den hätte man nactürlich mal wieder integrieren können.

Mit Backup meine ich eine 1:1 Kopie der VM. Ich habe also eine wenige Tage alte Kopie, die den zweiten Snapshot nicht hat, aber die gleichen Probleme hat.

Eine Datenträgerprüfung habe ich im Client nicht gemacht, wohl aber auf dem Host. Dieser bleibt aber reproduzierbar an einer Stelle stehen bzw ist sehr langsam. Ich benutze das Standardding von Windows, man könnte natürlich mal was anderes probieren. Das habe ich übrigens auch schon nach dem Crash der ersten VM gemacht und irgendwie habe ich das Gefühl, das dass der Grund sein könnte, weswegen beide VMs nun defekt sind (Ich hatte beim Scan mitgegeben, dass er Fehler korrigieren soll).

Falls interessant, hier ein Screenshot des Ordnerinhaltes:


Danke!

Hi
als erstes mach mal einen checkdisk mit diesem Befehl:

chkdsk /f /x /r C:

Dafuer wird ein Neustart des Hosts noetig.
Wenn das Problem danach weiter besteht dann muessen wir wissen welche vmdk defekt sein soll.

Die vmdks mit Namen *-00000*-s0**.vmdk muessen alle mit KDMV anfangen - evtl ist eine dabei die das nicht mehr tut ...

Die Dateianfaenge kann man mit einem hexeditor ueberpruefen - oder auch mit dsfo.exe
Dann extrahiert man sich die ersten 4 bytes und kann sich das ganze mit Notepad ansehen.

Das weiyere Troubleshooting ist einfach wenn man davor sitzt - leider ist es aber nicht mal eben erklaerbar - bei Bedarf ruf mal an und ich schau mir das mal selber an ...

Deine VM belegt ja trotz Sparse-Format die vollen 50GB. Entweder hast du das unbedingt notwendige, regelmäßige Shrinken unterlassen oder du produzierst soviel Schreiblast in der VM, daß du von Sparse-Format absolut keinen Platzvorteil hast. Viel schlimmer dabei ist jedoch, daß wenn der Platz auf dem Host zuende geht, die VM entweder direkt abstürzt oder es mangels Platz zu einem Datenverlust kommt. Neben den 50GB der Basis-VMDKs kommen für deinen ersten Snapshot nochmal ~6.2GB und für den zweiten weitere ~1.5GB an notwendigen Platz auf dem Host-Datenträger hinzu. Das "vmware.log" listet bei Workstation und Player inzwischen leider nicht mehr, wieviel Platz auf dem Host überhaupt noch frei ist.
Daher die Fragen an dich, wieviel Platz auf dem Host noch frei ist und wieviel Speicherplatz innerhalb der VM wirklich belegt ist.


Im Normalfall würde ich dir ja jetzt empfehlen, endlich die Snapshots einzupflegen - in VMware-Sprech "löschen" und dazu brauchst weiteren Speicherplatz. Es macht jedoch absolut keinen Sinn einem Datenträger noch zu vertrauen, bei dem nicht mal mehr der Dateisystemcheck durchläuft. Die Chancen auf einen Medienfehler steigen an dieser Stelle auf 99 Prozent.

Du brauchst jetzt daher einen externen oder zumindest weiteren Datenträger im Host mit ausreichend Speicherpatz und kopierst dann probehalber bei abgeschalteter VM den gesamten VM-Ordner an den neuen Platz. Wenn das ohne Host-Fehlermeldung klappt und du ausserdem die VM von dort mit Workstation oder Player starten kannst, ist zumindest die VMDK-Datenstruktur auf dem problematischen Datenträger noch nicht beschädigt.


Wenn du soweit gekommen bist, hast du jetzt eine lauffähige 1:1-Kopie. Die weiteren Schritte wären jetzt von meiner Warte, mich endlich von allen Snapshots zu lösen und dazu in einer CMD mit Hilfe des "vmware-vdiskmanager.exe" die bestehende VMDK (vDISK) inklu beider Snapshots in eine neue VMDK zu clonen. Dazu brauchst du wieder mindestens 50GB Platz. Die Syntax in deinem Fall wäre:


[edit]
Der Ulli war wieder schneller. Mein Rat ist, ruf ihn an. Im Normalfall solltest du jetzt eine Private Message/Nachricht mit seiner Telefonnummer haben.

@continuum: Ich habe chkdsk über Nacht laufen lassen, hier das Ergebnis:


Sieht ja recht unverdächtig aus, und auch sonst macht die Platte ja keine Probleme. Am Status der VMs/VMDKs hat sich nichts verändert.

Ich habe alle VMDK-files des defekten Snapshots (*-cl1-000001-s*) durchgesehen, s005 is wie auch schon im obigen Screenshot zu sehen 0KB groß und enthält daher auch keine Zeichen. Ist das ein valider Zustand?


@Dayworker: Der Client braucht tatsächlich sehr viel Platz, da ist eine komplette Test- und Entwicklungsumgebung drin, 2 Application Server, Datenbank, Eclipse, etc. Es stimmt, von dem Sparse hab ich eigentlich nichts, und da mir die Platte auch schon vollgelaufen ist, habe ich immer eine Kopie der VM (Leider auf dem selben Datenträger).

Die Kopie auf einen sauberen Datenträger habe ich ja bereits gemacht. Wenn ich dort die Snapshots auflösen will, kommt wieder die Fehlermeldung:

Bingo - das ist die Ursache.
Die 0kb *s-005.vmdk muss ersetzt werden.
Du hast leider nichts brauchbares in der Liste.

Leg eine neue VM an -
gleicher vmdk-typ mit 50 GB.
Erstell einen Snapshot und nimm davon die *-000001-s005.vmdk und ersetz die 0kb Datei damit.
Die neue VM brauchst du dafür nur einmal kurz anstarten - kann danach direkt wieder abgeschaltet werden

Super, das hat funktioniert, ich konnte das VMDK mounten und fast alles wichtige runterkopieren. Einige Dateien waren nicht lesbar, aber mit dem Stand komme ich wunderbar klar.

Ich studiere dann jetzt mal etwas VMDK, da scheint einiges ganz anders zu funktionieren als ich dachte...

Vielen Dank Euch, das gibt es nicht so oft, dass man so schnelle und kompetente Hilfe bekommt!

Prima
hier hast du etwas Lesestoff
http://sanbarrow.com/vmdk-handbook.html

Wenn du etwas nicht verstehst - ruf ruhig mal an - wenn ich gerade Zeit habe ich meistens Lust auf eine nette Plauderei

Stimmt, den Anruf kann ich persönlich nur empfehlen.