datastore 1 freier Speicherplatz schrumpf ungeklärt

[Zombiehase]

Hallo zusammen,

wir haben bei uns in der Firma einen kostenlosen ESXI 5.5 Server im Einsatz. Darauf laufen einige virtuelle Maschinen.

Nun zu unserem Problem:
Unser Datastore 1 freier Speicher schrumpft ungeklärt. Wir haben die letzten Wochen keine Snapshots und keine weiteren virtuellen Maschinenplatten dort erstellt.

Woran kann das liegen und wie kann man das stoppen?

Ich hoffe es kann mir jemand helfen.

Gruß,
Alina

[rprengel]

Unser Datastore 1 freier Speicher schrumpft ungeklärt.

Hallo,

du -h -d 1
auf dem ESX-Host ausführen wobei du schon im Ordner des Speichers sein solltets der schrumpft.
Das dann mehrfach am Tag und du siehst wo Platz verbraucht wird.

Gerne genommen sind
- logfiles
- jemand schreibt "quer" auf auf das System weil er es z.B. als Fileserver nutzt.
- dynamisch wachsende Festplatten in einer VM die sehr grosszügig angelegt sind.

Ihr solltets das zeitnah klären ehe euch das datastore voll läuft. Das könnte dann ganz schäbig werden.

Gruss

[irix]

Thinprovionig VMS?

Gruß
Joerg

[Martin]

Wir haben die letzten Wochen keine Snapshots und keine weiteren virtuellen Maschinenplatten dort erstellt.

Ist sichergestellt, daß keinerlei Snapshots existieren?

[Zombiehase]

Hallo nochmal,

wir wissen bereits welche virtuelle Maschine den Speicherplatz frisst. Wir fragen uns nur warum.

Eigentlich dürfte die selbst nicht wachsen derzeit egal ob wir dynamisch wachsende Festplatten eingestellt haben. Die sind ansatzweise noch nicht voll. Trotzdem schrumpft der freie Speicher.

Welche Logfiles wären denn interessant?

Dass jmd quer auf das System schreibt können wir ausschließen.

Was sind eigentlich die zu den normalen vmdk Dateien im Verzeichnis stehenden "XXX_1-000003-sesparse.vmdk" Dateien?

Gruß,
Alina

[Zombiehase]

Wir haben die letzten Wochen keine Snapshots und keine weiteren virtuellen Maschinenplatten dort erstellt.

Ist sichergestellt, daß keinerlei Snapshots existieren?

Die haben wir schon gelöscht, um an Speicherplatz zu kommen.

[Zombiehase]

Thinprovionig VMS?

Gruß
Joerg

Nein, thick-provision lazy zeroed

[~thc]

Was sind eigentlich die zu den normalen vmdk Dateien im Verzeichnis stehenden "XXX_1-000003-sesparse.vmdk" Dateien?

"XXX_1" von dieser Basis-Disk erstellter
"000003": Snapshot
"-sesparse": im "Space efficient sparse"-Format?

Oder eine Teildisk der Basis-Disk?

[kastlr]

Hallo,

der Füllstand einer vmdk hat nur bedingt mit dem belegtem Speicherplatz im Datastore zu tun.

Hast du z. B. eine 500 GB vmdk als Thin Device angelegt, belegt sie anfänglich nur wenig Speicher auf dem Datastore.
Wenn dann neue Dateien (z. B. 200 GB) in der vmdk abgelegt werden, wächst diese natürlich auf ca. 200 GB und daher sinkt die freie Kapazität des Datastores.
Werden nun aber Dateien in der vmdk gelöscht (z. B. 100 GB), belegt die vmdk weiterhin 200 GB, die freigewordene Kapazität wird nicht an den VMFS Datastore zurück gegeben.
Und wenn das Gast OS dann erneut Dateien auf bisher nicht verwendeten Bereichen der vmdk ablegt, wächst die vmdk wieder und der freie Plattenplatz des Datastore reduziert sich erneut.

Gruß,
Ralf

[Zombiehase]

