datastore 1 freier Speicherplatz schrumpf ungeklärt

[JustMe]

...dann scheinen die Snapshots -000004 und -000005 hinzugekommen zu sein.

Was steht mittlerweile in der XXX.vmx?
Was steht in der XXX_1-000005.vmdk, falls diese in der XXX.vmx gelistet sein sollte?
Was steht in der XXX_1-000001.vmdk?
Was steht in den anderen KLEINEN .vmdk-Dateien, falls die -000001.vmdk nicht auf die Basis-Datei zeigen sollte?

Ich vermute jetzt mal in's Blaue hinein, dass die 4 und 5 aus weiteren (fehlgeschlagenen) Versuchen stammen, die Snapshots aufzuloesen.

Sollte das der Fall sein, wuerde ich folgende Vorgehensweise vorschlagen:
- Falls Support bei VMware (oder einem OEM) besteht: Dort melden, und Problem loesen lassen.
- Falls nicht: VM herunterfahren
- VM aus Bestandsliste entfernen
- XXX.vmsd loeschen (Kosmetik...)
- die XXX_1-Dateien in ein neues Verzeichnis kopieren/verschieben (tja, da raechen sich die 4TB....)
- neue VM erstellen in diesem Verzeichnis, dabei die _1-Basisdatei als Existing Disk einbinden, VM dabei NICHT EINSCHALTEN
- auch diese VM deregistrieren
- in der .vmx-Datei den Eintrag scsi0:0 auf den LETZTEN Snapshot verzeigern lassen
- VM wieder registrieren
- neuen Snapshot der VM erzeugen
- Alle Snapshots loeschen
- nun sollten keine -00000x.vmdk mehr vorhanden sein
- Basis-Disk inkl. Deskriptordatei zurueck in's alte Verzeichnis
- alte .vmx anpassen, dass die auf die Basis-Datei zeigt
- VM wieder registrieren
- fertich.

Viel Erfolg!

[Zombiehase]

Die Snapshots 000004 und -000005 hatte ich erstellt um die mittels der einen Methode zu löschen (erstmal ohne das Gastsystem herunterzufahren)

Was steht in der XXX_1-000005.vmdk, falls diese in der XXX.vmx gelistet sein sollte?

Code: Alles auswählen

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

# The Disk Data Base
#DDB

ddb.grain = "8"
ddb.longContentID = "6ac63b866354b967abbdbd9fc5881e46"

Was steht in der XXX_1-000001.vmdk?

Code: Alles auswählen

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

# The Disk Data Base
#DDB

ddb.grain = "8"
ddb.longContentID = "c9ed552e563121cb5f859133afc8b2e0"

XXX.vmdk

Code: Alles auswählen

 # Disk DescriptorFile
version=1
encoding="UTF-8"
CID=b5adf1f8
parentCID=ffffffff
isNativeSnapshot="no"
createType="vmfs"

# Extent description
RW 314572800 VMFS "XXX-flat.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "19581"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "cfb98c7c159c91d50d520ae2b5adf1f8"
ddb.toolsVersion = "9349"
ddb.uuid = "60 00 C2 9b aa fa 6f a9-ae 24 b6 5c f7 ca 38 55"
ddb.virtualHWVersion = "8"

XXX_1.vmdk

Code: Alles auswählen

 # Disk DescriptorFile
version=1
encoding="UTF-8"
CID=c1c83ddd
parentCID=ffffffff
isNativeSnapshot="no"
createType="vmfs"

# Extent description
RW 8589934592 VMFS "XXX_1-flat.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "534698"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "22baddf2b6eb3590277c676ede4a4f39"
ddb.uuid = "60 00 C2 97 9f 12 e7 d0-62 5c aa e0 2d 4b 90 1a"
ddb.virtualHWVersion = "8"

XXX_1-000002.vmdk

Code: Alles auswählen

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=157003f3
parentCID=c1c83ddd
isNativeSnapshot="no"
createType="seSparse"
parentFileNameHint="XXX_1.vmdk"
# Extent description
RW 8589934592 SESPARSE "XXX_1-000002-sesparse.vmdk"

# The Disk Data Base
#DDB

ddb.grain = "8"
ddb.longContentID = "15e921b39555da5fa3ecd919157003f3"

