Folgendes habe ich probiert, dabei wurde die vmdk nicht etwa kleiner, sondern graduell größer:
- In XP defragmentiert
- In XP mit SDelete aufgeräumt
- Aus WS 12 defragmentiert und Fetsplatte komprimiert
- Vom Host aus mit dem Kommandozeilenprogramm komprimiert
Prinzipiell gilt für jede nichtmitwachsende VMDK (Sparse- bzw Thin-Format), daß man darin sowohl jedwede Defragmentierung als auch beim Gast-Install die Finger von einer kompletten Formatierung sein läßt. Wenn man das Gast-OS installiert, wählt man nach der üblicherweise stattfindenden Partitionierung immer die Option "Schnellformat" aus. Macht man das nicht, belegt die VMDK sehr schnell die spezifierte VMDK-Grösse und sorgt möglicherweise auf dem Host für einen volllaufenden Datenträger. Das ist sowohl für die dann häufig abstürzende VM als auch das Host-OS eine Katastrophe, da sich das Host-OS mangels freien Platz hoffentlich gleich wieder beendet oder sich sogar erneut aufhängt.
Da du jedoch über den Converter kommst, hättest du bereits vor dem Acronis-Image den Datenträger defragmentieren und mit "sdelete" vorbehandeln sollen. Das hätte höchstwahrscheinlich sowohl den Imageumfang als auch die Converterdurchlaufdauer positiv beeinflußt. Der Converter kann auch nur bedingt mit irgendwelchen Acronis-Images umgehen. Es wäre daher absolut möglich, daß der Converter die im Image als "frei" gekennzeichneten Bereiche trotzdem in deine "not preallocated disc space" sprich Sparse-Disk geschrieben hat. Es wäre daher mit Acronis wesentlich besser gewesen, das Image per Acronis-CD in eine VM wiederherzustellen und hernach die VM mithilfe des Converters zu patchen (Schaltfläche "Reconfigure Machine" im Converter).
Die Defragmentierung in der VMware-Workstation funktioniert anders, als wie von dir gedacht. Da die Workstation den vDISK-Inhalt überhaupt nicht sieht, versucht diese nur die über den gesamten Host-Datenträger verteilte VMDK wieder enbloc zu schreiben. Das ist wie die Defragmentierung einer SSD absolut unsinnig, da der Inhalt bereits fortlaufend geschrieben worden sein kann und mit der WS-Defragmentierung vielleicht diese fortlaufend geschriebenen Daten sogar unfreiwillig fragmentiert werden. Mal davon abgesehen, daß dieses Zusammenfügen von VMDK-Teilen nur klappen kann, wenn der freie Platz mindestens so groß wie die VMDK ist, verkürzt zudem früher oder später jeder Schreibzugriff die Lebensdauer einer jeder SSD und dazu hat die Defragmentierung einer SSD im Gegensatz zur Festplatten keinen beschleunigenden Effekt.
Deine Aussage "Vom Host aus mit dem Kommandozeilenprogramm komprimiert" läßt mich vermuten, daß du den "vmware-vdiskmanager" auf der Win-CMD genutzt hast.
Leider hilft dir dieser hier auch nicht wirklich weiter. Dessen Option "-d" (defragment the specified virtual disk. Only local virtual disks may be defragmented.) versucht auch nichts anderes, als wieder die über den gesamten Host-Datenträger verteilte VMDK enbloc zu schreiben. Sie ist daher nur als Pendant der Workstation-Schaltfläche zur "Defragmentierung". Etwas anders sieht es mit der Option "-k" (shrink the specified virtual disk. Only local virtual disks may be shrunk.) aus. Rein theoretisch kannst du damit eine Sparse-Disk wieder verkleinern. In der Praxis kann das jedoch nur funktionieren, wenn du vorher die freien Bereiche der vDISK auf logisch Null gesetzt hast und dazu dient entweder "sdelete" als Zusatztool von SysInternals oder du zweckentfremdest dazu das seit mindestens Windows2000 beiliegende Tool "cipher", bei dem du aber nach dem ersten gewünschten Durchlauf schnell sein muß, bevor das Tools einen anderen logischen Wert (FF wenn ich mich recht entsinne) in die freien Sektoren schreibt. Dafür muß man die vDISK aber vorher erstmal entweder über die Workstation-Anwendung oder "vddk" ins Host-System mounten/einbinden.
Ein paar Worte noch zum häufig geschriebenen "dd".
Das kopiert einen Datenträger immer Bitweise und das ist unabhängig vom Gast-OS überhaupt nicht nötig. Mit geeignet gesetzten Flags lassen sich sowohl Linux per "cp" als auch Windows über das mitgelieferte "robocopy" einfach kopieren. Da die Wiederherstellung des Bootsektors auch kein Hexenwerk ist, erledigt man das anschließend halt zu Fuß. Falls ein älteres Windows kein Robocopy mitbringt, kann man entweder dieses nachinstallieren oder erledigt den Job mithilfe eines kleines Helferlein namens
Drive Snaphot. Das Tool gibt es als 32bit- und 64bit-Version und ist als EXE-Datei ohne eine Installation lauffähig. Letzteres hat auch den Vorteil, daß der Bootsektor mitkopiert wird. Einzige wirkliche Schwachstelle ist das Fehlen einer Repartitionierungsfunktion, falls die neue Partition kleiner als die Ursprungspartition ist und die Datenmenge aber eigentlich auf die neue Partition passen würde. Das läßt sich aber auch umgehen, wenn man die Ursprungspartition vor dem Image bereits aufräumt und verkleinert.