Was sind eigentlich die zu den normalen vmdk Dateien im Verzeichnis stehenden "XXX_1-000003-sesparse.vmdk" Dateien?

"XXX_1" von dieser Basis-Disk erstellter
"000003": Snapshot
"-sesparse": im "Space efficient sparse"-Format?

Oder eine Teildisk der Basis-Disk?

Unsere Festplatte1 von dem virtuellen Server ist 150 GB groß. die ist auch als "XXX-flat.vmdk" in dem Ordner. die 2. Festplatte ist 4 TB groß und unter "XXX-1-flat.vmdk" in dem Ordner.
Zusätzlich sind da noch 3 "XXX-sesparse.vmdk" Dateien nummeriert von 000001 - 000003 in dem Ordner mit 884 GB, 17 Mb und 16 MB (mit heutigem Änderungsdatum)

Die Snapshots habe ich bereits alle über den Snapshot Manager gelöscht.

Woher weiß ich ob es eine Teildisk oder Basisdisc ist? Kann ich die löschen um an Speicherplatz zu kommen?

Zudem ist mir aufgefallen, dass wenn ich eine neue virtuelle Maschine erstellen möchte wird mir bei datastore 1 angezeigt:
Kapazität: 5,45 TB
Bereitgestellt: 9,26 TB
Frei 359,13 GB

Wie kommt das zustande?

Hallo,

der Füllstand einer vmdk hat nur bedingt mit dem belegtem Speicherplatz im Datastore zu tun.

Hast du z. B. eine 500 GB vmdk als Thin Device angelegt, belegt sie anfänglich nur wenig Speicher auf dem Datastore.
Wenn dann neue Dateien (z. B. 200 GB) in der vmdk abgelegt werden, wächst diese natürlich auf ca. 200 GB und daher sinkt die freie Kapazität des Datastores.
Werden nun aber Dateien in der vmdk gelöscht (z. B. 100 GB), belegt die vmdk weiterhin 200 GB, die freigewordene Kapazität wird nicht an den VMFS Datastore zurück gegeben.
Und wenn das Gast OS dann erneut Dateien auf bisher nicht verwendeten Bereichen der vmdk ablegt, wächst die vmdk wieder und der freie Plattenplatz des Datastore reduziert sich erneut.

Gruß,
Ralf

Danke für die gute Erklärung, aber das Problem dürfte wegfallen, da die Festplatten als "Thick-Provision Lazy-Zeroed" angelegt wurde.

[~thc]

Ihr habt auf dem Datastore mehr Speicherplatz vergeben, als er physisch hat (Overprovisioning durch Thin/Sparse-Disks) - deine Aussage, dass alle Disks "Thick" seien, ist damit nicht vereinbar!

Wären alle Thick: "Gesamt" minus "Bereitgestellt" = "Frei"

[kastlr]

Tja, deine Info mit der Thick vmdk lief in der Zeit auf, als ich an meiner Antwort gearbeitet habe.

Egal, folgende VMware KB's sollten dir hier weiterhelfen können.
Committing snapshots when there are no snapshot entries in the Snapshot Manager
Commands to monitor snapshot deletion in VMware ESXi/ESX

Gruß,
Ralf

[Zombiehase]

Ihr habt auf dem Datastore mehr Speicherplatz vergeben, als er physisch hat (Overprovisioning durch Thin/Sparse-Disks) - deine Aussage, dass alle Disks "Thick" seien, ist damit nicht vereinbar!

Wären alle Thick: "Gesamt" minus "Bereitgestellt" = "Frei"

Ich kann nur sagen, was da steht.
Habe mir sämtliche Maschinen angeschaut und da steht überall unter "Einstellungen bearbeiten" "Thick-Provision Lazy-Zeroed.
Deswegen kann ich mir das auch nicht erklären

[~thc]

Dann sind vermutlich die immer noch existierenden Snapshots daran Schuld - kannst du per SSH auf den ESXi zugreifen und den Inhalt aller VMDK-Dateien (auch der Snapshots) einsehen? Dann würde klar werden, welche VMDKs da Thin sind.

