VMware-Forum

Hallo,

ich habe mein Problem schon mal im Mac-Forum geschildert:

http://www.macuser.de/forum/f105/vm-lae ... rn-677787/

aber da weiß wohl niemand was darüber. Daher nun mal hier gefragt:

Ich habe eine vm in Fusion auf einem MacBook und die lässt sich partout nicht verkleinern.

Mit sdelete genullt, defragmentiert, aber es wird nicht kleiner, obwohl die Platte nur ca. 30 GB Daten beherbergt.
Aber das Verzeichnis der VM hat 130 GB.

Ich vermute stark, dass es damit zusammenhängt, dass beim Löschen der Snapshots (zur Vorbereitung zum Shrink) Fehler aufgetreten waren.

Gibt es da noch ein Mittel?

Was macht man da?

Ich habe zu wenig Platz, als dass ich 100 GB für die VM verschenken könnte.

Danke franc

Du hast also eine mitwachsende (Sparse) vDISK erstellt bzw laufende Snapshots und läßt auf diese ein Defragmentierungsprogramm los. Das ist echt wenig hilfreich und führt bei wenig Platz auf dem Host dann irgendwann sogar zum Gast-Absturz. Denn was der KB-Eintrag Defragmenting, shrinking, and cleaning up Fusion virtual machine disks (1001934) dabei leider verschweigt, ist die Tatsache, daß während der Gast-Defragmentierung die vDISK meist auf ihre maximale Grösse anwächst
Bei einer Sparse-Disk wird ja nur dann Platz belegt, wenn der Gast neue Daten schreiben will. Dabei wird dann vom Host-OS bzw VMware-Produkt freier Platz irgendwo auf dem gesamten Host-Datenträger angefordert und dann von VMware genutzt. Das sich dabei die VMDK-Datei auf dem Host-Datenträger fragmentiert und es dadurch auch zu Schreibperformanceeinbrüchen, kann man nicht verändern. Aber bei Snapshots spielt das ja eh keine Rolle, da diese immer vom Disk-Typ Sparse sind.
In deinem Fall optimiert/defragmentiert der Gast, ob Sparse-Disk oder Snapshots spielt keine Rolle, seinen Datenträger und fordert dazu kontinuierlich freien Speicherplatz auf dem Host an. Wenn dieser erschöpft ist, stürzt dir wahrscheinlich zuerst der Gast und dann der Host mangels freien Speicherplatz ab. Denn erst wenn der Gast seine Daten enbloc ausgerichtet hat, löschen Defragprogramme im Gast den freien Speicherplatz. Ob dazu der freie Bereich ausgenullt oder sogar dann platzverschwendend mit FF beschrieben wird, kann ich dir nicht beantworten und könnte auch vom Defrag-Programm abhängen. Selbst wenn das Defrag-Tool den freien Bereich ausnullt, wird es dazu bei dir mangels Platz nur nie kommen.


Weshalb hast du überhaupt viele Snapshots
Ein VMware-Snapshot ist im Gegensatz zu anderen Dateisystemen wie ZFS nämlich kein Backup sondern nur Mittel zum Zwecke eines solchen. VMware lockt beim VM-Start die vDISK des Gastes, um einen Schreibzugriff von aussen zu verhindern. Damit man die vDISK von ausserhalb sichern kann, bedient man sich eines Snapshots, der wie gehabt nur die neu zu schreibenden Daten enthält. Unveränderte Daten werden weiterhin aus der Basis-VMDK bzw dem vorherigen Snapshot bei einer Snapshotskette gelesen. Durch einen Snapshot wird also der Lock-Mechanismus auf die neue Datei gesetzt und die vorherige VMDK wird frei. Damit kann man diese Datei extern kopieren. Nach dem externen Backup löscht man dann den Snapshot und dessen Inhalt wird in den vorherigen Datenbestand (Basis-VMDK, Snapshotkette) eingepflegt.



