VMware-Forum

Hallo,

ich habe ein Problem mit einem ESXi 5.0 Host. Der Datastore läuft bald über. Im Moment habe ich noch 12 GB Platz und werde wohl auf der HDD keinen weiteren Platz mehr freigeben können. Der Datenspeicherbrowser zeigt folgenden Dateien an. (siehe Bild).
In der vmx. Datei stehen folgende Einträge:

.encoding = "UTF-8"
config.version = "8"
virtualHW.version = "8"
pciBridge0.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"
nvram = "Albis W2008 R2 Server.nvram"
virtualHW.productCompatibility = "hosted"
powerType.powerOff = "soft"
powerType.powerOn = "hard"
powerType.suspend = "hard"
powerType.reset = "soft"
smbios.addHostVendor = "TRUE"
displayName = "Albis W2008 R2 Server"
extendedConfigFile = "Albis W2008 R2 Server.vmxf"
numvcpus = "4"
cpuid.coresPerSocket = "4"
scsi0.present = "TRUE"
scsi0.sharedBus = "none"
scsi0.virtualDev = "lsisas1068"
memsize = "14336"
scsi0:0.present = "TRUE"
scsi0:0.fileName = "Albis W2008 R2 Server-000003.vmdk"
scsi0:0.deviceType = "scsi-hardDisk"
ide1:0.present = "TRUE"
ide1:0.clientDevice = "FALSE"
ide1:0.deviceType = "atapi-cdrom"
ide1:0.startConnected = "TRUE"
ethernet0.present = "TRUE"
ethernet0.virtualDev = "e1000"
ethernet0.networkName = "VM Network"
ethernet0.addressType = "generated"
ethernet1.present = "TRUE"
ethernet1.virtualDev = "e1000"
ethernet1.networkName = "VM Network"
ethernet1.addressType = "generated"
disk.EnableUUID = "TRUE"
guestOS = "windows7srv-64"
uuid.location = "56 4d a9 7a 8a 85 c9 b0-e3 65 6e fd ab 88 80 cd"
uuid.bios = "56 4d a9 7a 8a 85 c9 b0-e3 65 6e fd ab 88 80 cd"
vc.uuid = "52 42 22 6d 28 c4 64 37-43 f0 a4 64 90 a0 af 97"
ide1:0.fileName = "/vmfs/devices/cdrom/mpx.vmhba35:C0:T0:L0"
ethernet0.generatedAddress = "00:0c:29:88:80:cd"
ethernet1.generatedAddress = "00:0c:29:88:80:d7"
svga.vramSize = "134217728"
vmci0.id = "-1417117491"
cleanShutdown = "FALSE"
replay.supported = "FALSE"
sched.swap.derivedName = "/vmfs/volumes/4fef0d6c-e108d952-b150-00199973112e/Albis W2008 R2 Server/Albis W2008 R2 Server-0b2838c1.vswp"
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"
ethernet1.pciSlotNumber = "33"
vmci0.pciSlotNumber = "34"
scsi0.sasWWID = "50 05 05 6a 8a 85 c9 b0"
ethernet0.generatedAddressOffset = "0"
ethernet1.generatedAddressOffset = "10"
hostCPUID.0 = "0000000b756e65476c65746e49656e69"
hostCPUID.1 = "000106a510100800009ce3bdbfebfbff"
hostCPUID.80000001 = "00000000000000000000000128100800"
guestCPUID.0 = "0000000b756e65476c65746e49656e69"
guestCPUID.1 = "000106a500040800809822011febfbff"
guestCPUID.80000001 = "00000000000000000000000128100800"
userCPUID.0 = "0000000b756e65476c65746e49656e69"
userCPUID.1 = "000106a510100800009822011febfbff"
userCPUID.80000001 = "00000000000000000000000128100800"
evcCompatibilityMode = "FALSE"
vmotion.checkpointFBSize = "134217728"
tools.syncTime = "FALSE"
unity.wasCapable = "TRUE"
svga.autodetect = "FALSE"
scsi0:0.ctkEnabled = "TRUE"
ctkEnabled = "TRUE"
scsi0:1.deviceType = "scsi-hardDisk"
sched.cpu.units = "mhz"
sched.cpu.shares = "high"
sched.cpu.min = "5624"
floppy0.present = "FALSE"