[Zombiehase]

Dann sind vermutlich die immer noch existierenden Snapshots daran Schuld - kannst du per SSH auf den ESXi zugreifen und den Inhalt aller VMDK-Dateien (auch der Snapshots) einsehen? Dann würde klar werden, welche VMDKs da Thin sind.

Per SSH komm ich drauf. Bin auch im "Problemordner" . Wie kann ich da den Inhalt der .vmdk Dateien einsehen?

Auflistung der vorhanden Dateien in dem Ordner:
(XXX-aux.xml
XXX.vmx.lck
XXX_1-000003-sesparse.vmdk
vmware-4.log
XXX-ff002be6.vswp
XXX.vmxf
XXX_1-000003.vmdk
vmware-5.log
XXX-flat.vmdk
XXX.vmx~
XXX_1-flat.vmdk
vmware-6.log
XXX.nvram
XXX_1-000001-sesparse.vmdk
XXX_1.vmdk
vmware-7.log
XXX.vmdk
XXX_1-000001.vmdk
vmmcores-1.gz
vmware.log
XXX.vmsd
XXX_1-000002-sesparse.vmdk
vmware-2.log
vmx-XXX-4278201318-1.vswp
XXX.vmx
XXX_1-000002.vmdk
vmware-3.log)

Derzeit habe schaue ich mir die Einstellungen hauptsächlich über den vSphere Client an. Dort habe ich auch die mal erstellten Snapshot Dateien gelöscht.

(Tut mir leid, so viel Erfahrung ist noch nicht da :/ )

[~thc]

Dann schau erst mal mit

Code: Alles auswählen

less XXX.vmx

in der Definition der Maschine nach, welcher Snapshot aktiv ist (einfach hier als code-Block posten).

[Zombiehase]

Wenn ich "less XXX.vmx" eingebe wird folgendes angezeigt:

Code: Alles auswählen