Damit du dein Problem lösen kannst, würde ich dir empfehlen, die Defragmentierung sofort zu beenden und sie auch in allen virtuellen Maschinen zu deaktivieren, da sie hier aufgrund der Virtualisierung kontraproduktiv ist. Ein Gast sieht eh nichts vom darunterbefindlichen Host und hat auch keinen direkten HW-Zugriff auf den Host.
Da du geschrieben hast, daß das Auflösen der 5 Snapshots fehlgeschlagen ist, dürfte die Snapshotkette eh nicht mehr vollständig sein. In diesem Fall sind sämtliche Snapshotpunkte verloren und nur in der VMX-Datei steht jetzt noch der Name der aktuell genutzten/aktiven VMDK. Du erstellst jetzt bei abgeschalteter VM einfach einen neuen Snapshot und löschst diesen dann bei immer noch abgeschalteter VM. Beides kann je nach Umfang der zwischenzeitlich veränderten Daten und vor allem IO-Performance des Host-Datenträgers geraume Zeit dauern. Am Ende werden dann alle Snapshots in die Basis-VMDK namens "Win Hard Disk.vmdk" bzw die Sparse-Disks "s001" bis "s033" eingepflegt sein.

Vielen Dank für die Erklärung.
Ich habe das immer falsch gemacht, ich habe die Snapshots tatsächlich als eine Art Backup verwendet.

Dayworker hat geschrieben:... Du erstellst jetzt bei abgeschalteter VM einfach einen neuen Snapshot und löschst diesen dann bei immer noch abgeschalteter VM. Beides kann je nach Umfang der zwischenzeitlich veränderten Daten und vor allem IO-Performance des Host-Datenträgers geraume Zeit dauern. ...

Leider hat das nicht funktioniert. Nachdem ich auf 'Snapshot löschen' drücke und die Warnung abnicke kommt zwar noch kurz eine Meldung mit:

"Gelöschte Dateien werden bereinigt"

das ist aber schnell wieder weg und ich erhalte die Fehlermeldung:

"Beim Löschen des Snapshots ist ein Fehler aufgetreten.
Gelöschte Dateien können nicht bereinigt werden."

http://abload.de/img/bildschirmfoto2013-06kealw.png

Die Defragmentierung hatte ich übrigens schon erfolgreich abgeschlossen:

http://abload.de/img/bildschirmfoto2013-0665yuh.png

In der Tat hatte das mein System auch ordentlich ausgebremst.

In meiner vmx steht:



Ich habe auch noch 000001.vmdk bis 000006.vmdk sowie die dazugehörige sparse (...-s001.vmdk usw)
Kann ich die nicht einfach löschen?
Oder baut das 000007 auf diesen auf?

Durch die Experimente mit dem Snapshot löschen habe ich jetzt übrigens auch noch 000008.vmdk bis 000010.vmdk, da ich es (auch wegen der Screenshots) mehrfach probiert hatte.

Bringt es was, wenn ich wieder versuche mit sdelete den ungenutzten Plattenplatz zu nullen?

Was tun?

Danke, franc

EDIT: nur die 000007-Dateien haben zusammen 37 GB, wie sich mit 'du' erfahren lässt:



Also etwas größer als in der VM angegeben.

Reden wir immer noch über dieselbe VM oder eine andere???
Ausgehend von deinem Verzeichnis-Listing auf macuser.de lautet deine vDISK "Win Hard Disk.vmdk" und nicht "Windows XP corp SP3 Hard Disk.vmdk".
Die "-00001" bis "-000007" und bei dir inzwischen "-000010" sind die Snapshots und dürfen auf keinen Fall gelöscht werden. Du verlierst sonst Daten.

Poste mal bitte ein aktualisiertes Verzeichnislisting aus dem MAC Terminal dieser VM bei abgeschalteter VM, bei dem man auch Zugriffsrechte und Dateigrössen sieht. Am besten postest du die Ausgabe als [Code], dann bleiben hoffentlich Leerzeichen und Tabulatoren an ihrem Platz und vereinfachen die Ansicht.

Dayworker hat geschrieben:Reden wir immer noch über dieselbe VM oder eine andere?...

Entschuldigung. Ich hatte dort aus Übersichtlichkeitsgründen, diesen langen Namen (Windows XP corp SP3 Hard Disk) gekürzt. Es ist noch die gleiche, wobei die lck-Dateien weg waren, nachdem die vm angehalten war.
Hier das aktuelle listing (ls -al):

Und hier die vmx.
Tatsächlich steht die jetzt auf 000010, also dem letzten (misglückten) Snapshot.
Ist also logisch, dass ich die vorhergehenden nicht entfernen darf.

