Defragmentation failed:The specified virtual disk needs repa

[circulars]

Ich habe deshalb von einem alten Rechner noch eine Datei (v7-1-3 gezogen, geht die?!?), allerdings noch auf Win7-32bit (hier: 64bit) und versuche es nun mit ihr.

Zwecks Dokumentation:

1.) vware-vdiskmanager von Version 9 in "..." "...v9_funktioniert nicht umbenannt
2.) den diskmanager von V.7-1-3 in das u.g. Program FIles-Verzeichnis kopiert
3.) "C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager" -r "Windows 7 x64D-000001.vmdk"
a) zunächst hatte ich vergessen, dass die VM nun wieder oben war -> "... Lock timed out." -> o.k.
b) (nach dem Herunterfahren und Schließen von VMware):
No errors wer found on the virtual disk, 'Windows 7 x64D-000001.vmdk'.

Ok, aber weshalb dann immer noch, "... needs repair", wenn doch keine Fehler und nun auch keine Snapshots mehr?!?

Lade nun die Dateien hoch.

DIE DATEIEN SIND NUN ALLE GANZ AKTUELL OBEN - ES GIBT AUCH NUR NOCH EINE EINZIGE LOG-DATEI im VirtualMachine-Verzeichnis. - Es sind 4 neue Dateien oben, die alten sind in "alt-Ordner" verschoben.

[JustMe]

Sorry, aber ich werde mir jetzt nicht noch rasch ein Office-Paket installieren, nur um neben den paar Screenshots in der docx auch noch Deinen Text anschauen zu koennen

Und die vmware.log vom 31.1.15 18:00 taucht zwar im VM-Verzeichnis auf, aber nicht in Deinem Webspace (nochmals ) Im "alt"-Ordner findet sich eine vom 30.1., aber auch im aktuellen Ordner ist wieder keine drin. Die Logdatei vom vprintproxy ist dagegen m.E. eher mehr als fluessig.

Fassen wir noch einmal zusammen:
Auch bei Verwendung von "-r" (klein) und -00009 kommt die Meldung "needs repair"? Das ist dann ein weiterer Hinweis auf die Richtigkeit von ~thc's Diagnose, dass das Problem im letzten Snapshot (eben die -00009) liegt. Leider war der schon heute morgen mit ca. 9GB nicht gerade klein.

Mit -r wird auch nichts "repariert", sondern eine neue vmdk erstellt (ein "Clone"), z.B. vom Stand der -00008. Diesen Clone kannst Du mal in eine neue VM einbinden, und schauen, ob Du mit diesem Stand "leben" kannst. Dann koenntest Du die weitere Bastelei an der -00009 einstellen...

In den sechs Screenshots der .docx sehe ich uebrigens keinen Versuch mit "-r", sondern immer nur mit "-R".

Der erste Screenshot zeigt, dass die vmdk 13.2GB belegen wuerde (und keinen Cleanup benoetigen wuerde ), aber das Dateilisting zeigt fuer die Basis-vmdk eine Groesse von ca. 70G. Da stimmt dann doch was nicht...

