mac | How to shrink a virtual linux harddisk in VMware Fusion
December 10th, 2009 at 18:41
Der regelmäßige Besucher wird es wissen – ein Thema welches hier in regelmäßigen Abständen wieder hochkommt ist VMware Fusion.
Im Regelfall ging es in der Vergangenheit eher darum wie man Mac OS X unter Mac OS X in Betrieb nehmen kann – diesbezüglich verweise ich hier nochmal auf die Artikel
Ein Aspekt den ich in den meisten virtuellen Maschinen einsetzte sind wachsende Festplatten – dies hat Vor- und Nachteile. Da Performance für mich meist nicht das Killerargument ist ziehe ich eben wachsende Festplatten vor … die über den Daumen gepeilt in der Theorie nur so viel Platz einnehmen sollten wie das virtuelle OS derzeit auch wirklich belegt.
In der Praxis zeigt sich jedoch das speziell virtuelle Linux Installationen bei mir bei Bedarf zwar ihre Festplatte im Rahmen der definierten Maximalgröße anpassen – dieser Vorgang aber mehr oder weniger nur in die Wachstumsrichtung wirklich reibungslos läuft – zumindest wenn man wie ich ein Linux ohne X und damit auch ohne VMware Tools betreibt 
Daher im folgenden mal ein Ansatz wie man eine virtuelle Linux Festplatte unter Mac OS X und VMware Fusion wieder gesund schrumpfen kann.
Ausgangsszenario
- Mac OS X 10.6.x
- VMware fusion 2.x
- Ubuntu 8.04 TLS
- lt. Ubuntu sind knapp 13 GB der max 64 GB großen virtuellen HD belegt
- lt. Mac OS X ist die virtuelle Maschine 51 GB groß
- Snapshots sind keine mehr enthalten
Relevant ist wohl die Info dass in der Vergangenheit diverse Snapshots angelegt wurden – diese teilweise wieder entfernt wurden und dies sicherlich zur gesamt Ausgangslage beitragen hat.
Shrink Ansätze in VMware Fusion
Einstellungen der virtuellen Festplatte
VMware bietet innerhalb den Harddisk-Einstellungen einer virtuellen Maschine die Möglichkeit diese mittels der Funktion Clean Up Disk zu bereinigen.
Vorsicht das Bild entspricht nicht der besprochenen virtuellen Maschine
Laut VMware funktioniert der Spaß allgemein gesehen dann ganz einfach
Sollte ein Disk Cleanup Sinn ergeben wird die Option angeboten – ansonsten ist diese Funktion ggf ausgegraut und mit dem Hinweis versehen das die anwendung derzeit nicht notwendig ist.
Das klingt schön – brachte mir aber bei der obig erwähnten virtuellen Maschine – ohne VMware Tools (und ohne X) relativ wenig da die Funktion zwar anstoßbar war – aber die Fusion Diagnose zuvor schon stets klar ausdrückte
Macht hier keinen Sinn
und endete auch leider nicht erfolgreich.
Defragmentierung
Soweit so gut – daher wurde es Zeit sich nach alternativen Ansätzen umzusehen. Mein erster Gedanke ging in Richtung Defragmentierung – wenngleich dies in derart heftiger form eigentlich auf der virtuellen ext3 Platte nicht hätte passieren sollen.
Anbei noch ein Support Dokument von VMware mit Gedanken zum Thema Defrag.
Ich hatte das Thema an dieser Stelle erstmal beiseite gelegt und wollte mir noch die sonstigen VMware Fusion Boardmittel ansehn was beim Thema
vmware-vdiskmanager
Dieses Tool wird mit VMware Fusion mitinstalliert und erlaubt es dem geneigten Terminaluser auch aus der Kommandozeile (irgendwie liebe ich dieses Wort) heraus Änderungen an den virtuellen Festplatten durchzuführen.
Wer diesbezüglich Interesse hat sollte sich mal unter
/Library/Application Support/VMware Fusion/
VMware selbst dokumentiert einige Beispiele u.a. hier – wobei es fast nahe liegt sich einfach mal alle Optionen direkt im Terminal anzeigen zu lassen.
Obwohl die Idee naheliegend ist dass die im ersten Punkt gezeigte Clean Up Disk Funktion im Hintergrund genau auf vmware-vdiskmanager zurückgreift wollte ich auch diese Varianze mal durchspielen.
Daher habe ich sowohl ein Defrag (-d), wie auch ein Shrink (-k) und ein abschließend ein Check (-R) durchgeführt – jedoch war die virtuelle Festplatte nach diesen Operationen noch exakt so groß wie zuvor. Während dem reinen Defrag war diese interessanterweise sogar zeitweise über der definierten 64 GB Marke wenn man den Angaben des Finders ueberhaupt trauen will
Die finale Lösung
Wie so oft liegt die Lösung in einer Mischung der Ideen … und die Idee kam im IRC Channel #vmware auf nachdem hin und her diskutiert wurde.
You need to zero out the unused disk space first before performing the shrink
Eh voila – da liegt der Hase begraben. Also fix ein innerhalb der virtuellen Maschine auf dd zurückgreifen
dd if=/dev/zero of=/empty_file; rm /empty_file
und darauf anschließend dann unter Mac OS X erneut ein Shrink mittels vmware-vdiskmanager anstoßen. Je nach Umfang der VM dauert der Vorgang dann doch recht lange ….. am Ende kam ich aber auf die erhoffte Reduktion von ursprünglich 51 GB auf ca 14 GB runter – was in etwa meiner vorstellung entsprach.
Fazit
Interessant wäre natürlich wie unterschiedlich die Gesamtsituation inzwischen mit VMware Fusion 3 – letzlich kommt na aber auch mit Fusion 2 und etwas Terminal-Hackerei gut zum Ziel – wenngleich es mich wundert das man relativ wenig Informationen zu dem Problem findet – bzw die Foreneinträge meist 0815 Geschwaffel bieten – die aber letzlich leider oft nicht 100% zielführend sind.
Fragen über Fragen
Kennt ihr das Grundproblem ?
Wenn ja wie geht ihr damit um ?
Und seht ihr ähnliche Effekte bei Virtualbox oder Parallels ?
Tags: dd, empty_file, linux, shrink, vmware, vmware fusion, vmware-vdiskmanager, zero
December 10th, 2009 at 20:37
Cooles Thema! Wirklich Nische, aber absolut klasse auf den Punkt. Danke!
Hast Du schonmal einen Blick auf KDE 4.x angesehen (k.A., was aktuell ist; ich hatte, was jetzt gerade aktuell mit openSUSE 11.2 kam)? Ich fand das doch recht schick.
December 10th, 2009 at 23:31
[...] Dieser Eintrag wurde auf Twitter von I want a Mac!, fidel erwähnt. fidel sagte: post:: mac | How to shrink a virtual linux harddisk in VMware Fusion http://bit.ly/7UnfGN [...]
December 11th, 2009 at 13:42
@fellowweb
ich seh den aktuellen KDE Stand recht regelmäßig – im Kern jede Woche mind einmal
Mir geht es ähnlich wie dir ….. KDE 4 ist nicht unattraktiv – bietet ne Konfigurationsvielfalt die teilweise fast zu weit (Fenstereigenschaften und Effekte ….) geht – aber alles in allem ist das ne tolle Sache wenn man nen grafiklastingen WindowManager sucht.
Wie geht’s dir dabei ? Und was war davor die letzte Version die du kanntest ?
Weil wenn KDE 3 zuvor der letzte Stand bei dir war dann wirkt KDE 4 sicherlich wie ne neue – und vor allem recht bunte Welt oder?
Gruss
fidel
December 11th, 2009 at 14:55
@fidel:
Im Detail konnte ich es mir noch nicht ansehen. Bisher habe ich primär mit GNOME unter Ubuntu Erfahrungen gesammelt. Als jetzt openSUSE 11.2 rauskam und es hieß, dass damit die erste richtig brauchbare Version von KDE 4.x kommt, konnte ich es mir jedoch nicht verkneifen, das Live CD-ISO mal in VMware Fusion zu starten. Schon chique.
Davor hatte ich, glaub ich, KDE zum letzten Mal in der Version 3 gesehen. Es scheint mir schon ein gewaltiger Sprung zu sein. Mich würde freuen, wenn ein paar helle Köpfe mal einen wirklich innovativen Fenstermanager entwickeln würden. – Einige Pakete wie AWN, Docky oder GNOME Do haben mir schon ganz gut gefallen (z.B. die Wetter- oder Netzwerk-Widgets im Dock).
Nutzt Du KDE ausschließlich/schwerpunktmäßig oder auch GNOME? Setzt Du Linux für irgendetwas “produktiv” ein? Oder mehr zum “Frickeln”/Erfahrung sammeln?
December 11th, 2009 at 15:05
Ich möchte ja nicht klugscheissen, aber müsste es nicht
dd if=/dev/zero of=/empty_file; rm /empty_file
heissen?
December 11th, 2009 at 15:07
@fellowweb:
Witzig das man jetzt KDE wieder über Suse entdeckt- nachdem der Großteil der Distris bei Gnome angekommen ist – was die Defaultwahl angeht. Der optische Sprung von KDE3 auf KDE 4 war definitiv ein großer
Ich nutzte KDE eigentlich garnicht – aber im Umfeld verwenden das einige – teilweise seit > 10 Jahren und über diesen Weg habe ich immer mal wieder Kontakt dazu – weniger als Anwender / aber es reicht um neue UI-Entwicklungen im Ansatz im blick zu behalten.
Linux verwende ich selbst privat nur sehr selten und wenn dann als Bastelwiese – at work kommen diverse Linux-Installationen zum Einsatz, jedoch sind diese ohne grafische Oberfläche o. Ä. …. da einfach unnötig für die Zwecke.
Gruss
fidel
December 11th, 2009 at 15:12
@Volker
klugscheissen rockt in dem Fall – danke für den Korrektur-Hinweis.
Irgendwann werd ich mich dahingehend anpassen dass ich hier ein Ticket System installiere – NUR für meine Typos
Gruss und guten Start ins Wochenende.
fidel
January 16th, 2010 at 10:04
Hallöle.
1. Speicherplatzbedarf beim Verkleinern
Das der Speicherplatzbedarf für die virtuelle Festaplatte zeitweise über den 64 GB lag ist einfach zu erklären. Das Werkzeug von VMWare verkleinert die virtuelle Festplatte indem es einfach die (benutzten) Sektoren von der aktuellen Datei in eine neue Datei kopiert. Danach wird die alte Datei entfernt und die Zwischendatei zur Originaldatei umbenannt. Ist die virtuelle Festplatte in 2GB Stücke aufgeteilt (was ich ausschließlich auch tue) dann läuft die Verkleinerung separat pro 2GB Datei. Wenn Du eine virtuelle Festplatte hast die nicht in 2 GB Stücke unterteilt ist, dann benötigst Du beim Verkleinern ausreichen freien Speicherplatz. Im ungünstigsten Fall für soviel, wie die größe der virtuellen Platte ist.
2. Ausfüllen des unbenutzen Dateisystemplatzes mit Null-Bytes
Wenn eine Datei im Dateisystem gelöscht wird, dann wird gemeinhin lediglich die Verwaltungsinformation (i-node) als wieder frei markiert. Die wirklichen Inhalte der Datei verbleibt weiterhin auf der Festplatte. Das Werkzeug zum Verkleinern der virtuellen Festplatte kann aber nicht erkennen ob ein Sektor in der Festplatte zu einer gelöschten Datei gehört oder auch nicht. Im Sektor sind einfach Daten enthalten (die zu einer eventuellen früheren Datei gehören). Mit dem DD Befehl sorgst Du nun dafür, dass alle freien Sektoren die in dem mount-point (ich mache das dann auch pro mount-point mit einem kleinen Script) zur Verfügung stehen auch zu der neuen Datei empty_file gehören werden, jedoch komplett mit Null-Bytes gefüllt. Das Werkzeug zum Verkleinern muss diese Sektoren wohl speziell behandeln. Damit kommt dann eine echte Verkleinerung zu Stande.
Gruss
Andi
January 16th, 2010 at 10:41
@Andi
bzgl 2:
wenn ich es richtig verstehe – hätten die Onboard-Mittel von VMware Fusion die verkleinerung auch realisiert hätte ich ein X sowie die VMware Tools installiert.
Im Falle dieser VM handelte es sich jedoch nur um nen kleinen Server – der auf beides verzichtete …. weshalb ich halt eine alternative Lösung benötigte auf die schnelle
Merci für die ausführungen
Gruss
fidel
January 16th, 2010 at 10:48
Ja genau.
Die VMWare Tools in der VM machen das eben mit einer hübschen Oberfläche.
Deswegen dauert das Verkleinert mit den Tools auch so ewig. Weil eben auch die freien Sektoren mit NULL-Bytes aufgefüllt werden. Wird auch nur mit wasser gekocht.
Ich habe viele Debian Installationen in VM und kein X installiert und mache das immer so.
January 16th, 2010 at 10:53
@Andi
klar …. alles Wasser – meist gleiche Temperatur
Ich dachte nur ich halte das mal fest – vor allem da ich anfangs selbst nicht an X & die VMware Tools dachte (die Sache mit dem Brett vor dem Kopf lässt grüßen)