VMware VMDK verkleinern: vCenter Converter, vdiskmanager, vmkfstools


    Tags: , ,

    VMDK-Größe im vSphere ClientEinen virtuellen Datenträger zu verkleinern ist keine triviale Aufgabe, weil er nämlich ein Dateisystem enthält, das vom Gast-OS in der VM verwaltet wird. Dieses kann man durch eine solche Operation beschädigen. Wegen der damit verbundenen Risiken hat VMware diese Option aus dem vSphere Client entfernt und bietet sie auch nicht in den VM-Einstellungen der Workstation. Daher muss man zu diesem Zweck andere Wege beschreiten.

    Auf den ersten Blick mag es nur die Anforderung geben, ein virtuelles Laufwerk zu schrumpfen, wenn man es mittels Thick Provisioning auf eine fixe Größe festgelegt hat. Diese statische Zuordnung kann sich nachträglich als zu großzügig erweisen, so dass man den ungenutzten Speicher zurückgewinnen möchte.

    Speicherverschwendung auch bei Thin Provisioning

    Bei dynamisch wachsenden VMDKs stellt sich dieses Problem aber genauso. Die automatische Ausdehnung führt nämlich mit der Zeit dazu, dass aus der Sicht des Hypervisors im virtuellen Datenträger mehr Platz verbraucht wurde, als der Gast tatsächlich beansprucht. Daher vergrößert er die VMDK laufend weiter, obwohl das Betriebssystem in der VM noch ausreichende Kapazitäten vorfindet.

    Diese Diskrepanz entsteht dadurch, dass die VM bei Bedarf zwar sofort zusätzlichen Speicherplatz erhält, aber der Hypervisor in der Regel nicht bemerkt, wenn im Gastsystem Dateien gelöscht werden. Dies liegt daran, dass die meisten Dateisysteme nur die Einträge aus ihren Metadaten entfernen, aber die weiterhin von gelöschten Dateien belegten Blöcke nicht mit Nullen überschreiben.

    Ungenutzten Speicher messen

    Die Differenz zwischen Innen- und Außenperspektive kann man relativ einfach ermitteln, indem man den freien Plattenspeicher, den man im Gastsystem vorfindet, mit dem Wert vergleicht, den VMware berichtet. Dieser lässt sich unter anderem im vSphere Client und in der VMware Workstation unter den Einstellungen der VM einsehen.

    Auf der Konsole von ESXi bzw. über SSH lässt sich die Zahl der belegten Blöcke in einer VMDK mit stat anzeigen.

    Alternativ kann man auf der ESXi-Konsole diese Informationen mit Hilfe von stat abrufen, wobei man die angezeigte Zahl der 512 Bytes großen Blöcke selbst in GB umrechnen muss. Wer PowerShell bevorzugt, kann alternativ dafür PowerCLI nutzen, vorausgesetzt eine VM läuft und die VMware Tools sind installiert. Details finden sich in diesem Blog-Eintrag.

    Platzverbrauch reduzieren mit Storage vMotion

    Bei der Verkleinerung von VMDKs holt man mit Tools nach, was das Dateisystem unterlassen hat und überschreibt ungenutzte Blöcke mit Nullen. In Windows-Gästen eignet sich dafür das kostenlose sdelete von Sysinternals. Anschließend verschiebt man die VM mit Hilfe von Storage vMotion auf einen anderen Datastore. Im Zuge dessen werden freie Blöcke nicht in die neuen VMDKs übernommen.

    Dieses Vorgehen hat jedoch zwei Einschränkungen. Zum einen setzt es mindestens vSphere Enterprise voraus, so dass es für kleinere Editionen, die Workstation oder ESXi Free nicht funktioniert. Zum anderen klappt diese Bereinigung nur, wenn VMFS auf dem Zielmedium mit einer anderen Blockgröße konfiguriert wurde. Dies startet einen älteren (und langsameren) Mechanismus für den Dateitransfer, der diese Fähigkeit besitzt. Daher wird man hier möglicherweise um VMFS-Konvertierungen nicht herumkommen. Der Vorteil dieser Methode ist aber, dass sie eine Hot Migration unterstützt und die VM nicht heruntergefahren werden muss.

    Größe reduzieren mit vCenter Converter

    Eine relativ elegante Lösung bietet vCenter Converter, der ebenfalls eine VMDK verkleinert, indem er sie über V2V in einen neuen virtuellen Datenträger schreibt. Der Trick besteht hier darin, dass man die Konvertierung nicht auf Blockebene, sondern auf über das Dateisystem ausführt. Auf diese Weise gelangen nur die tatsächlich vorhandenen Files in die neue VM, und von gelöschten Dateien belegte Blöcke bleiben unberücksichtigt. Voraussetzung dafür ist natürlich, dass der Converter das betreffende Dateisystem lesen kann. Er unterstützt dabei FAT, FAT32, NTFS, ext2, ext3, ext4 und ReiserFS.

    Der Converter erlaubt sowohl die Bearbeitung lokaler VMDKs, die von der Workstation genutzt werden, als auch den Zugriff auf Datastores von Servern unter ESX(i). Dabei kann man die virtuellen Datenträger auch zwischen den Systemen transferieren. Nachdem bei diesem Vorgang die VM neu gestartet werden muss, handelt es sich um eine Cold Migration.

    Versteckte Option für Konvertieren auf Dateiebene

    Der entscheidende Schritt erfolgt hier, wenn der Wizard zum Konvertieren von VMs den Punkt Optionen erreicht. Dort klickt man im Fenster Aktuelle Einstellungen auf den Link Bearbeiten neben dem Eintrag Zu kopierende Daten. Im Pull-Down-Menü Datenkopiertyp entscheidet man sich für Zu kopierende Volumes auswählen (wenn der Eintrag nicht vorhanden ist, dann kennt der Converter das Dateisystem nicht).

    Die Option für das Konvertieren auf Dateiebene ist im vCenter Converter nur schwer zu finden.

    Danach findet sich direkt rechts neben diesem Eintrag der Link Erweitert. Folgt man ihm, dann kommt man auf eine Seite mit 2 Registerkarten. Dort wechselt man zum Reiter Ziellayout und wählt die neue Größe für die VMDK aus. Dies bewirkt ein Umschalten auf den Dateisystem-Modus.

    VMDK unter ESXi mit vmkfstools verkleinern

    Unter ESXi gibt es eine weitere Möglichkeit, eine VMDK durch Kopieren in eine neue Datei zu verkleinern. Zuständig ist dafür das Kommandozeilenprogramm vmkfstools, dem man durch den Eintrag der neuen Größe in die Descriptor-Datei nachhelfen muss (also in die Datei mit der Endung .vmdk, die eigentliche virtuelle Festplatte heißt dann z.B. win8-flat.vmdk). Eine gute Beschreibung für dieses Vorgehen findet sich auf ProfessionalVMware.

    Der Aufruf mit den Schaltern -X und --force konnte in älteren Versionen des Hypervisors eine VMDK beliebig verkleinern, und zwar ohne Rücksicht auf den Inhalt. Unter ESXi 5.x eignet sich dieser Befehl nur mehr, um virtuelle Datenträger zu vergrößern.

    Original-VMDK schrumpfen

    Als weitere Option für das Verkleinern von virtuellen Datenträgern bleibt noch die direkte Bearbeitung der VMDK. Sie ist nicht nur am aufwändigsten, sondern auch am riskantesten. Daher ist es ratsam, dass man die VMDK vorher sichert und zudem alle Snapshots löscht bzw. integriert. Die VM sollte zudem ausgeschaltet sein.

    Wenn man den virtuellen Datenträger von außen verändert, muss man sicherstellen, dass man das Dateisystem des Gastes nicht beschädigt. Zu diesem Zweck schrumpft man die in der VMDK enthaltene/n Partion/en, und zwar mit den Mitteln des Gast­betriebs­systems (im Fall von Windows mit der Datenträgerverwaltung oder mit diskpart). Der dann verbleibende nicht partitionierte Bereich gibt die Größe vor, um die sich die VMDK maximal reduzieren lässt.

    Das eigentliche Schrumpfen des virtuellen Datenträgers übernimmt dann ein Kommandozeilen-Tool, nachdem diese Funktion aus den GUIs entfernt wurde. Die VMware Workstation installiert ein Programm namens vmware-vdiskmanager.exe, das für derartige Aufgaben zuständig ist (fixe Disks lassen sich damit allerdings nicht verändern). Dazu verwendet man den Schalter -k, also zum Beispiel

    vmware-vdiskmanager -k win8-virt.vmdk

    Dieser Aufruf gibt den gesamten Platz frei, der nicht von Volumes des Gastsystems belegt wurde.

    3 Kommentare

    Bild von Thorsten Albrecht
    Thorsten Albrecht sagt:
    29. Januar 2014 - 19:47

    Danke für den Tip, eine VMDK mittels des VMware Converters zu verkleinern.

    In der Version 5.5.0, die ich soeben dafür benutzt habe, war es für mich allerdings nicht notwendig, die von Dir beschriebene "Versteckte Option für Konvertieren auf Dateiebene" zu benutzen. Unter "Zu kopierende Volumes auswählen" bin ich im Basis-Mode geblieben und habe "Größe beibehalten" eingegeben. (Meine Quellpartition hatte ich bereits auf die gewünschte Zielgröße verkleinert.) Ein Umschalten von "Basis" auf "Erweitert" mit anschließender Wahl einer bestimmten Partitionsgröße (bzw. Mindestgröße) und das dadurch implizit erwirkte Umschalten des Kopiermodus von Block- auf Dateiebene war nicht notwendig.

    Thorsten

    Bild von Wolfgang Sommergut
    29. Januar 2014 - 22:49

    Danke für den Hinweis, dann hat sich hier einiges geändert. Mein Tipp beruht noch auf der Version 5.0 oder 5.1.

    Bild von Marcel
    Marcel sagt:
    18. August 2014 - 13:40

    Hallo,
    danke für den Tipp. Normalerweise ist ja immer was... aber hier lief alles am wie am Schnürchen !