Anyway, wie Du schon schriebst: Platz genug ist jetzt vorhanden, also fuehre bitte mal den Befehl mit -r (klein und einer Ziel-vmdk aus. Danach poste das Ergebnis dieses Befehls hier (inkl. Dateilisting vorher+nachher), und schaue, ob Du mit diesem Stand in einer neuen VM zufrieden sein kannst.

[JustMe]

OK, danke fuer die .pdf.

Aber auch wenn Du zig-mal unter den Screenshot schreibst, Du haettest "-r" verwendet: Der Screenshot zeigt deutlich, dass Du "-R" in der Befehlszeile tatsaechlich verwendet hast

[circulars]

Sorry, aber ich werde mir jetzt nicht noch rasch ein Office-Paket installieren, nur um neben den paar Screenshots in der docx auch noch Deinen Text anschauen zu koennen

Gemach, nun als pdf

Und die vmware.log vom 31.1.15 18:00 taucht zwar im VM-Verzeichnis auf, aber nicht in Deinem Webspace (nochmals ) Im "alt"-Ordner findet sich eine vom 30.1., aber auch im aktuellen Ordner ist wieder keine drin. Die Logdatei vom vprintproxy ist dagegen m.E. eher mehr als fluessig.

findet er scheinbar nicht mit *.log-Suche, aber danke für den Hinweis, habe Sie nun manuelll umkopiert in den Upload.

Fassen wir noch einmal zusammen:
Auch bei Verwendung von "-r" (klein) und -00009 kommt die Meldung "needs repair"?

Nein, ersetzt man -R durch -r funktioniert es gar nicht (sh. Screenshots in der PDF).

Das ist dann ein weiterer Hinweis auf die Richtigkeit von ~thc's Diagnose, dass das Problem im letzten Snapshot (eben die -00009) liegt. Leider war der schon heute morgen mit ca. 9GB nicht gerade klein.

Bitte nochmals Screenshot in VMSystem_Screenshots.pdf (erste Version) ansehen - ich habe m.E. keine Snapshots mehr, nur noch den allerletzten Stand - oder ist das auch ein Snapshot (den kann ich dann allerdings nicht mehr löschen, denn sonst bleibt keine Version ehr)

Mit -r wird auch nichts "repariert", sondern eine neue vmdk erstellt (ein "Clone"), z.B. vom Stand der -00008. Diesen Clone kannst Du mal in eine neue VM einbinden, und schauen, ob Du mit diesem Stand "leben" kannst. Dann koenntest Du die weitere Bastelei an der -00009 einstellen...

Das verstehe ich nur noch der Theorie nach, aber -r funktioniert ja ohnehin gar nicht (s.o.)

Der erste Screenshot zeigt, dass die vmdk 13.2GB belegen wuerde (und keinen Cleanup benoetigen wuerde ), aber das Dateilisting zeigt fuer die Basis-vmdk eine Groesse von ca. 70G. Da stimmt dann doch was nicht...

Gut, aber wie bekomme ich das wieder hin?

Anyway, wie Du schon schriebst: Platz genug ist jetzt vorhanden, also fuehre bitte mal den Befehl mit -r (klein und einer Ziel-vmdk aus. Danach poste das Ergebnis dieses Befehls hier (inkl. Dateilisting vorher+nachher), und schaue, ob Du mit diesem Stand in einer neuen VM zufrieden sein kannst.

Erledigt, aber es funktioniert leider nicht (sh in pdf...neu). - Um ganz sicher zu gehen, habe ich mir die Befehlszeile von -R kopiert und eingefügt und dann nur noch das -R durch -r ersetzt, dürfte eigentlich nichts schiefgegangen sein ... aber doch geht es nicht.

Gut, und zum Abschluss habe ich alle DIR neu erstellt und alle Schritte per Screenshot in der VMSystem_Screenshots_neu.pdf dokumentiert...fast alles mit Uhrzeit.

[~thc]

Also ganz langsam zum Mitschreiben :

- Alles mit "-00000X" im Namen ist ein Snapshot
- Die aktuelle Snapshotkette deiner VM lautet 1-9-8-5-Basisdisk
- Der falsch angegebene Platzbedarf und die "needs repair"-Ansage deuten auf eine verhunzte Snapshotkette hin
- Die korrekte Syntax für den Konvertierungsbefehl "-r" lautet

Code: Alles auswählen

vmware-diskmanager -r alte-disk-oder-snapshot.vmdk -t 2 neue-disk.vmdk

Bitte versuche also die Konvertierung in eine Thick-VMDK mit

Code: Alles auswählen

"C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager" -r "Windows 7 x64D-000001.vmdk" -t 2 "Windows 7 x64T.vmdk"

[Dayworker]

Ausgehend von Ulli's Post im Thread Hilfe! Defekte VDMK! ist der der Workstation7 beiliegende "vmware-vdiskmanager.exe" die letzte funktionale Version um vDISKs zu reparieren und eine Downloadquelle für diese Version ist ebenfalls verlinkt. Bei allen späteren WS-Versionen macht die Repair-Funktion überhaupt nichts.

Das ist ein sehr wertvoller Input!...damit ist geklärt, warum bislang immer NICHTS passiert ist. - Was denkt sich VMware eigentlich, Programmteile auszuliefern, die ohne Funktion sind?

Schnitzeljagd zum Download:
http://vmware-forum.de/viewtopic.php?p=166336#166336
http://kb.vmware.com/kb/1023856
-> und dann muss man sich einfach in sein Download-Center einloggen, zum Glück hatte ich V7 bereits.

Nun habe ich VMware-workstation-full-7.1.4-385536 zur Installation auf dem Rechner - wie komme ich nun bitte an die benötigte, darin wohl enthaltene Datei heran, ohne zu installieren - VM9 will ich natürlich nicht überschreiben?

Ich habe deshalb von einem alten Rechner noch eine Datei (v7-1-3 gezogen, geht die?!?), allerdings noch auf Win7-32bit (hier: 64bit) und versuche es nun mit ihr.

Weshalb lädst du denn die komplette WS7.x runter
Ganz unten im verlinkten KB-Eintrag gibt es den Punkt "Attachment" und da kann man sich direkt den funktionierenden "vmware-vdiskmanager" einzeln für MacOS, Linux und Windows downloaden.

Warum VMware doirt fehlerhafte SW ausgeliefert hat, ist ganz einfach erklärt. Weil es VMware bzw der neue für die Workstation verantwortliche Produktmanager nicht wußte, was man damit reparieren konnte und das es überhaupt so eine Funktion gab. Im Endeffekt haben diese jedoch nur VMware-Freaks genutzt, der Rest hat einfach das Backup eingespielt und gut war's....