.encoding = "UTF-8"
config.version = "8"
virtualHW.version = "8"
nvram = "XXX.nvram"
pciBridge0.present = "TRUE"
svga.present = "TRUE"
pciBridge4.present = "TRUE"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge4.functions = "8"
pciBridge5.present = "TRUE"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge5.functions = "8"
pciBridge6.present = "TRUE"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge6.functions = "8"
pciBridge7.present = "TRUE"
pciBridge7.virtualDev = "pcieRootPort"
pciBridge7.functions = "8"
vmci0.present = "TRUE"
hpet0.present = "TRUE"
displayName = "XXX"
extendedConfigFile = "XXX.vmxf"
virtualHW.productCompatibility = "hosted"
numvcpus = "2"
cpuid.coresPerSocket = "2"
memSize = "12288"
scsi0.virtualDev = "lsisas1068"
scsi0.present = "TRUE"
ide1:0.startConnected = "FALSE"
ide1:0.deviceType = "cdrom-raw"
ide1:0.clientDevice = "TRUE"
ide1:0.fileName = "emptyBackingString"
ide1:0.present = "TRUE"
floppy0.startConnected = "FALSE"
floppy0.clientDevice = "TRUE"
floppy0.fileName = "vmware-null-remote-floppy"
ethernet0.virtualDev = "e1000"
ethernet0.networkName = "VM Network"
ethernet0.addressType = "generated"
ethernet0.present = "TRUE"
scsi0:0.deviceType = "scsi-hardDisk"
scsi0:0.fileName = "XXX.vmdk"
scsi0:0.present = "TRUE"
guestOS = "windows7srv-64"
disk.EnableUUID = "TRUE"
toolScripts.afterPowerOn = "TRUE"
toolScripts.afterResume = "TRUE"
toolScripts.beforeSuspend = "TRUE"
toolScripts.beforePowerOff = "TRUE"
uuid.bios = "56 4d 4c 86 3c 77 cb 56-91 17 c9 ef 23 a8 43 57"
uuid.location = "56 4d 4c 86 3c 77 cb 56-91 17 c9 ef 23 a8 43 57"
vc.uuid = "52 19 86 21 d8 94 9e be-17 0a 4a e6 96 a3 02 54"
svga.vramSize = "8388608"
sched.swap.derivedName = "/vmfs/volumes/539ae4a3-72c468c3-7fe8-c81f66bf6a6a/XXX/XXX-ff002be6.vswp"
replay.supported = "FALSE"
replay.filename = ""
scsi0:0.redo = ""
pciBridge0.pciSlotNumber = "17"
pciBridge4.pciSlotNumber = "21"
pciBridge5.pciSlotNumber = "22"
pciBridge6.pciSlotNumber = "23"
pciBridge7.pciSlotNumber = "24"
scsi0.pciSlotNumber = "160"
ethernet0.pciSlotNumber = "32"
vmci0.pciSlotNumber = "33"
scsi0.sasWWID = "50 05 05 66 3c 77 cb 50"
ethernet0.generatedAddress = "00:0c:29:a8:43:57"
ethernet0.generatedAddressOffset = "0"
vmci0.id = "598229847"
hostCPUID.0 = "0000000d756e65476c65746e49656e69"
hostCPUID.1 = "000306e40020080077bee3ffbfebfbff"
hostCPUID.80000001 = "0000000000000000000000012c100800"
guestCPUID.0 = "0000000d756e65476c65746e49656e69"
guestCPUID.1 = "000306e400020800969822031fabfbff"
guestCPUID.80000001 = "00000000000000000000000128100800"
userCPUID.0 = "0000000d756e65476c65746e49656e69"
userCPUID.1 = "000306e400020800969822031fabfbff"
userCPUID.80000001 = "00000000000000000000000128100800"
evcCompatibilityMode = "FALSE"
vmotion.checkpointFBSize = "8388608"
cleanShutdown = "FALSE"
softPowerOff = "FALSE"
toolsInstallManager.lastInstallError = "0"
tools.syncTime = "FALSE"
unity.wasCapable = "TRUE"
tools.remindInstall = "FALSE"
toolsInstallManager.updateCounter = "1"
scsi0:1.deviceType = "scsi-hardDisk"
scsi0:1.fileName = "XXX_1-000001.vmdk"
sched.scsi0:1.vFlash.enabled = "FALSE"
scsi0:1.present = "TRUE"
scsi0:1.redo = ""
scsi0:2.deviceType = "scsi-hardDisk"
scsi0:3.deviceType = "scsi-hardDisk"

[~thc]

Du siehst an

Code: Alles auswählen

scsi0:0.fileName = "XXX.vmdk"

und

Code: Alles auswählen

scsi0:1.fileName = "XXX_1-000001.vmdk"

das die erste Festplatte ohne Snapshot (konsolidiert) läuft, und die zweite aber noch auf den Snapshot 000001 zeigt.

Verifiziere das wie folgt:

Mit

Code: Alles auswählen

vim-cmd vmsvc/getallvms

erhälst du eine Liste der VMs mit ihrer Vmid.

Mit

Code: Alles auswählen

vim-cmd vmsvc/snapshot.get [vmid]

lass dir die Snapshots der VM anzeigen.

[Zombiehase]

Wenn ich

Code: Alles auswählen

 vim-cmd vmsvc/snapshot.get 3

eingebe kommt nur:

Code: Alles auswählen

 Get Snapshot:

[~thc]

Dann ist auch von der Kommandozeile nix zu holen.

Hast du das von VMWare empfohlene Verfahren probiert?

Commit snapshots from vCenter/vSphere Client
To commit all snapshots by using the Virtual Infrastructure Client:

Take a Snapshot. For more information, see the Take a Snapshot section of the VMware vSphere Online Library.
Delete all Snapshots. For more information, see the Delete all Snapshots section of the VMware vSphere Online Library.

Note: If you have unsuccessfully attempted to consolidate using the Take a Snapshot then Delete all Snapshots technique, attempt the technique again, but this time select the Quiesce guest file system checkbox to enable quiesced snapshots when you Take a Snapshot.

[Zombiehase]

