1
Thin Provisioned .vmdk größer als eigentlich belegt
Hallo Gemeinde 
,
ich finde hier einen ESXi 7 mit 2 internen lokalen Datastores vor.
Datastore 1 - RAID 1 480 GB SATA SSDs - Hier liegt der Hypervisor drauf
Datastore 2 - RAID 5 3 TB SATA SSDs
Auf Datastore 1 liegen dann noch 4 Thin Provisioned .vmdks mit Windows drauf (also die jeweiligen C: Partionen der VMs) welche im ESXi mehr Speicherplatz belegen als sie in Windows eigentlich an Platz benötigen.
Beispiel:
VM 1 Platte 1 - zugewiesen auf ESXi: 60 GB - Belegter Speicher laut Betriebssystem: 39,1 GB - Größe der .vmdk im Datastore: 55,26 GB
VM 2 Platte 1 - zugewiesen auf ESXi: 175 GB - Belegter Speicher laut Betriebssystem: 110,5 GB - Größe der .vmdk im Datastore: 168,72 GB
VM 3 Platte 1 - zugewiesen auf ESXi: 100 GB - Belegter Speicher laut Betriebssystem: 78,1 GB - Größe der .vmdk im Datastore: 80,96 GB
VM 4 Platte 1 - zugewiesen auf ESXi: 100 GB - Belegter Speicher laut Betriebssystem: 47,7 GB - Größe der .vmdk im Datastore: 51,79 GB
Heißt Zusammengefasst:
Kapaztität Datastore 1: 439,50 GB
Belegt laut ESXi: 385,95 GB
Belegt laut 4x Windows: 275,40 GB
Insgesamt werden somit roundabout 80 GB (nach Abzug der 24 GB swap-files und der restlichen zur VM gehörenden Files) zuviel belegt.
Ich gehe davon aus dass die Platten wohl mal tatsächlich soviel Speicher benötigt haben wie die .vmdk nun groß ist.
Aber müsste nicht eigentlich die .vmdk dann auch wieder schrumpfen wenn Speicher verfügbar wird?
(Da sie das nicht tun ist es schon passiert dass eine VM ausgefallen ist weil kurzfristig kein Speicher mehr verfügbar war.)
Wie bekomme ich den tatsächlich freien Speicher wieder verfügbar sodass der ESXi und auch ich glücklich werden?
(Ich weiß dass es diese paar GB eigentlich recht banal sind und Speicher ja auch günstig ist, aber mir gehts da auch ein wenig um das Prinzip und auch mein Background-Wissen hierzu erweitern zu können)
Zweite Frage:
Sollte ich die Platten aufs RAID 5 auslagern sodass wirklich nur noch der Hypervisor auf dem RAID 1 liegt?
Warum auch immer liegt das Working Directory (Ordner mit logs und ConfigFiles) von VM 1 auf Datastore 2, die Working Directories von 2,3 und 4 auf Datastore 1.
Die weiteren zugewiesenen Festplatten der obigen VMs liegen allesamt auf Datastore 2, nur die Windows OS-Platten auf Datastore 1.
Das würde ich dann auch gerne auf Best Practice bringen oder optimieren.
Wie wäre hier das Optimum?
Vielen Dank für eure Hilfe.
,ich finde hier einen ESXi 7 mit 2 internen lokalen Datastores vor.
Datastore 1 - RAID 1 480 GB SATA SSDs - Hier liegt der Hypervisor drauf
Datastore 2 - RAID 5 3 TB SATA SSDs
Auf Datastore 1 liegen dann noch 4 Thin Provisioned .vmdks mit Windows drauf (also die jeweiligen C: Partionen der VMs) welche im ESXi mehr Speicherplatz belegen als sie in Windows eigentlich an Platz benötigen.
Beispiel:
VM 1 Platte 1 - zugewiesen auf ESXi: 60 GB - Belegter Speicher laut Betriebssystem: 39,1 GB - Größe der .vmdk im Datastore: 55,26 GB
VM 2 Platte 1 - zugewiesen auf ESXi: 175 GB - Belegter Speicher laut Betriebssystem: 110,5 GB - Größe der .vmdk im Datastore: 168,72 GB
VM 3 Platte 1 - zugewiesen auf ESXi: 100 GB - Belegter Speicher laut Betriebssystem: 78,1 GB - Größe der .vmdk im Datastore: 80,96 GB
VM 4 Platte 1 - zugewiesen auf ESXi: 100 GB - Belegter Speicher laut Betriebssystem: 47,7 GB - Größe der .vmdk im Datastore: 51,79 GB
Heißt Zusammengefasst:
Kapaztität Datastore 1: 439,50 GB
Belegt laut ESXi: 385,95 GB
Belegt laut 4x Windows: 275,40 GB
Insgesamt werden somit roundabout 80 GB (nach Abzug der 24 GB swap-files und der restlichen zur VM gehörenden Files) zuviel belegt.
Ich gehe davon aus dass die Platten wohl mal tatsächlich soviel Speicher benötigt haben wie die .vmdk nun groß ist.
Aber müsste nicht eigentlich die .vmdk dann auch wieder schrumpfen wenn Speicher verfügbar wird?
(Da sie das nicht tun ist es schon passiert dass eine VM ausgefallen ist weil kurzfristig kein Speicher mehr verfügbar war.)
Wie bekomme ich den tatsächlich freien Speicher wieder verfügbar sodass der ESXi und auch ich glücklich werden?
(Ich weiß dass es diese paar GB eigentlich recht banal sind und Speicher ja auch günstig ist, aber mir gehts da auch ein wenig um das Prinzip und auch mein Background-Wissen hierzu erweitern zu können)
Zweite Frage:
Sollte ich die Platten aufs RAID 5 auslagern sodass wirklich nur noch der Hypervisor auf dem RAID 1 liegt?
Warum auch immer liegt das Working Directory (Ordner mit logs und ConfigFiles) von VM 1 auf Datastore 2, die Working Directories von 2,3 und 4 auf Datastore 1.
Die weiteren zugewiesenen Festplatten der obigen VMs liegen allesamt auf Datastore 2, nur die Windows OS-Platten auf Datastore 1.
Das würde ich dann auch gerne auf Best Practice bringen oder optimieren.
Wie wäre hier das Optimum?
Vielen Dank für eure Hilfe.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 670656
Url: https://administrator.de/forum/thin-provisioned-vmdk-groesser-als-eigentlich-belegt-670656.html
Ausgedruckt am: 12.01.2025 um 15:01 Uhr
1 Kommentar
Moin,
nein, das ist kein Automatismus, sondern muss manuell angestoßen werden. Grob vereinfacht hat das damit zu tun, dass eine komplette Datenreorganisation stattfinden muss. Der "freie" Speicherplatz muss am Ende der "Festplatte" = VMDK sein, dann kann die Datei gekürzt werden. Die in der VMDK enthaltenen Betriebssysteme schreiben zwar in der Regle erst einmal fortlaufend, wenn aber bspw. die ältesten Dateien gelöscht werden, dann ist der freie Speicher im Anfangsbereich. Und so im Laufe der Zeit überall ein paar nicht belegte Häppchen. Außerdem werden gelöschte Dateien meist nicht wirklich gelöscht, sondern nur zum Löschen markiert, so dass ein Tool von außen nicht wissen kann, was in der VMDK frei ist (nur das dort laufende Betriebssystem).
Es gibt verschiedene Vorgehensweise: innerhalb der VM alle Daten reorganisieren oder unter Windows mit SDELETE arbeiten. Anschließend dann über die vmdktools den Shrink Vorgang anstoßen. Benötigt aber freien Speicherplatz.
Details: www.winteach.de/vmware-vsphere/vmware-esxi-vmdk-von-thick-zu-thin-mit-vmkfstools-ohne-vcenter/.
Gruß
DivideByZero
Aber müsste nicht eigentlich die .vmdk dann auch wieder schrumpfen wenn Speicher verfügbar wird?
(Da sie das nicht tun ist es schon passiert dass eine VM ausgefallen ist weil kurzfristig kein Speicher mehr verfügbar war.)
(Da sie das nicht tun ist es schon passiert dass eine VM ausgefallen ist weil kurzfristig kein Speicher mehr verfügbar war.)
nein, das ist kein Automatismus, sondern muss manuell angestoßen werden. Grob vereinfacht hat das damit zu tun, dass eine komplette Datenreorganisation stattfinden muss. Der "freie" Speicherplatz muss am Ende der "Festplatte" = VMDK sein, dann kann die Datei gekürzt werden. Die in der VMDK enthaltenen Betriebssysteme schreiben zwar in der Regle erst einmal fortlaufend, wenn aber bspw. die ältesten Dateien gelöscht werden, dann ist der freie Speicher im Anfangsbereich. Und so im Laufe der Zeit überall ein paar nicht belegte Häppchen. Außerdem werden gelöschte Dateien meist nicht wirklich gelöscht, sondern nur zum Löschen markiert, so dass ein Tool von außen nicht wissen kann, was in der VMDK frei ist (nur das dort laufende Betriebssystem).
Es gibt verschiedene Vorgehensweise: innerhalb der VM alle Daten reorganisieren oder unter Windows mit SDELETE arbeiten. Anschließend dann über die vmdktools den Shrink Vorgang anstoßen. Benötigt aber freien Speicherplatz.
Details: www.winteach.de/vmware-vsphere/vmware-esxi-vmdk-von-thick-zu-thin-mit-vmkfstools-ohne-vcenter/.
Zweite Frage:
Sollte ich die Platten aufs RAID 5 auslagern sodass wirklich nur noch der Hypervisor auf dem RAID 1 liegt?
Jedenfalls so organisieren, dass auf dem Host noch Platz ist. Das auf Datastore 1 ist nun wirklich zu knapp und wird das auch bleiben, da die VMDKs, selbst wenn Du sie verkleinerst, ja wieder anwachsen werden.Sollte ich die Platten aufs RAID 5 auslagern sodass wirklich nur noch der Hypervisor auf dem RAID 1 liegt?
Gruß
DivideByZero
1