XXX_1-000003.vmdk

Code: Alles auswählen

 # Disk DescriptorFile
version=1
encoding="UTF-8"
CID=8bf9d5d0
parentCID=157003f3
isNativeSnapshot="no"
createType="seSparse"
parentFileNameHint="XXX_1-000002.vmdk"
# Extent description
RW 8589934592 SESPARSE "XXX_1-000003-sesparse.vmdk"

# The Disk Data Base
#DDB

ddb.grain = "8"
ddb.longContentID = "758dd4bf0f4e49e29c9004268bf9d5d0"

Ich hoffe ich habe nichts vergessen.

Falls das mit dem herunterfahren des Gastsystems nicht funktioniert, versuche ich auf jeden Fall mal deinen Vorschlag.

Danke schon mal

[JustMe]

Ich hatte von der XXX.vmx geschrieben, nicht von der XXX.vmdk

Aber mit der Aussage, dass die Snaps 4 und 5 spaeter erstellt wurden, passt das schon, und ich nehme an, dass scsi0:1 jetzt auf die 5 verweisen sollte.

Deshalb auch Obacht, denn die Snapshot-Kette ist nicht "linear", sondern offenbar 5->4->1->3->2->Base, d.h. es werden wirklich alle gebraucht.

Herunterfahren des Gastes ist dewegen vorteilhaft, weil dann zumindest keine I/Os dieses Gastes mehr das System belasten.

[irix]

Welche vDisk noch eine Snap haelt und wie der heist zeigt immer ein

Code: Alles auswählen

grep vmdk *.vmx

im Verzeichnis der VM.

Aber ich wuerde die VM nicht ausmachen wollen. Wir gehen mal davon aus das vorher ein Backup gemacht wird. Je nach Groesse und Performance kann das einarbeiten Stunden dauern und wenn der Prozess gestartet ist kannst du an der VM selber nix machen. Auch ein einschalten geht nicht! Ich wuerde es Online machen und gucken das es nicht zur Hochlastphase passiert. Das WE steht ja vor der Tuer!

Andere Frage ist was fuer Ursachen es haben kann das nur eine vDisk eine Snapshotkette hat und nicht alle bzw. warum das loeschen unvollstaendig war.

Wie wird das Backup der VM gemacht und kommt ein Produkt zum Einsatz welches den Hot-Add Mode verwenden und besteht die Gefahr das die vDisk noch wo anders gemountet ist?

Frage an alle:
Wo stellt man den ein das man diese Sparse vDisk haben will bzw. wer triggert dies? Weil der Standard ist dies ja nun nicht.

Gruss
Joerg

[Zombiehase]

Ich hatte von der XXX.vmx geschrieben, nicht von der XXX.vmdk

Hups, hier noch mal die XXX.vmx

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-000005.vmdk"
sched.scsi0:1.vFlash.enabled = "FALSE"
scsi0:1.present = "TRUE"
scsi0:1.redo = ""
scsi0:2.deviceType = "scsi-hardDisk"
scsi0:3.deviceType = "scsi-hardDisk"

Noch eine kurze Frage:
Wenn wir das so machen, wie du es beschrieben hast, gehen uns dann Daten verloren oder auch nicht?

[JustMe]

Tja, Problem ist nur, dass bisher alle Versuche, die Snapshots IM LAUFENDEN BETRIEB zu beseitigen, nicht funktioniert haben

Ansonsten ist Dein Einwand natuerlich berechtigt. Aber wat will mer mocha...

Und wenn man sich die Logs detailliert anschaut, wird man vmtl. feststellen, dass auch fuer die erste Platte immer brav ein Snapshot-File angelegt wurde, dieses dann aber recht schnell wieder aufgeloest werden konnte beim RemoveAll. Und beim Fortschreiten des Snapshot-Aufloesens (eben dann fuer die zweite Platte) kommen dann Fehler, und deren Snapshot wird NICHT aufgeloest.

@zombiehase:
Nein, wie schon geschrieben, sollten beim Aufloesen keine Daten verlorengehen.
Nichtsdestotrotz ist ein Backup immer gut, aber wie irix schon schrieb, bei 4TB halt mit einigem Zeitaufwand verbunden.