Das versuche ich Donnerstag mal. Danke bis dahin schon mal

[JustMe]

Kleine Erklaerung so nebenher, vielleicht hilft es ja beim weiteren Verstaendnis:

Snapshot-Dateien sind (bisher) IMMER Thin-provisioned.

Wenn ich also von einer VM mit einer 4TB-vmdk Thick-provisioned) einen Snapshot erstelle, dann liegen im Verzeichnis ZWEI Dateien von 4TB Groesse (provisioned) herum, von denen aber natuerlich nur die Base-Disk tatsaechlich 4TB belegt. Allerdings kann die Snapshot-Datei trotzdem bis auf diese Groesse wachsen.

Damit muesste die Anzeige "Kapazitaet/Bereitgestellt/Frei" geklaert sein.

Bei der weiteren Untersuchung koennte es helfen, den Verzeichnisinhalt nicht mit "ls" sondern mit "ls -lh", und dann auch mit "du -h" gegenueber zu stellen.

Und dann in die KLEINEN *.vmdk hineinschauen. (oder hier im "Code"-Kontext posten).

[Zombiehase]

Hallo zusammen,

meine Kollegin und ich haben da gerade noch mal drüber gesprochen.
Die Platte 2 (Datenplatte) zeigt ja noch auf einen Snapshot.

Wenn wir den dann mittels

Commit snapshots from vCenter/vSphere Client
To commit all snapshots by using the Virtual Infrastructure Client:

Take a Snapshot. For more information, see the Take a Snapshot section of the VMware vSphere Online Library.
Delete all Snapshots. For more information, see the Delete all Snapshots section of the VMware vSphere Online Library.

Note: If you have unsuccessfully attempted to consolidate using the Take a Snapshot then Delete all Snapshots technique, attempt the technique again, but this time select the Quiesce guest file system checkbox to enable quiesced snapshots when you Take a Snapshot.

gelöscht bekommen... gehen dann die Daten verloren?

Danke schon mal

Gruß,
Alina

[JustMe]

Nein, wenn alles gut geht, werden ja nur die Daten, die in der Snapshot-Datei als Unterschiede zur Basis-Datei gespeichert sind, in ebendiese Basis-Datei "eingearbeitet".

Was man verliert, waere die Moeglichkeit zum Zeitpunkt VOR dem Snapshot zurueckzukehren. Aber das geht ja eh' nicht mehr (sauber), weil das Snapshot-Aufloesen schon teilweise "gelungen" war, denn die "kleine" Disk scheint keinen Snapshot mehr zu haben, und in der Snapshot-Verwaltung wird ja vmtl auch nix mehr angezeigt.

Ich bin gespannt, ob das wie im Zitat beschrieben funktioniert

Ach ja, PS:
Es waere moeglicherweise immer noch hilfreich, wenn wir das vollstaendige Verzeichnislisting (ls -lh) mit der Belegungsinformation (du -h *), sowie die Inhalte der kleinen .vmdk-Dateien zu sehen bekommen koennten.

[Zombiehase]

Wenn ich ls -lh eingebe kommt folgendes bei raus:

Code: Alles auswählen

 total 5396166680