Es scheint so zu sein, dass die "Albis W2008 R2 Server-000003.vmdk" die Datei ist, die als einzige ständig wächst.

Die Konsolidierung der virtuellen Festplatten kann im Moment noch erfolgreich durchgeführt werden.

Im Snapshot-Manager stehen 2 Snapshots vom 9.12. drin. Aber wenn ich diese lösche, dann ist doch die Kette gefährdet, oder?
..was kann ich tun, um den Datastore zu bereinigen?

[/img]

oder?


[/img]

Kommt drauf an, wie man die Snapshots loescht

Wird Delete Snap (oder Snapshot loeschen) ausgewaehlt, so bedeutet dies, dass die Daten des Snapshots in die darunterliegende Ebene eingearbeitet werden. Man verliert also keinerlei Daten, sondern nur die Moeglichkeit, zum Zeitpunkt der Erstellung des Snapshots zurueckzukehren.

Wenn man "Revert to Snap" oder so aehnlich auswaehlt, dann werden allerdings die seither aufgelaufenen Daten verworfen.

Also: Um den Datastore zu bereinigen (unter Beibehaltung des AKTUELLEN Datenbestands der VM, aber unter Verlust der Moeglichkeit, die alten Staende wiederherzustellen), muessen die Snapshots geloescht werden, z.B. RemoveAll. Das waer's.

Schau Dir bitte nochmal das Bild an. 00002 und 00004 sind vom 9.12.

Die anderen vmdk Dateien werden täglich aktualisiert.

Wenn das keine Probleme verursachen wird, kann ich die alten Snapshots dann einfach über den Snapshot-Manager über - "Alle Snapshots löschen" löschen?

..und das zur Laufzeit der VM?

Guck erstmal nach ob deine Acronis Appliance noch eine oder alle vDisks dieser VM gemounet hat und behebe das Problem.

- Dann das Backup mal aussetzen
- Im Snapshot Manager ein "Delete all" druecken und alle Aenderungen werden eingearbeitet
- Wird im Snapshot Manager nichts angezeigt ein "Consolidate" ausfuehren
- Geduld haben weil wird extrem lange dauern bei dir. Der eine Snap ist ja alleine 80GB gross!

Gruss
Joerg

Danke für die Antwort.

ich mache jetzt erstmal ein Backup. Schalte dann am besten beide VMs aus Acronis und Albis W2008 R2 Server.
Der Ordner (W2K8) ist leer.

..und lösche dann alle Snapshots?!

Zitat: "Der eine Snap ist ja alleine 80GB gross!".

Ist das unproblematisch? Ich habe ja nur noch 12 GB frei.

Gucke erst ob die andere VM die vDisks gemountet hat! Das geht auch im Livebetrieb und wenn ja haenge diese ab!

Durch das ausschalten wirst du mehr freien Speicher bekommen und die Gefahr das die Thinprovisioning VM mit ihren Snaps weiter anwaechst wird ausgeschlossen.

Nein die 12GB sind kein Problem und ich wollte nur sagen das es lange dauern wird bis der Prozess abgeschlossen ist.

Gruss
Joerg

In der Acronis-Appliance steht unter "gemountete VM(s)" - Es gibt keine gemounteten VMs

Guck in den Eigenschaften der Acronis VM nach ob da mehr vDisks angehaengt sind als sollten. Du kannst das an den Pfad/Dateinamen festmachen.

Gruss
Joerg

Albis-VM wurden 14GB an vRAM zugewiesen. Wenn du die VM abschaltest, hättest du zumindest diese 14GB und nach verschieben/löschen der drei vmmcore-Dateien nochmal weitere ~30GB freien Platz. Da sollte in Abhängigkeit der sich veränderten Daten eigentlich ausreichen. Auf der absolut sicheren Seite wärest du, wenn du VMDK- plus Snapshot-Grössen frei hättest.

sorry, vielleicht stelle ich mich ein wenig doof an, aber meinst Du die hauseigenen Platten?




Gruß Hendrik