Bedeutet bei dir "angehalten" den VM-Status "Beendet" oder hast du die VM nur nur angehalten also "Suspend"?
Bei einer nur angehaltenen, also nicht komplett runtergefahrenen VM kannst du einige Sachen nicht machen, da ansonsten der vDISK-Inhalt nicht mehr zu seinem Snapshotvorgänger konsistent ist. Mit aktiven Snapshots kannst du daher auch nicht die vDISK vergrössern...
Das es hintenrum manuell trotzdem klappen kann nicht muß und dann ggf in einem fast vollständigen Verlust aller Daten innerhalb der VM enden kann, sei an dieser Steller nur der Vollständigkeit erwähnt.


Falls die VM wirklich nur angehalten und nicht beendet war, steigt das Risiko eines kapitalen Datenverlustes mit vorhandenen immer höher, da nur bei intakter Snapshotkette der Datenbestand konsistent bleibt. In allen anderen Fällen ist Datenverlust vorprogrammiert.

Dayworker hat geschrieben:Bedeutet bei dir "angehalten" den VM-Status "Beendet" oder hast du die VM nur nur angehalten also "Suspend"?...

Sorry, wieder ungenau ausgedrückt, ich meinte natürlich nicht "angehalten", sondern ausgeschaltet.
Also heruntergefahren und aus.

Mir fällt als Lösung nun noch ein:

Die VM im laufenden Betrieb mit disk2vhd als VHD zu sichern und dann neu in Fusion importieren (weiß nicht ob das direkt geht oder ob ich das mit dem VMware Converter machen muss).
Wäre das gangbar und die letzte Möglichkeit?

So, mit 130 GB ist das jedenfalls keine Dauerlösung, dazu ist die Platte zu eng geworden.

Auch wenn du einen Snapshot im abgeschalteten Zustand einer VM anlegst oder löschst, wird irgendwo im Benutzerordner eine Log-Datei erstellt und uns hilft dann vielleicht diese verlinkte Datei weiter. Ich sage mit Absicht verlinkt, da unseren Foren-SW ab einigen Tausend Zeichen das Posting rigoros abschneidet.

Wenn du schon dabei bist, verlinke doch bei der Gelegenheit auch gleich mal das "vmware.log" dieser VM. Dann sehen wir vielleicht auch die Ursache, weshalb sich die Snapshots nicht mehr löschen lassen.

Dayworker hat geschrieben:...wird irgendwo im Benutzerordner eine Log-Datei erstellt...

... auch gleich mal das "vmware.log" dieser VM...

Irgendwo im Benutzerordner? Da finde ich nichts, in diesem Heuhaufen. Ich weiß auch gar nicht wie und wo ich da genau suchen soll. Z.B. mit locate vmware habe ich nichts eindeutiges gefunden.
Und in /var/log/ steht wohl auch nichts von vmware...

Aber in dem VM-Ordner gibt es natürlich die vmware.log Dateien, mehrere. Ich werde daraus nicht schlau.

Die sind hier nun verlinkt:

http://7fw.de/tmp/vmware-log.zip

franc hat geschrieben:

Dayworker hat geschrieben:...Die VM im laufenden Betrieb mit disk2vhd als VHD zu sichern und dann neu in Fusion importieren...

Ist das denn machbar?
Also mittlerweile habe ich damit schon angefangen, aber das dauert ganz schön lange!
Das voraussichtliche Ende sei um 21.15 erst.
Aber wenn das am Ende gar nichts bringt, oder nicht geht, dann kann ich es wieder abbrechen...

Zu Disk2VHD kann ich nichts sagen. Hatte ich bisher noch nie gebraucht und demzufolge auch keinerlei Erfahrung. In jedem Fall dauert die Umwandlung in das andere Format je nach Geschwindigkeit des Host-Datenrägers einige Zeit. Wenn du geschickt warst, hast du als Zielort ein zweite Festplatte oder einen anderen schnell angebundenen Datenträger gewählt. Letzteres kann dann auch ein per Thunderbolt oder USB3.0 angeschlossenes Gerät sein...

Ich kenn Mac OS X nicht gut genug um zu wissen, wo dieses solche Log-Dateien hinschreibt. Notfalls mußt du mal dein Fusion-Manual befragen.


