Hallo zusammen,
Ich habe auf meiner VM ein Linux System mit einer virtuellen Disk der maximalen Grösse 220GB; der normale Platzbedarf ist aber nur um die 60GB. Vor einiger Zeit wurde die Disk vom Guest aus aber wegen eines fehlgeleiteten Prozesses auf die vollen 210GB aufgeblasen, und da dies für Backups sehr mühsam ist, möchte ich sie wieder shrinken (die VM hat keine Snapshots, insofern ist das also kein Problem). Bevor ich das aber probiere, woltle ich mögliche Felerquellen abchecken. Ich habe dazu einige Infos Online gefunden, aber eine wesentliche fehlt mir leider: wieviel physischen Platz muss auf dem Host noch frei sein, damit nicht etwa "vmware-vdiskmanager -k" mittendrin abbricht und mir im schlimmsten Fall einen inkonsistenten Zustand zurücklässt? Ja, ich werde die Disk vorher backuppen (noch einmal 3 Stunden...), aber trotzdem möchte ich die Prerequisites kennen; Ich habe auf der physischen Disk eben leider nur noch 12GB frei, die 210Gb maximale Grösse habe ich in etwa an der physischen Disk ausgerichtet. Arbeitet "vmware-vdiskmanager -k" in-place, modifiziert also das bestehende vdk File und kommt somit mit den 12GB Zusatzplatz aus, oder schreibt er alles in ein neues File und braucht im schlimmsten Fall 210GB zusätzlichen Platz? Wenn ja, kann ich dem irgendwie sagen, dass er den Platz von einer anderen Disk nehmen soll?
Auch nicht ganz klar bin ich mir, ob man beim Vorbereiten zuerst den freien Platz der Disk mit Nullen überschreiben soll ("cat /dev/zero > zero.fill;sync;sleep 1;sync;rm -f zero.fill") und dann defragmentieren, oder umgekehrt, oder ob es auf dasselbe herausläuft. Vom vmtoolbox tool zu diesem Zweck unter Linux ist ja nicht sehr viel zu halten, das scheint schon ganze Disks zerstört zu haben, der Umweg über /dev/null scheint stabiler zu sein.
Danke im voraus, Andreas
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Shrinking einer virtuellen Disk: Diskbedarf?
Hallo,
als Erstes müssen wir wissen in welcher Form Deine vmdk vorliegt (in 2GB-Häppchen?).
Beim Shrinken wird auch nur der leere Platz auf der vDisk ausgenullt und dann zusammengefasst, von Hand bringt da auch keine anderen Ergebnisse. Aber Du hast anscheinend GENAU dies schon einmal gemacht und dann abgebrochen und deshalb hat sich die vmdk so aufgeblasen. Ich benutze immer unter KDE die Toolbox, und bisher immer ohne Probleme. Nach dem Shrinken VM runterfahren und unter VM | Settings | Defragment machen und gut is', in der VM ist da nichts weiter nötig.
als Erstes müssen wir wissen in welcher Form Deine vmdk vorliegt (in 2GB-Häppchen?).
Beim Shrinken wird auch nur der leere Platz auf der vDisk ausgenullt und dann zusammengefasst, von Hand bringt da auch keine anderen Ergebnisse. Aber Du hast anscheinend GENAU dies schon einmal gemacht und dann abgebrochen und deshalb hat sich die vmdk so aufgeblasen. Ich benutze immer unter KDE die Toolbox, und bisher immer ohne Probleme. Nach dem Shrinken VM runterfahren und unter VM | Settings | Defragment machen und gut is', in der VM ist da nichts weiter nötig.
Es ist alles in einer grossen Datei (ntfs).
@e-e-e:
Nein, ich habe nichts abgebrochen... Ursprünglich war die Disk so um die 60GB gefüllt und auch physisch war das vdk File in dieser Grössenordnung. Aber ein fehlgeleitreter Prozess im Linux Guest (der nichts mit VMWare zu tun hat) hat die vdk aufgeblasen. Ich habe diese Dateien mittlerweile gelöscht, und jetzt mal vorbereitend mit dem genannten Linux Kommando den freien Platz innerhalb des Guests "benullt" (schöne Wortkreastion .-). Weitere Schritte (Defragmentierung falls das überhaupt notwendig/sinnvoll ist und eigentliches Schrinken) steht noch aus, da wollte ich eben zur Sicherheit vorher nachfragen - weil der Host eben auf derselben physischen Disk nur noch 12GB freien Platz hat. Wenn das Shrinken aber "in-place" erfolgt, dann sollte das reichen - aber vorher fragen statt nachher bereuen ist immer besser.
Aber wenn ich dich richtig verstehe, meinst du, das "vmware_diskmanager -k" sei nicht notwendig weil das schon automatisch geschehe? Ich dachte, eine vmdk wächst nur und shrinkt selbstständig nie, egal was man innerhalb des Guests tut (ausnullen, defraggen), man müsse dann am Ende die Disk unounten und manuell shrinken. Liege ich hier falsch?
@continuum: also 210GB zusätzlich Diskplatz? Mir ist klar, dass man mit 2x210GB Diskplatz am sichersten wäre, aber ich habe im System leider keine 500GB Disk, die müsste ich erst beschaffen. Auf der momentanen Disk hat es das 210GB vmdk File und dann noch 12GB Platz, auf einer anderen Disk kann ich um die 400GB frei machen, aber nirgends 420GB auf einer Disk. Daher auch meine Frage, ob es wirklich 210GB *zusätzlichen* Platz benötigt (deiner Aussage nach ja), und ob man dem Teil irgendwie sagen kann, dass er dies von einer anderen Disk nimmt. Wenn er wirklich nur Nullen zusamenfasst, müsste das - wie beim Defragmentieren - eigentlich nicht nochmals denselben Diskplatz benötigen. Und wenn es diesen Diskplatz wirklich benötigt, müsste man als Rat sagen, dass man die maximale Diskgrösse einer virtuellen Disk nicht grösser als die Hälfte des freien Platzes der physischen Disk wählen sollte, sonst läuft man irgendwann mal genau in dieses Problem rein, oder?
@e-e-e:
Nein, ich habe nichts abgebrochen... Ursprünglich war die Disk so um die 60GB gefüllt und auch physisch war das vdk File in dieser Grössenordnung. Aber ein fehlgeleitreter Prozess im Linux Guest (der nichts mit VMWare zu tun hat) hat die vdk aufgeblasen. Ich habe diese Dateien mittlerweile gelöscht, und jetzt mal vorbereitend mit dem genannten Linux Kommando den freien Platz innerhalb des Guests "benullt" (schöne Wortkreastion .-). Weitere Schritte (Defragmentierung falls das überhaupt notwendig/sinnvoll ist und eigentliches Schrinken) steht noch aus, da wollte ich eben zur Sicherheit vorher nachfragen - weil der Host eben auf derselben physischen Disk nur noch 12GB freien Platz hat. Wenn das Shrinken aber "in-place" erfolgt, dann sollte das reichen - aber vorher fragen statt nachher bereuen ist immer besser.
Aber wenn ich dich richtig verstehe, meinst du, das "vmware_diskmanager -k" sei nicht notwendig weil das schon automatisch geschehe? Ich dachte, eine vmdk wächst nur und shrinkt selbstständig nie, egal was man innerhalb des Guests tut (ausnullen, defraggen), man müsse dann am Ende die Disk unounten und manuell shrinken. Liege ich hier falsch?
@continuum: also 210GB zusätzlich Diskplatz? Mir ist klar, dass man mit 2x210GB Diskplatz am sichersten wäre, aber ich habe im System leider keine 500GB Disk, die müsste ich erst beschaffen. Auf der momentanen Disk hat es das 210GB vmdk File und dann noch 12GB Platz, auf einer anderen Disk kann ich um die 400GB frei machen, aber nirgends 420GB auf einer Disk. Daher auch meine Frage, ob es wirklich 210GB *zusätzlichen* Platz benötigt (deiner Aussage nach ja), und ob man dem Teil irgendwie sagen kann, dass er dies von einer anderen Disk nimmt. Wenn er wirklich nur Nullen zusamenfasst, müsste das - wie beim Defragmentieren - eigentlich nicht nochmals denselben Diskplatz benötigen. Und wenn es diesen Diskplatz wirklich benötigt, müsste man als Rat sagen, dass man die maximale Diskgrösse einer virtuellen Disk nicht grösser als die Hälfte des freien Platzes der physischen Disk wählen sollte, sonst läuft man irgendwann mal genau in dieses Problem rein, oder?
Hallo,
ja.. ja, stimmt, die vmdk shrinkt nie von selbst, aber wandle sie in 2GB-Häppchen, die sind viel besser zu händeln und auch nicht langsamer. Bei meinen vmdk's ist dann nur ein zusätzlicher Speicherplatz von ca. 2GB zum Shrinken nötig, bei einer monolithic-Datei kann das zusätzlich die Gesamtgröße der Datei sein, also 220 GB. Ich shrinke immer aus der VM heraus und hatte noch nie Probleme. Beim Shrinken werden zwar nur Nullen zusammengefasst, aber in eine neue Datei geschrieben und erst nach Beendigung wird die alte Datei gelöscht, ergo am Ende der Aktion sind 2 Dateien mit u.U. 220 GB vorhanden, bei 2 GB-großen Dateien hast Du max. 2x2Gb der gerade bearbeiteten Datei vorliegen und den Vorteil, dass der Deskriptor Deiner vmdk als kleine Extradatei vorliegt und nicht am Anfang Deiner Nutzdaten (vmdk).
ja.. ja, stimmt, die vmdk shrinkt nie von selbst, aber wandle sie in 2GB-Häppchen, die sind viel besser zu händeln und auch nicht langsamer. Bei meinen vmdk's ist dann nur ein zusätzlicher Speicherplatz von ca. 2GB zum Shrinken nötig, bei einer monolithic-Datei kann das zusätzlich die Gesamtgröße der Datei sein, also 220 GB. Ich shrinke immer aus der VM heraus und hatte noch nie Probleme. Beim Shrinken werden zwar nur Nullen zusammengefasst, aber in eine neue Datei geschrieben und erst nach Beendigung wird die alte Datei gelöscht, ergo am Ende der Aktion sind 2 Dateien mit u.U. 220 GB vorhanden, bei 2 GB-großen Dateien hast Du max. 2x2Gb der gerade bearbeiteten Datei vorliegen und den Vorteil, dass der Deskriptor Deiner vmdk als kleine Extradatei vorliegt und nicht am Anfang Deiner Nutzdaten (vmdk).
e-e-e hat geschrieben:Hallo,
ja.. ja, stimmt, die vmdk shrinkt nie von selbst, aber wandle sie in 2GB-Häppchen, die sind viel besser zu händeln und auch nicht langsamer. Bei meinen vmdk's ist dann nur ein zusätzlicher Speicherplatz von ca. 2GB zum Shrinken nötig, bei einer monolithic-Datei kann das zusätzlich die Gesamtgröße der Datei sein, also 220 GB. Ich shrinke immer aus der VM heraus und hatte noch nie Probleme. Beim Shrinken werden zwar nur Nullen zusammengefasst, aber in eine neue Datei geschrieben und erst nach Beendigung wird die alte Datei gelöscht, ergo am Ende der Aktion sind 2 Dateien mit u.U. 220 GB vorhanden, bei 2 GB-großen Dateien hast Du max. 2x2Gb der gerade bearbeiteten Datei vorliegen und den Vorteil, dass der Deskriptor Deiner vmdk als kleine Extradatei vorliegt und nicht am Anfang Deiner Nutzdaten (vmdk).
Hmm das ist ein guter Punkt, danke... die Frage ist jetzt halt nur, wie ich die 210GB Disk in 2GB Häppchen umwandle, wenn die Disk nicht emtsprechend viel Platz hat. Wie gesagt, auf eienr zweiten Disk hätte ich den Platz schon, aber wenn ich dem Tool nicht sagen kann, dass er den Ouput auf eine andere Disk als den Input schreiben soll, nützt mir das ncihts. Ich werde mich wohl trotz allem auf die Suche nach einer 500GB Disk machen müssen.
continuum hat geschrieben:mit vdiskmanager kannst du auf eine zweite Platte klonen - da dann 2Gb schnipsel aussuchen
Ausgezeichnet, das war genau der Missing Link! Und nicht nur das, beim Kovertieren der Disk ("-r <srcdisk> -t 1 <dstdisk>") wurde sie sogar im gleichen Durchgang geschrinkt, so dass die Häppchen zusammen jetzt nur noch die 70GB Platz einnehmen - ein -k Durchgang hat sich also erübrigt. Scheint jetzt auch prima zu Laufen, danke für den Tip.
Ich betätige mich mal als Leichenfledderer und hole diesen alten Thread noch mal raus, denn ich hatte jetzt bei einem Kunden (nur Mäuseschubser und nicht fit an der Konsole) ein ähnliches Problem. (VMWare Tools boten keine Partition zum shrinken an, dürfte aber auch bei virt. Linuxen, die nur eine Konsole haben, funktionieren - also ohne KDE, Gnome u.ä.)
Daraufhin habe ich ihm eine VM Ubuntu-LTS-Desktop eingerichtet und dort hinein die VMWare Tools installiert, funktionierte im Gegensatz zu so manch anderer Distribution, dass in der vmware-toolbox die Partitionen zum shrinken angeboten werden.
Jetzt muss der Kunde nur noch die zu shrinkende VM runterfahren, in die Ubuntu-LTS-Desktop VM die vHDDs der zu shrinkenden VM einbinden, das Ubuntu starten und dank automounter die eingebundenen Partitionen mittels Mausbedienung shrinken. Danach Ubuntu runterfahren und vHDDs wieder entfernen. Zeitaufwand: 1 Minute
Jetzt kann die geshrinkte VM wieder gestartet werden.
Hier schlagen ja öfter mal derartige Fragen auf und ich dachte es wär' hilfreich, kann ja sein, dass ausnahmsweise jemand vorher die SuFu benutzt.
Daraufhin habe ich ihm eine VM Ubuntu-LTS-Desktop eingerichtet und dort hinein die VMWare Tools installiert, funktionierte im Gegensatz zu so manch anderer Distribution, dass in der vmware-toolbox die Partitionen zum shrinken angeboten werden.
Jetzt muss der Kunde nur noch die zu shrinkende VM runterfahren, in die Ubuntu-LTS-Desktop VM die vHDDs der zu shrinkenden VM einbinden, das Ubuntu starten und dank automounter die eingebundenen Partitionen mittels Mausbedienung shrinken. Danach Ubuntu runterfahren und vHDDs wieder entfernen. Zeitaufwand: 1 Minute
Jetzt kann die geshrinkte VM wieder gestartet werden.
Hier schlagen ja öfter mal derartige Fragen auf und ich dachte es wär' hilfreich, kann ja sein, dass ausnahmsweise jemand vorher die SuFu benutzt.
Zurück zu „VMware Workstation und VMware Workstation Pro“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 21 Gäste