Ich habe gesagt das du es kontrollieren sollst weil ich kann nur begrenzt Hellsehen! Wenn keine da sind die nicht hingehoeren ist ja gut. Die Festplatte 2 gehoert auch dem Acronis selber?

Das nicht loeschen von Snapshots ist sehr oft dem Problem geschuldet das die Basis Festplatten der Backup Appliance noch zugeordnet sind. Gerade wenn der Backup Prozess unplanmaessig beendet wird.

Gruss
Joerg

Festplatte 2 gehört auch zu Acronis.

Ok.

Wie genau lautete eigentlich die Fehlermeldung beim letzten Versuch des loeschens?

Gruss
Joerg

Hatte keine.
Ich habe mich nur nicht getraut die Snapshots zu löschen.
Ich habe mir Sorgen gemacht, ob ich damit die VM zerschieße, da die zu löschenden Dateien die Konsistenz der fortlaufenden Nummerierungen verlieren könnten...

Die Konsolidierung der virtuellen Festplatten lief ohne Probleme.
Jedoch lief mir der Gesamt-Speicher voll.

Vielen Dank übrigens, dass Ihr Euch der Thematik annehmt. Wenn Alles geklappt hat, dann gebe ich Euch ein virtuelles Bier aus

Wenn der Gesamtspeicher vollläuft, endet das meist in einer Katastrophe und die VM läßt sich dann häufig auch nicht mehr starten. Daher hatte ich dir ja extra etwas zum Platzbedarf geschrieben. In deinem Fall, erkennbar an der Spalte "Bereitgestellte Grösse" im DS-Browser, kann jeder Snapshot auf die von dir eingestellte VMDK-Grösse von 251,658,200KB = 240GB anwachsen.

Keine Ahnung wie groß dein Datastore ist, aber bei Thinprovisioned VMDKs muß man immer ein wachsames Auge auf den freien Platz im DS haben und Snapshots sind auch keine Backups. Du solltest auch immer im Hinterkopf haben, daß je länger eine Snapshot-Kette wird, desto anfälliger wird diese VM für Datenverlust.

Durch das Herunterfahren der VMs habe ich nun 28 GB frei, um die Löschung / Konsolidierung durchzuführen. Ich hoffe nicht, dass er erst alles rüberschreibt (80GB) und erst dann die alten Dateien löscht. Dann geht die Nummer in die Hose. Ich habe für den Notfall jedoch noch die Acronis-Sicherung und eine NAS mit 6TB...

Die Snaps werden von Hinten geginnend geloescht. Das spart Speicherplatz und frueher was das anders.

Beim ausschalten einer VM wird dessen Swapdatei geloescht und man bekommt freien Speicher in der Hoehe der Memory Konfiguration der VM. Wenn man diese auf 100% Reservierung setzten wuerde koennte man die VM wieder anmachen ohne das ein Swap angelegt wird. Wenn du aber eine Downtime dir erlauben kannst dann macht alle VMs aus.

Gruss
Joerg

Mist, jetzt habe ich genau diesen Zustand, dass mir die 00002.vmdk fehlt...

Und? Des weiteren sind Snaps mit einer groesse von 16MB hoehstwahrscheinlich Helper Snapshots weil dies die Mindesgroesse ist bzw. das Inkrement darstellen mit dem Thinprovisioning Disks wachsen.

Gruss
Joerg

Die Löschung ist gleich durch und ich probiere mal die Konsolidierung.

Der 2008er Server war übrigens auch sehr langsam, kann das was damit zu tun haben???

Wenn das loeschen funktioniert gibt es nichts zu Konsolidieren.

Zeige uns am Ende


und



Ja offene Snaps koennen ein wenig auf die Performance druecken und natuerlich ist das loeschen extrem Anspruchsvoll weil ihr die Daten aus den Snaps zurueck in die Basis vDisk uebertragen werden.

Gruss
Joerg

Der Zustand hängt jetzt die ganze Zeit bei "Alle Snapshots entfernen" - 99%.

Das wir dann wahrscheinlich eine ganze Zeit lang dauern?!

Ja, hatte ich doch geschrieben. 80GB und mehr zu verarbeiten dauert nun einmal.

Gruss
Joerg