Die Logs werd ich mir gleich mal anschauen.

Dayworker hat geschrieben:...Wenn du geschickt warst, hast du als Zielort ein zweite Festplatte oder einen anderen schnell angebundenen Datenträger gewählt...

Nein, ich war nicht geschickt, sondern habe die vhd auf das NAS im Netzwerk gespeichert. Über USB wäre sicher schneller gewesen, aber meine USB-Buchsen am MacBook sind nicht mehr die zuverlässigsten, gerne mal, wenn ich dran stoße oder daran wackle, unterbrechen die. Natürlich würde das dann bei 99% passieren

Dayworker hat geschrieben:...Die Logs werd ich mir gleich mal anschauen.

Danke!

Wenn das NAS zumindest über Fast-Ethernet oder schnellem WLan angebunden ist, wird das schon deutlich schneller ablaufen, als wenn du eine Kopie auf denselben Datenträger machen würdest.

Dayworker hat geschrieben:Wenn das NAS zumindest über Fast-Ethernet oder schnellem WLAN angebunden ist...

Theoretisch müsste es viel schneller sein, nämlich so um die 20 Mbps, aber praktisch kriege ich oft nur 1 Mbps raus, was lästig genug ist. Filme darüber schauen ist z.B. nicht angenehm. Das liegt aber am NAS, heißt es. Ein einfaches Buffalow Duo LS.

Okay, die Logs habe ich im Schnellgang durchgesehen. Auffällig finde ich nur, daß das dabei der Eintrag usb.generic.autoconnect = "TRUE" gesetzt wurde. Das führt eigentlich dazu, daß sämtliche USB-Geräte des Hostes am Host abgemeldet und an die VM/Gast durchgereicht werden. Das ist ungünstig und dürfte auch für Einträge der Art: "USBGM: Failed to retrieve drive type for volume:(/dev/disk0s2)" sein.

Ich bin aber noch weiter am Durchsuchen...

Dayworker hat geschrieben:...sämtliche USB-Geräte des Hostes am Host abgemeldet und an die VM/Gast durchgereicht werden...

Ich schließe oft mein Telefon an den MacBook an und will dass die USB-Laufwerke darin automatisch immer an das virtuelle Windows angeschlossen werden (wg. der Zukackerei von Mac OS X des Dateisystems mit allerhand Müll).
Vielleicht ist es das.

Editiere mal bitte die VMX-Datei mit einem reinen ASCII-Editor und setze usb.generic.autoconnect = "FALSE". Dann starte die VM erneut, schiebe bei laufender VM einen neuen Snapshot an und fahre die VM wieder vollständig runter.
Dieses neue "vmware.log" wird dann hoffentlich erklären, weshalb du Probleme beim Auflösen der Snapshots hast. In deinen bisherigen Logs springt mir einfach kein Eintrag direkt ins Auge und nach vier kompletten VM-Start/Stop-Zyklen sind die VMware-Logs auch durchrotiert.

Falls dieses Log keine weiteren Erkennisse liefert, folgt Plan B.



[add]
Bezüglich Datenmüll durch Mac OS X hast du nicht unrecht. Selbst auf selbst zusammengestellten Audio-CDs findet man nachher irgendwelche XML-Dateien, die dann unter anderem die gesamte Trackliste und dergleichen enthalten...

Dayworker hat geschrieben:Editiere mal bitte die VMX-Datei mit einem reinen ASCII-Editor und setze usb.generic.autoconnect = "FALSE". Dann starte die VM erneut, schiebe bei laufender VM einen neuen Snapshot an und fahre die VM wieder vollständig runter.
Dieses neue "vmware.log" wird dann hoffentlich erklären, weshalb du Probleme beim Auflösen der Snapshots hast....

OK, ich warte aber noch, bis ich diese vhd fertig habe, um 21.07 sei sie durch, laut disk2vhd-Fenster. Diese Zeit ist recht konstant, also vermute ich, dass sie ungefähr stimmt.

Dayworker hat geschrieben:...Falls dieses Log keine weiteren Erkennisse liefert, folgt Plan B...

Was ist Plan B?

