Snapshoterstellen nicht möglich

[DGutschalk]

Ich grüße euch,

Ich habe in einer meiner Umgebungen eine VM die ich nicht snappshotten kann. Ich probiere es über unser vCenter und erhalte den Fehler
Es wurde eine ungültige Snapshot-Konfiguration erkannt.
Fehler beim Erstellen eines Snapshots: Eine erforderliche Datei wurde nicht gefunden.
Fehler beim Speichern der Snapshot-Datei '/vmfs/volumes/56e81272-117b6e28-06ee-0cc47ac0884c/Email_Archiv/Email_Archiv-Snapshot684.vmsn'.
Fehler beim Speichern des Snapshots: Eine erforderliche Datei wurde nicht gefunden.

Ich habe schon versucht die VMX neu zu registrieren und habe die Maschine aus dem Inventory geworfen und neu hinzugefügt, leider ohne Erfolg. Die VSMSD habe ich schon einmal aus dem Ordner geworfen und neu erstellen lassen, leider auch keine Hilfe.

Im vmware.log aus dem Folder der VM habe ich ein paar Einträge die mich etwas verwirren, failed to create child disk: The file already exists und SnapshotBranch failed: A required file was not found (7).

Wenn das Log hilft poste ich es gern.

Bin offen für alle Ideen

[irix]

Kannst du mal pruefen ob bereits ein Snapshot besteht... und aus diesem evtl. Dateien verlustig geangen sind? Weil das wuerde zumind. die Fehlermeldung evtl. erklaerbar machen.

Aber ich habe vorab eine Frage. Wieviel Platz ist noch im Datastore und wiegross ist der konfigurierte vMEM der VM?

Ansonsten.
- Ein Dateilisting von der Shell
- Ein grep vmdk *.vmx
- Dateinamen der vDisks mit -00000x.vmdk
- Moeglichkeit der Vergroesserung ausgegraut

wuerde Anzeigen das die VM bereits einen oder mehrere Snaps hat. Dann gibts extrems seltene Faelle wo der Ablage Ort fuer Snapts woanders hin umgebogen wird.

Gruss
Joerg

[DGutschalk]

Guten Morgen,

Danke schonmal für deine Zeit.

Ich habe nicht erkennen können das bereits ein Snapshot besteht. Der Datastore auf dem die VM liegt hat noch 250GB Platz. Der RAM ist 8GB groß. Vielleicht dazu zu sagen, die Maschine hat eine 50GB Platte und eine 6TB Thin Provisioning Platte. Die 6TB Platte liegt auf einem anderen Store der noch 1,34TB frei hat.

Hier mal die Liste mit Files:
-rw-r--r-- 1 root root 90 Jan 31 18:17 Email_Archiv-5a8cf493.hlog
-rw------- 1 root root 8589934592 Mar 26 09:14 Email_Archiv-5a8cf493.vswp
-rw-r--r-- 1 root root 13 Feb 16 04:04 Email_Archiv-aux.xml
-rw------- 1 root root 3277312 Mar 27 03:46 Email_Archiv-ctk.vmdk
-rw------- 1 root root 53687091200 Mar 27 07:37 Email_Archiv-flat.vmdk
-rw------- 1 root root 8684 Mar 27 03:46 Email_Archiv.nvram
-rw------- 1 root root 615 Mar 27 03:45 Email_Archiv.vmdk
-rw-r--r-- 1 root root 77 Mar 27 03:45 Email_Archiv.vmsd
-rwxr-xr-x 1 root root 3080 Mar 26 11:15 Email_Archiv.vmx
-rw------- 1 root root 0 Mar 26 09:14 Email_Archiv.vmx.lck
-rw------- 1 root root 3764 Aug 26 2016 Email_Archiv.vmxf
-rwxr-xr-x 1 root root 3156 Mar 26 11:15 Email_Archiv.vmx~
-rw------- 1 root root 9488491 Aug 26 2017 vmmcores-1.gz
-rw-r--r-- 1 root root 292924 Mar 26 09:10 vmware-10.log
-rw-r--r-- 1 root root 279828 Jan 31 17:04 vmware-5.log
-rw-r--r-- 1 root root 192817 Jan 31 17:17 vmware-6.log
-rw-r--r-- 1 root root 188644 Jan 31 18:17 vmware-7.log
-rw-r--r-- 1 root root 5056217 Mar 26 07:18 vmware-8.log
-rw-r--r-- 1 root root 366753 Mar 26 09:03 vmware-9.log
-rw-r--r-- 1 root root 390633 Mar 27 06:41 vmware.log
-rw------- 1 root root 174063616 Mar 26 09:14 vmx-Email_Archiv-1519187091-1.vswp
-r-------- 1 root root 8638464 Aug 26 2017 vmx-zdump.000

