Konsolidieren einer Festplatte / Datastore

[AK18]

Hallo, nachdem ich nur Stunden mit Goolge und Lesen verbracht habe, suche ich hier Hilfe:

Auf einem ESXi 6.7 Host läuft eine Debian-VM inkl. VMTools. Nachdem ich alle Snapshots gelöscht habe inkl. Konsolidieren ist die Festplatte von 100GB auf 768GB auf dem "datastore1" angewachsen. Das Probleme kenne ich schon, gefällt mir aber nicht. Die Festplatte ist VMFS6 mit Thin Provisioning.

Jetzt suche ich einen Weg, die Festplatte wieder klein zubekommen. Probiert habe ich:

esxcli storage vmfs unmap -u 5c2be368-41de4c72-abdd-6805ca0e414d
und
esxcli storage vmfs unmap -l datastore1

aber es passiert nichts. Beide Befehle laufen ca. 4 Sekunden ohne Fehlermeldung.

Ich habe gelesen, dass bei VMFS6 die Konsolidierung automatisch im Hintergrund passiert, aber wann?

[Martin]

Hast Du auch sichergestellt, daß alle freien Bereiche der virtuellen Festplatte innerhalb der VM "getrimt" sind?

[Dayworker]

Genau aus solchen Gründen existiert die Devise: "Nur soviel (vRAM, vCPU, vDISK) wie nötig und nicht wie möglich."
Wenn die vDISK jetzt auf 768GB angewachsen ist, dürfte das auch ihre maximale, spezifierte Grösse sein. Keine Ahnung was du mit deinen Befehlen machst, sieht für mich eher nach zukünftigen Schreib-IOs betreffende Einstellungen aus, aber damit bekommst du die vDISK nicht hostdatenträgermäßig verkleinert. Dafür dient der Befehl:

Code: Alles auswählen

vmkfstools -K /path/to/disk-name.vmdk

Bevor das jedoch die logischen Nullen aus der VMDK entfernen und somit die Luft rauslassen kann, mußt du alle freien Bereiche Ausnullen. Das geht am einfachsten per Hilfs-VM mit Einbinden der VMDKs aus der anderen oder auch per ISO-Start der zu bearbeitenden VM. Letzteres ist mein bevorzugter Weg. Die zu shrinkenden Datenträger könnte man theoretisch auch bei laufendem Linux-System vollschreiben, damit geht aber jedes OS etwas anders um. Hier mein Weg mit ISO unter "gparted" (Debian):

1. sudo mount /dev/sda1 /media (mountet die erste Partition nach /media)
2. cd /media (springt in Media-Verzeichnis und somit in die dort vorher eingehängt erste Partition)
3. sudo dd if=/dev/zero of=0bits bs=20971520 (beschreibt die unter "/media" eingehängte Partition mit 20MiB-Blöcken komplett voll)
4. sudo rm 0bits (löscht die Datei "0bits" wieder)
5. VM beenden (Rechtsklick in den Desktop und "Exit" wählen)

[AK18]

Hast Du auch sichergestellt, daß alle freien Bereiche der virtuellen Festplatte innerhalb der VM "getrimt" sind?

Wie geht das?

[AK18]

@ Dayworker

Das heißt, ich müsste eine etwa 650GB größe Null-Datei in der VM anlegen usw. Das müsste ich auch ohne Linux Kenntnisse laut Deiner Beschreibung hinbekommen...

Aber gibt es keinen einfacheren Weg!?

[Dayworker]

Bei installierten OpenVM-/VMware-Tools gings das früher auch einfach per Rechtsklick auf das System-Icon und Auswahl von Shrinken, seit geraumer Zeit zumindest bei Windows-Gästen nur noch umständlich per Befehl auf der CMD. Daher habe ich mir das manuelle Vorgehen angewöhnt, falls ich überhaupt noch mit Thin-VMs arbeite. Legt man eine VM gleich mit einer vernünftigen, auf den Einsatzzweck geprägten Größe an und reserviert damit sogleich diesen Speicherbereich auf dem Storage in voller Grösse, kommt man kaum in die Verlegenheit eines unerwartet vollgelaufenen Datastore.

[AK18]

Bei installierten OpenVM-/VMware-Tools gings das früher auch einfach per Rechtsklick

Aber bei Linux/Debian geht es überhaupt nicht über die VMTools?

bei Windows-Gästen nur noch umständlich per Befehl auf der CMD.

Mit Windows-VMs hatte ich das Problem auch schon. Verräts Du mir diesen CMD Befehl bitte?

Zurück zu Debian: Nach "VM beenden" (Dein letzter Punkt), was muss dann gemacht werden? vmkfstools -K... ?

[Dayworker]

Irgendwo hier im Forum hat das schon jmd gepostet, aber wo?


[edit]
Lustigerweise liefert mir Google bei der Forum-Suche die passenderen Threads....
Auch wenn folgendes aus der Workstation für Windows-Gäste stammt, sollte es auch unter ESXi funktionieren:

Code: Alles auswählen

"c:\program files\vmware\vmware tools\vmwaretoolboxcmd.exe disk shrink c:\"

Linux sollte ähnlich sein, allerdings würde ich unter Linux nie die VMware-Tools sondern immer deren Open-Source-Pendant sprich das vom jeweiligen Distributor, aus den offiziellen VMware-Sourcen passend für alle ausgelieferten Kernel-Versionen kompilierte Meta-Paket "open-vm-tools" installieren. Letzteres paßt immer zum laufenden Kernel und wird wesentlich häufiger an die ständigen Kerneländerungen angepaßt.

[AK18]

@ Dayworker

Erfolgsmeldung! "vmkfstools -K /path/to/disk-name.vmdk" hat ausgereicht.
Die Lunix-Befehle brauchte ich nicht.

Danach waren auf dem Datastore nur noch 50GB belegt. Nach dem Starten der Debian-VM waren plötzlich 100GB belegt... warum, keine Ahnung? Swapdatei?...

In der VM wird jedoch weiter 768GB (max. HD Größe) genutzt angezeigt, aber das ist dann eigentlich egal.

Vielen Dank. Tolles Forum. Toller Support!

[Dayworker]

Wir wissen zuwenig vom Gast. Wenn du wenigstens ein Verzeichnislisting per "ls -alh" von vor und nach dem VM-Start in Code-Tags posten würdest, hätte man zumindest Anhaltspunkte. Und NEIN, der Datastore-Browser ist dabei keine Hilfe, weil er eine interpretierte Ansicht liefert. Es gilt nach wie vor, daß wenn die Anzeige von DS-Browser und SSH-Zugang gleich ist, man ein ernsthaftes Problem hat.

Eine Swapdatei würde ich mir bei Thin-VMDKs verkneifen. Dadurch bläst man die VMDK vollkommen unnötig auf. Eine zweite Thin-VMDK als Swap-Partition ist wesentlich platzsparender und erweitern läßt sich jede VMDK. Ich weiß ja nicht, wieviel Platz du in diesem DS hast, aber bei deiner VMDK-Grösse, der geringen Auslastung und einer von mir vermuteten fehlenden oder falsch eingestellten Alarmierung in vCenter bzw VCSA oder auch Überwachung per nagios/icinga/check_mk können Thin-VMDKs tödlich sein. Von daher würde ich auch über eine besseres Sizing nachdenken. Bei 250GB Nutzdaten plus 50GB Reserve in der VM hätte ich mit 3 VMDKs netto nur 900GB belegt, mit deinen 768GB dagegen landest du bereits bei 2304GB...