Dayworker hat geschrieben:...Bezüglich Datenmüll durch Mac OS X hast du nicht unrecht. Selbst auf selbst zusammengestellten Audio-CDs findet man nachher irgendwelche XML-Dateien, die dann unter anderem die gesamte Trackliste und dergleichen enthalten...

OS X geht davon aus, dass es auf der ganzen Welt nur OS X Betriebssysteme gibt, scheint mir manchmal
Es gibt da auch keine Möglichkeit, dieses "Herumkacken" abzuschalten, es gibt aber Hilfsmittel, mit denen man den Müll (mehr oder weniger automatisch) entsorgen kann.

Neben disk2vhd hättest du es wahrscheinlich auch schneller über http://drivesnapshot.de erledigen können.
Das ist ein kleiner Imager, der lediglich 3MB Plattenplatz braucht, ab NT4-SP3 über 2000, XP, 2003, Vista, 2008, 7, 2008 R2, PE bis Windows-X64 läuft, dabei von Windows' Volume Snapshot Möglichkeiten Gebrauch machen kann und dazu sogar scriptbar ist. Dessen Eval-Version würde hier schon völlig ausreichen, machmal liegt eine laufzeitlimitierte Version auch einigen Computermagazinen bei. Einzigster mir bekannter Nachteil ist, daß man bisher das Image noch nicht auf einen kleineren Datenträger wieder ausrollen kann. Aber daran arbeitet der Entwickler schon.

Positiv im platztechnischen Sinne ist dessen Einstellmöglichkeit, daß man stupide sämtliche oder nur die benutzten Sektoren ohne Papierkorb sowie Auslagerungs- und Ruhezustandsdatei kopieren lassen kann.



[add]
Eine Anmerkung noch zu disk2vhd. Keine Ahnung ob die aktuelle Version 1.63 davon auch noch betroffen ist, aber bei Platten über 127GB streikt nachher wohl die Einbindung und es ist fraglich, ob VMware damit umgehen bzw ausbügeln kann. Unter Umständen hilft dir hier nicht mal der aktuellste Converter5.1 weiter.

Dayworker hat geschrieben:Neben disk2vhd hättest du es wahrscheinlich auch schneller über drivesnapshot erledigen können...

Ja, kenne und verwende ich auch, aber ich wusste nicht, dass man ein snapshot von drive snapshot in vmware einbinden kann. Geht das?
Das war nämlich meine erste Idee, aber ich habe dann nichts gefunden, wie man das in vmware rein kriegt, daher bin ich dann zu disk2vhd gegangen.

Dayworker hat geschrieben:...Eine Anmerkung noch zu disk2vhd. Keine Ahnung ob die aktuelle Version 1.63 davon auch noch betroffen ist, aber bei Platten über 127GB...

Habe ich auch gelesen, ist auch die aktuelle Version betroffen, aber nicht ich. Ich habe ja "nur" 64 GB, auch wenn das vm-Verzeichnis viel größer ist.

Nachdem ich mich jetzt noch mal bei disk2vhd durchgewühlt habe, scheint das 127GB-Problem wirklich nur die reinen Nutzdaten zu betreffen. Solange die Nutzdaten unterhalb dieses Wertes bleiben, gibt es keinerlei Probleme.

Wenn man Drivesnapshot nutzt, erstellt man nachher eine neue vDISK passender Grösse und fügt diese einer bestehenden Win-VM hinzu. Im nächsten Schritt präsentiert man die Imagedateien über eine normale Netzwerkfreigabe dieser Hilfs-VM und schreibt die Sicherung auf die leere vDISK zurück. Das ist genau dieselbe Vorgehensweise, die man auch zum Convertieren/Umwandeln einer bestehenden OS-Inst also P2V machen kann, wenn einem der VMware-Converter für das Imaging zu lahm ist. Das man die neue VM dann doch noch mit dem Converter "impfen" muß, um zumindest den neuen Plattencontroller samt benötigter Treiber einzuspielen bzw die Boot-Dateien an die neuen HW-Gegebenheiten anzupassen, sei hier auch nur am Rande erwähnt...


Ich bin dennoch an einem neuen "vmware.log" interessiert.