und grep vmdk *.vmx
scsi0:0.fileName = "Email_Archiv.vmdk"
scsi0:1.fileName = "/vmfs/volumes/56e897f7-b2982877-34f1-0cc47ac08998/Email_Archiv/Email_Archiv.vmdk"

Gruß

[irix]

Hmm....
also die VM hat keinen Snapshot und genug Platz sagst du ist auch vorhanden. Man kann sehen das die VM mal einen Crash hatte da dort ein zdump herum liegt.

https://www.google.de/search?q=vmware+%22Detected+invalid+snapshot+configuration%22&ie=utf-8&oe=utf-8&client=firefox-b&gfe_rd=cr
Leider hat vmware.com gerade Wartungsarbeiten


- Was passiert wenn du einen Snap ohne Memory/Quiesing erstellst?
- Zeigen andere VMs auf dem gleichen Datastore auch das Problem?
- Poste mit den Inhalt von /vmfs/volumes/56e81272-117b6e28-06ee-0cc47ac0884c/Email_Archiv/

Edit:
Frage... warum gibt es dort ZWEI *.vswp Dateien? Diese haben bei dir auch eine unterschiedliche Groesse.Wer keine Memory Resvervierung macht bei dem hat diese Datei immer die Groesse des konfigurierten vMem.

Gruss
Joerg

[DGutschalk]

Snapshot ohne Memory/Quiesing schlägt ebenfalls fehl
Andere VMs zeigen nicht das Problem
Den Inhalt des Verzeichnisses hab ich schon gepostet, das ist das in dem die VM liegt

Warum dort zwei vswp Dateien liegen ist eine gute Frage die ich dir so spontan nicht beantworten kann. Memory Reservierung ist nicht aktiv, eine der beiden hat die Größe des vMem.

Gruß

[irix]

Snapshot ohne Memory/Quiesing schlägt ebenfalls fehl
Andere VMs zeigen nicht das Problem
Den Inhalt des Verzeichnisses hab ich schon gepostet, das ist das in dem die VM liegt

Nein... du hast den Inhalt von EINEM Verzeichnis gepostet. Du sagst das die 2. vDisk wo anders liegt.
Der eine Post aus dem Jahre 2009 da im VMTN hat die gleiche Ausgangslage wie du. Eine VM und vDisks in unterschiedlichen Datastore. Aber es wurde nie eine Loesung des Problems gepostet.


Ich wuerde die VM mal ausmachen... und die vmsd loeschen und etwas auftrauemen core/dump loeschen. Dann im ausgeschalteten eine Versuch starten. Die Meldung mit file not found sollte man ignorieren koennen das Folgefehler. Er kann sie nicht anlegen und die Frage warum.

Wir sind betroffen von dem Problem das ein Lock (Snapshot loeschen geht dann nicht) haengen vom Eigentuemer 000000000000 und wir nicht herausbekommen welcher Host/Prozess das ist. Nur loesbar in dem alle Hosts neugestartet werden.

Gruss
Joerg

[DGutschalk]

Du hast recht, ich habe nur ein Verzeichnis gepostet.
-rw------- 1 root root 24.2G Feb 17 04:00 Email_Archiv-000002-sesparse.vmdk
-rw------- 1 root root 24.2G Feb 17 04:16 Email_Archiv-000003-sesparse.vmdk
-rw------- 1 root root 24.2G Feb 17 04:31 Email_Archiv-000004-sesparse.vmdk
-rw------- 1 root root 24.2G Feb 17 04:46 Email_Archiv-000005-sesparse.vmdk
-rw------- 1 root root 6.0M Mar 27 08:36 Email_Archiv-ctk.vmdk
-rw------- 1 root root 6.0T Mar 27 10:05 Email_Archiv-flat.vmdk
-rw------- 1 root root 619 Mar 27 08:35 Email_Archiv.vmdk

Ich schätze hier liegt der Hase dann auch im Pfeffer, keine Ahnung warum ich nicht auf die Idee gekommen bin dem Verzeichnis nachzusehen. Muss ich nur schauen wie ich diese komische Snapshot Überreste weg bekomme.

[irix]

Bei VMDKs >2TB wird fuer Snapshots das sesparse Format verwendet. Ich habe wenig bis keine vDisks mit dieser Groesse... .. unsere VMs haben immer mehrere Platten dann.

Die Frage warum die alle die gleiche Groesse haben und nun schon 4 Wochen alt sind. Bei einem "normalen" aktiven Snapshot haette der Snap das aktuelle Datum und die Flat den "eingefrohrenen" Zustand.

Man koennte die sesparse mal verschieben... loeschen wuerde ich sie noch nicht. Es gibt auch ein vmkfstool Aufruf mit einem Schalter welcher die Snapshotchain prueft.

Es muesste sich mal einer melden welcher sagen kann in wiefern sich die sesparse von den normalen Snapshotdaeien unterscheiden.

Wenn du "Snapshot" Consolidate ausfuehrst aendert sich was?