-rw-r--r--    1 root     root          13 Mar 17 15:51 XXX-aux.xml
-rw-------    1 root     root       12.0G Mar 16 05:45 XXX-ff002be6.vswp
-rw-------    1 root     root      150.0G Mar 19 10:54 XXX-flat.vmdk
-rw-------    1 root     root        8.5K Mar 19 08:26 XXX.nvram
-rw-------    1 root     root         496 Mar 19 08:26 XXX.vmdk
-rw-r--r--    1 root     root          78 Mar 19 08:26 XXX.vmsd
-rwxr-xr-x    1 root     root        3.2K Mar 19 08:26 XXX.vmx
-rw-------    1 root     root           0 Feb  7 15:18 XXX.vmx.lck
-rw-r--r--    1 root     root        3.2K Jun 16  2014 XXX.vmxf
-rwxr-xr-x    1 root     root        3.2K Mar 19 08:26 XXX.vmx~
-rw-------    1 root     root       18.6G Mar 19 08:26 XXX_1-000001-sesparse.vmdk
-rw-------    1 root     root         345 Mar 17 10:02 XXX_1-000001.vmdk
-rw-------    1 root     root       16.1G Mar 19 08:26 XXX_1-000002-sesparse.vmdk
-rw-------    1 root     root         338 Mar 17 09:52 XXX_1-000002.vmdk
-rw-------    1 root     root      883.7G Mar 19 08:26 XXX_1-000003-sesparse.vmdk
-rw-------    1 root     root         345 Mar 17 09:54 XXX_1-000003.vmdk
-rw-------    1 root     root       24.6G Mar 19 08:26 XXX_1-000004-sesparse.vmdk
-rw-------    1 root     root         345 Mar 17 15:34 XXX_1-000004.vmdk
-rw-------    1 root     root       16.5G Mar 19 10:52 XXX_1-000005-sesparse.vmdk
-rw-------    1 root     root         345 Mar 19 08:29 XXX_1-000005.vmdk
-rw-------    1 root     root        4.0T Mar 19 10:54 XXX_1-flat.vmdk
-rw-------    1 root     root         474 Mar 19 08:26 XXX_1.vmdk
-rw-------    1 root     root        4.2M Mar 16 05:43 vmmcores-1.gz
-rw-r--r--    1 root     root      220.2K Jun 17  2014 vmware-2.log
-rw-r--r--    1 root     root       46.7M Jun 27  2014 vmware-3.log
-rw-r--r--    1 root     root        3.5G Oct  6 08:13 vmware-4.log
-rw-r--r--    1 root     root      541.7M Oct 21 11:34 vmware-5.log
-rw-r--r--    1 root     root        1.4G Feb  7 06:02 vmware-6.log
-rw-r--r--    1 root     root      164.2M Mar 16 05:43 vmware-7.log
-rw-r--r--    1 root     root        4.0M Mar 19 08:29 vmware.log
-rw-------    1 root     root      127.0M Mar 16 05:45 vmx-XXX-4278201318-1.vswp

du -h * ergibt folgendes:

Code: Alles auswählen

 0       XXX-aux.xml
12.0G   XXX-ff002be6.vswp
150.0G  XXX-flat.vmdk
1.0M    XXX.nvram
0       XXX.vmdk
0       XXX.vmsd
8.0K    XXX.vmx
0       XXX.vmx.lck
8.0K    XXX.vmxf
8.0K    XXX.vmx~
2.5G    XXX_1-000001-sesparse.vmdk
0       XXX_1-000001.vmdk
23.0M   XXX_1-000002-sesparse.vmdk
0       XXX_1-000002.vmdk
871.1G  XXX_1-000003-sesparse.vmdk
0       XXX_1-000003.vmdk
8.5G    XXX_1-000004-sesparse.vmdk
0       XXX_1-000004.vmdk
362.0M  XXX_1-000005-sesparse.vmdk
0       XXX_1-000005.vmdk
4.0T    XXX_1-flat.vmdk
0       XXX_1.vmdk
3.0M    vmmcores-1.gz
1.0M    vmware-2.log
47.0M   vmware-3.log
3.5G    vmware-4.log
542.0M  vmware-5.log
1.4G    vmware-6.log
165.0M  vmware-7.log
5.0M    vmware.log
127.0M  vmx-XXX-4278201318-1.vswp

less XXX_1-000004.vmdk ergibt folgendes als Bsp:

Code: Alles auswählen

 # Disk DescriptorFile
version=1
encoding="UTF-8"
CID=de4a4f39
parentCID=afc8b2e0
isNativeSnapshot="no"
createType="seSparse"
parentFileNameHint="XXX_1-000001.vmdk"
# Extent description
RW 8589934592 SESPARSE "XXX_1-000004-sesparse.vmdk"

# The Disk Data Base
#DDB

ddb.grain = "8"
ddb.longContentID = "22baddf2b6eb3590277c676ede4a4f39"