Dayworker hat geschrieben:...Wenn man Drivesnapshot nutzt, erstellt man nachher eine neue vDISK passender Grösse und fügt diese einer bestehenden Win-VM hinzu. Im nächsten Schritt präsentiert man die Imagedateien über eine normale Netzwerkfreigabe dieser Hilfs-VM und schreibt die Sicherung auf die leere vDISK zurück. ...Das man die neue VM dann doch noch mit dem Converter "impfen" muß, um zumindest den neuen Plattencontroller samt benötigter Treiber einzuspielen bzw die Boot-Dateien an die neuen HW-Gegebenheiten anzupassen, sei hier auch nur am Rande erwähnt...

Verstehe ich das richtig: Meiner alten Win-VM füge ich eine weitere virt. Festplatte hinzu, in diese sichere ich die sna-Datei zurück? Das mit dem "Impfen" durch den Converter verstehe ich nicht, ich habe den Converter gar nicht.

Dayworker hat geschrieben:...Ich bin dennoch an einem neuen "vmware.log" interessiert.

Ich habe getan wie vorgeschlagen, also die vmx editiert und dieses usb autoconnect auf false gesetzt, die vm hoch gefahren, einen Snapshot erstellt (Nr. 11 jetzt), runtergefahren, vmware.log kopiert nach:

http://7fw.de/tmp/vmware-log.txt

Übrigens ist der Import der vhd schnarchend langsam. Nach einer Stunde bin ich erst bei ca. 10%. Wenn das so weiter geht, ist es in zehn Stunden fertig, uff.

Also die Hilfs-VM darf nicht dieselbe sein, wie die, von der du ein Image gezogen hast. Der Grund dafür ist die dann doppelte Datenträger-ID. Nicht nur Windows mag sowas überhaupt nicht, da sich diese ID je nach Datum, Windrichtung, Uhrzeit, Laune, Partitionierung, Dateisystem etc immer ändert.
Du fügst daher einer anderen Win-VM eine weitere Platte hinzu und spielst darin das Image zurück. Wenn du BartPE noch als CD/DVD rumliegen oder als ISO hast, könntest du auch fix eine neue XP-VM erstellen, dieser wieder eine vDISK passender Grösse geben, BartPE von CD/ISO booten und dann das Image zurückspielen.

Unter Umständen brauchst du bei disk2vhd den Converter auch überhaupt nicht. Wie bereits gesagt, habe ich damit noch nie arbeiten müssen. Das das Importieren aber solange dauert, scheint dabei erneut ein Image in eine VM vorgenommen zu werden. Ich würde das daher direkt abbrechen, da du eine weitere VM in der Grösse der alten abzüglich überschriebener Daten erstellst.

Jun 09 08:47:23.264: vmx| DUMPER: restoring checkpoint version 8

Ausgehend von dieser Meldung, war die VM nur angehalten und nicht beendet gewesen. Falls du davon per disk2vhd ein Image gezogen hast, wird Windows beim nächsten Start erstmal ein Dateisystemcheck durchlaufen lassen und einige noch im vRAM umherfliegende Sachen werden dir auch fehlen. Mit etwas Glück war im vRAM aber noch nichts wichtiges gespeichert und du hattest keine offenen Dateien in der VM.
Aber zumindest der Checkpoint hat funktioniert. Poste mal bitte wieder als [Code] den Inhalt der VMSD-Datei, darin sollte die gesamte Snapshotkette aufgeführt sein.

/users/f/Documents/Virtual Machines.localized/Windows XP corp SP3 Hard Disk.vmwarevm/Windows XP corp SP3 Hard Disk.vmsd



Ich bin jetzt bei ca. einem Viertel und habe bisher 14 GB in den vmdk-Dateien (bei Nr. 7 derzeit) beieinander. Ich breche das jetzt lieber nicht mehr ab.
So groß wie das alte Verzeichnis (130 GB) kann es also wohl nicht werden.
Eigentlich sollte es aber ja nur ca. 30 GB ergeben, so viel hat ja die disk2vhd-vhd-Datei, vielleicht kann ich hinterher noch komprimieren.
Die VM hatte ja jedenfalls nur gut 30 GB, wie erwähnt.
Wenn das nicht klappt, mache ich es halt noch mal mit BartPE oder der anderen Windows VM, die ich noch habe (die habe ich für eine spezielle Kassensoftware drauf, die ich nicht mit meinem "normalen" Arbeits-Windows vermischen will).