Gruss
Joerg

[DGutschalk]

Ich habe die sesparse Files mal rausgeschoben und versucht einen Snapshot zu machen. Jetzt erhalte ich nicht mehr die Fehlermeldung einer ungültigen Konfiguration sondern das ich nicht genug Speicher auf dem Volume frei habe. DIESE Meldung habe ich bei einer anderen VM auch. Mal schauen was ich zu dem Thema rausbekomme.

Dir schon mal vielen Dank für deine Zeit!

[Dayworker]

Hänge mal bitte alle noch vorhandenen Logs mit "vmware" im Namen an und poste dazu sowohl die Grösse als auch den Freien Platz aller beteiligten Datastores.

[DGutschalk]

datastore1 (1) Kapazität 52GB Frei 51,05GB
qsan_vmstore Kapazität 599,75GB Frei 250,25GB
qsan_produktivstore Kapazität 12TB Frei 709,76GB
qsan_archivbackupstore Kapazität 63,82TB Frei 1,34TB
qsan_kerio Kapazität 1,76TB Frei 1,76TB

Die betroffenen Stores sind markiert. Heute früh habe ich gesehen das die VM pausiert ist, VMWare meldet das nicht genug Speicher auf dem archivbackupstore ist, ich könnte die Sitzung nach Beantwortung der Frage eventuell fortsetzen. Klappt aber nicht, trotz +1TB freiem Speicher

Archiv.zip

vmware logs machine folder

(585.89 KiB) 121-mal heruntergeladen

[JustMe]

Ist der qsan_archivbackupstore wirklich 63,82TB gross, oder handelt es sich womoeglich um eine Thin-provisioned LUN auf dem Storage?
Dann koennte es auch sein, dass dem zugrundeliegenden Speichergeraet die Luft ausgegangen ist, obwohl der ESXi im Datastore noch meint, Platz zu finden.

Was mir ein wenig merkwuerdig vorkommt:
- Bis zum 14.2. lief alles mit den morgendlichen Snapshots sauber.
- Vom 15.2. ist keiner im Log.
- Am 16.2. wieder ein einzelner normaler Snapshot wie viele andere vorher.
- Am 17.2. Fehler beim Quiescing des Gastes. Ursache laut Log: "2018-02-17T04:01:01.806Z| vmx| I120: SnapshotVMXTakeSnapshotComplete: Snapshot 0 failed: There is not enough space on the file system for the selected operation (5)."
- Seither sind bis zum 26.3. (Absturz) SAEMTLICHE Snapshots fehlgeschlagen (immer viertelstuendlich zwischen 04:00 und 05:00), aber bis Ende Maerz nicht mehr mit den (ausdruecklichen) Speicherproblemen.
- Ab dem 25.3. 19:00 kamen dann wieder die Out of Space Meldungen hinzu.
- Und zuletzt (nach ein paar VM-Neustartversuchen und Migrationen) ab 1.4. 19:00 die VM-Haltemitteilungen mit Speicherplatzproblemen, die in Timeout liefen; bis zum heutigen Morgen in Summe 552 Stueck.

Ich vermute mal, dass die liegengebliebenen -00000x-sesparse vmdks nur "Folgefehler" der (fehlgeschlagenen) Speicherzugriffe sind.

[continuum]

Können wir mal die vmsd-Datei sehen ?
Bitte überprüf auch einmal wieviel freier Platz innerhalb des Gastes vorhanden ist.
Wenn da zu wenig Platz ist, schlägt das quiescing fehl.
Ganz am Rande angemerkt ... ich halte es für grob fahrlässig Datastores mit 63 TB zu betreiben.

[DGutschalk]

Entschuldigt bitte, ich war fast die ganze letzte Woche auf Montage und Menschen aus meinem Büro haben sich mit der Sache nicht befasst.

In der vmsd Datei steht im Moment nur folgendes drin

.encoding = "UTF-8"
snapshot.lastUID = "712"

Der Store ist wirklich 63TB groß, leider sehe ich im Webinterface vom Storage nicht ob noch Speicher bereit steht, aktuell suche ich noch nach einer Möglichkeit das zu verifizieren. Ich hab die sesparse Dateien mal auf einen anderen Store verschoben, theoretisch wären bei einer kompletten Füllung also wieder 100GB frei geworden, kann die VM aber nicht fortsetzen. Über die Größe des Stores bin ich auch alles andere als glücklich, die Menschen die das eingerichtet haben arbeiten hier nicht mehr.

[DGutschalk]

Ich habe die pseudo 6TB Platte der VM zwischenzeitlich auf einen anderen Datastore migrieren können der 1,5TB frei hatte, jetzt werden Snapshots wieder ausgeführt. Ich denke man kan davon ausgehen das hier wirklich ein Problem mit der Erkennung des freien Speichers auf dem Datastore vorliegt oder so.