Virtuelle Festplatte aus DS entfernen

[Nino]

Hallo zusammen,

in einer meiner Umgebungen betreue ich einen ESXi 5.0.0 Build 623860. Auf diesem Host laufen insgesamt 6 produktive Server. Gesichert wird mit Veeam Backup and Replication 6.5. Aufgrund von Platzmangel wollte ich eine virtuelle Festplatte einer VM aus dem DS entfernen.Ich habe die Festplatte in den Eigenschaften der virtuellen Maschine markiert und mit der Option "aus dem DS löschen" entfernt. Anschließend wurde der Speicherplatz aber nicht freigegeben. Ich schaute anschließend mit dem DS Browser nach und die -vmdk, sowie alle anderen Dateien, lagen immernoch dort. Hier im Forum habe ich bereits einen ähnlichen Artikel gefunden, indem der Fehler durch löschen von Snapshots behoben wurde, allerdings bin ich mir nicht sicher, ob dies in meiner Umgebung praktikabel ist.

Ich habe anschließend eine Sicherheitskopie aller Dateien auf einer Workstation erstellt und die Dateien der virtuellen Festplatte verschoben. Nun wird mir im VSphere Client eine Meldung mit "Festplatten müssen konsolidiert werden" angezeigt. Da ich noch nicht viel Erfahrung sammeln konnte und bevor ich weitere Dummheiten anstelle, dachte ich mir, ich frage lieber vorher bei eine paar Experten.

Vielleicht kann mir ja jemand weiterhelfen, vielen Dank schonmal im Vorraus.

Gruß

Nino

[Dayworker]

Eins gleich vorneweg, wir können keine Wunder verbringen...
Die Dummheit dürfte schon darin bestanden haben, die vDISK einer noch laufenden VM entfernt zu haben. Solange diese VM noch läuft, liegt eine Datei-Sperre/Lock drauf und diese wird gelöst, sobald die VM beendet wird. Die vDISK wird beim Beenden unwiderruflich gelöscht und eine Datenrettung ist dann meistens nur noch von Spezialisten wie Kroll-Ontrack oder bei geschickter vDISK-Auswahl auch von unserem Ulli aka continuum möglich.
Wenn du jetzt selbst noch mögliche bestehende Snapshots ins Spiel bringst, scheinst du absolut keinen blassen zu haben, was du da eigentlich treibst oder auch schon verbrochen hast. Snapshots sind bekanntlich kein Backup sondern nur das Mittel, um überhaupt ein Backup von gesperrten Dateien machen zu können. Zu deiner eigenen Sicherheit als Mitarbeiter kann ich nur hoffen, daß euer Backup entweder möglichst aktuell ist oder die betreffende VM möglichst wenig an Datendurchsatz zu bearbeiten hatte. In allen anderen Fällen dürfte Dir die fristlose Kündigung drohen.

Kommen wir also zur Schadensbegutachtung...
Schalte dich bitte per SSH (putty) direkt auf den ESXi-Server und poste dann die komplette Ausgabe des folgenden Befehls aus dem VM-Ordner mit der gelöschten VMDK:

Code: Alles auswählen

ls -slh

Als Ausgabe solltest du dann sowas wie dem folgenden erhalten:

Code: Alles auswählen

~ # cd /vmfs/volumes/<DS-Name>/<examplevm>
/vmfs/volumes/<DS-ID>/<examplevm> # ls -slh
5242880 -rw-------    1 root     root         5.0G Aug 28  2012 <examplevm>-flat.vmdk
  64 -rw-------    1 root     root          373 Aug 28  2012 <examplevm>.vmdk
   0 -rw-------    1 root     root            0 Aug 28  2012 <examplevm>.vmsd
  64 -rwxr-xr-x    1 root     root         1.5k Aug 29  2012 <examplevm>.vmx
  64 -rw-------    1 root     root          262 Aug 29  2012 <examplevm>.vmxf
  64 -rw-r--r--    1 root     root         3.4k Aug 28  2012 vmware-1.log
  64 -rw-r--r--    1 root     root         3.4k Aug 28  2012 vmware-2.log
  64 -rw-r--r--    1 root     root         3.4k Aug 28  2012 vmware-3.log
  64 -rw-r--r--    1 root     root         3.4k Aug 28  2012 vmware-4.log
  64 -rw-r--r--    1 root     root         4.0k Aug 29  2012 vmware-5.log
  64 -rw-r--r--    1 root     root         4.0k Aug 29  2012 vmware-6.log
  64 -rw-r--r--    1 root     root         5.9k Mar 21 10:29 vmware.log
/vmfs/volumes/<DS-ID>/<Gast-Bezeichner> #

In meinem Beispiel ist zu sehen, daß die VM über eine Preallocated VMDK von 5GB Grösse verfügt. Falls bei dir jetzt schon keine grosse VMDK-Datei ohne <examplevm>-000001 und mit Anzahl der Snapshots weiter fortlaufender 6stellige Nummer vorhanden ist, dürfte die Basis-Disk und somit auch der Ursprungsdatenträger dieser VM gelöscht sein. Die in der VMSD-Datei abgebildete Snapshotkette wäre somit ungültig, da ein Snapshot immer nur die zum jeweiligen Vorgänger geänderten Daten enthält und eine reine Snapshotdatei selbst nicht lauffähig ist.

Poste daher bitte noch den Inhalt der VMX-Datei oder verlinke gleich das aktuellste, ungekürzte "vmware.log" auf einen Freehoster oder eigenen Webspace. Dann sollten wir recht schnell das nötigste zusammenhaben.

[Nino]

Erstmal vielen Dank für die schnelle Antwort und die aufbauenden Worte
Hier ist die Ausgabe des VM Verzeichnisses:

Code: Alles auswählen

ls -slh
4096 -rw-------    1 root     root         3.1M Apr  2 07:03 ORSwin-Bremer-000001-ctk.vmdk
3195904 -rw-------    1 root     root         3.0G Apr  2 07:03 ORSwin-Bremer-000001-delta.vmdk
   0 -rw-------    1 root     root          402 Apr  2 11:21 ORSwin-Bremer-000001.vmdk
4096 -rw-------    1 root     root         3.1M Apr  2 08:15 ORSwin-Bremer-000002-ctk.vmdk
17408 -rw-------    1 root     root        16.1M Apr  2 08:15 ORSwin-Bremer-000002-delta.vmdk
   0 -rw-------    1 root     root          409 Apr  2 11:21 ORSwin-Bremer-000002.vmdk
4096 -rw-------    1 root     root         3.1M Apr  3 07:20 ORSwin-Bremer-000003-ctk.vmdk
115712 -rw-------    1 root     root       112.1M Apr  3 07:24 ORSwin-Bremer-000003-delta.vmdk
   0 -rw-------    1 root     root          409 Apr  3 07:20 ORSwin-Bremer-000003.vmdk
1024 -rw-------    1 root     root        27.7k Apr  2 07:03 ORSwin-Bremer-Snapshot1008.vmsn
1024 -rw-------    1 root     root        27.8k Feb  8 08:02 ORSwin-Bremer-Snapshot723.vmsn
2097152 -rw-------    1 root     root         2.0G Mar 28 15:24 ORSwin-Bremer-cd80e098.vswp
4096 -rw-------    1 root     root         3.1M Feb  8 08:02 ORSwin-Bremer-ctk.vmdk
52428800 -rw-------    1 root     root        50.0G Feb  8 08:01 ORSwin-Bremer-flat.vmdk
1024 -rw-------    1 root     root         8.5k Apr  3 07:20 ORSwin-Bremer.nvram
   0 -rw-------    1 root     root          566 Apr  2 11:21 ORSwin-Bremer.vmdk
   8 -rw-r--r--    1 root     root         1.0k Apr  2 11:21 ORSwin-Bremer.vmsd
   8 -rwxr-xr-x    1 root     root         2.8k Apr  2 08:16 ORSwin-Bremer.vmx
   0 -rw-r--r--    1 root     root          268 Mar 28 15:24 ORSwin-Bremer.vmxf
3072 -rw-r--r--    1 root     root         3.2M Mar 27 12:17 vmmcores-1.gz
4096 -rw-r--r--    1 root     root         3.3M Mar 28 13:24 vmmcores-2.gz
3072 -rw-r--r--    1 root     root         2.6M Dec 10 16:56 vmware-3.log
7168 -rw-r--r--    1 root     root         6.4M Jan 25 08:13 vmware-4.log
9216 -rw-r--r--    1 root     root         8.5M Mar 27 12:17 vmware-5.log
1024 -rw-r--r--    1 root     root       377.1k Mar 28 13:24 vmware-6.log
1024 -rw-r--r--    1 root     root       134.1k Mar 28 15:01 vmware-7.log
1024 -rw-r--r--    1 root     root       114.1k Mar 28 15:22 vmware-8.log
1024 -rw-r--r--    1 root     root       628.9k Apr  3 07:20 vmware.log
47104 -rw-------    1 root     root        46.0M Mar 28 15:24 vmx-ORSwin-Bremer-3447775384-1.vswp
6144 -r--------    1 root     root         5.4M Mar 27 12:17 vmx-zdump.000


Die VM Logdatei ziehe ich sofort nach.

Hier ist die aktuelle Logdatei:
http://dl.dropbox.com/u/15241619/vmware.log

[Dayworker]

2013-03-28T15:24:49.366Z| vmx| DICT scsi0:0.fileName = ORSwin-Bremer-000002.vmdk

Deine aktive vDISK.

2013-03-28T15:24:49.366Z| vmx| DICT memsize = 2048
...
2013-03-28T15:24:49.367Z| vmx| DICT sched.swap.derivedName = /vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer-cd80e098.vswp

Beide Angaben passen zur Grösse von "ORSwin-Bremer-cd80e098.vswp" von 2GB.

2013-03-28T18:03:05.197Z| vmx| SnapshotVMX_Consolidate: starting
2013-03-28T18:03:05.207Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer-000002-delta.vmdk" : open successful (21) size = 33660928, hd = 0. Type 8
2013-03-28T18:03:05.207Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer-000002-delta.vmdk" : closed.
2013-03-28T18:03:05.208Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer-flat.vmdk" : open successful (21) size = 53687091200, hd = 0. Type 3
2013-03-28T18:03:05.208Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer-flat.vmdk" : closed.
2013-03-28T18:03:05.209Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer_1-flat.vmdk" : open successful (21) size = 53687091200, hd = 0. Type 3
2013-03-28T18:03:05.209Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer_1-flat.vmdk" : closed.
2013-03-28T18:03:05.210Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer-000002-delta.vmdk" : open successful (21) size = 33660928, hd = 0. Type 8
2013-03-28T18:03:05.210Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer-000002-delta.vmdk" : closed.
2013-03-28T18:03:05.211Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer-000001-delta.vmdk" : open successful (21) size = 3271663616, hd = 0. Type 8
2013-03-28T18:03:05.211Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer-000001-delta.vmdk" : closed.
2013-03-28T18:03:05.212Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer-flat.vmdk" : open successful (21) size = 53687091200, hd = 0. Type 3
2013-03-28T18:03:05.212Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer-flat.vmdk" : closed.
2013-03-28T18:03:05.213Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer_1-flat.vmdk" : open successful (21) size = 53687091200, hd = 0. Type 3
2013-03-28T18:03:05.213Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer_1-flat.vmdk" : closed.
2013-03-28T18:03:05.213Z| vmx| SnapshotVMXConsolidateOnlineCB: nextState = 0 uid 0
2013-03-28T18:03:05.213Z| vmx| Turning on snapshot info cache. VM=ORSwin-Bremer.vmx.
2013-03-28T18:03:05.216Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer-000002-delta.vmdk" : open successful (21) size = 33660928, hd = 0. Type 8
2013-03-28T18:03:05.216Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer-000002-delta.vmdk" : closed.
2013-03-28T18:03:05.217Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer-flat.vmdk" : open successful (21) size = 53687091200, hd = 0. Type 3
2013-03-28T18:03:05.217Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer-flat.vmdk" : closed.
2013-03-28T18:03:05.218Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer_1-flat.vmdk" : open successful (21) size = 53687091200, hd = 0. Type 3
2013-03-28T18:03:05.218Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer_1-flat.vmdk" : closed.
2013-03-28T18:03:05.218Z| vmx| SNAPSHOT: Turning on snapshot disk cache.

Bist du dir sicher, daß dein Verzeichnislisting über ls -slh vollständig ist oder war die _1-Datei die von dir gelöschte? Ich vermute mal letzteres, was natürlich ungeschickt ist, siehe nächstes Quoting.

2013-04-02T11:21:21.894Z| vmx| SnapshotVMX_Consolidate: starting
2013-04-02T11:21:21.904Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer-000003-delta.vmdk" : open successful (21) size = 33660928, hd = 0. Type 8
2013-04-02T11:21:21.904Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer-000003-delta.vmdk" : closed.
2013-04-02T11:21:21.905Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer-flat.vmdk" : open successful (21) size = 53687091200, hd = 0. Type 3
2013-04-02T11:21:21.905Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer-flat.vmdk" : closed.
2013-04-02T11:21:21.906Z| vmx| DISKLIB-VMFS : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer_1-flat.vmdk" : failed to open (The system cannot find the file specified): Ioctl for 'ORSwin-Bremer_1-flat.vmdk' failed: No such file or directory (2). Type 3
2013-04-02T11:21:21.906Z| vmx| DISKLIB-LINK : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer_1.vmdk" : failed to open (The system cannot find the file specified).
2013-04-02T11:21:21.906Z| vmx| DISKLIB-CHAIN : "/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer_1.vmdk" : failed to open (The system cannot find the file specified).
2013-04-02T11:21:21.906Z| vmx| DISKLIB-LIB : Failed to open '/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer_1.vmdk' with flags 0x15 The system cannot find the file specified (25).
2013-04-02T11:21:21.906Z| vmx| DISKLIB-LIB : Failed to enum '/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer_1.vmdk' : 25
2013-04-02T11:21:21.906Z| vmx| SNAPSHOT: SnapshotConfigInfoExpandDisksInt: Failed to enumerate the disks for '/vmfs/volumes/50164d45-e237a1bc-07e8-00259091e89d/ORSwin-Bremer/ORSwin-Bremer_1.vmdk'.
2013-04-02T11:21:21.906Z| vmx| SNAPSHOT: SnapshotConfigInfoExpandDisks: SnapshotTreeIntIterate Error 5
2013-04-02T11:21:21.906Z| vmx| SNAPSHOT: SnapshotConfigInfoExpand SnapshotConfigInfoExpandDisks: Error 5
2013-04-02T11:21:21.907Z| vmx| SnapshotVMXConsolidateOnlineCB: nextState = 0 uid 0

Deine VM verfügte zuvor über 2 VMDKs mit Namen "ORSwin-Bremer.vmdk" und "ORSwin-Bremer_1.vmdk". Der Snapshot 000003 enthält aber noch Daten für diese VMDK und möchte jetzt zwischenzeitliche Änderungen einpflegen.
Gibt es einen bestimmten Grund, weshalb bei euch 3 aktive Snapshots vorliegen? Snapshots sind wie bereits geschrieben nur Mittel zum Zweck eines Backup und sollten für SW-Tests im Gast-OS nur mit Bedacht und in jedem Fall nur kurzzeitig eingesetzt werden.

[Nino]

vielen Dank für die schnelle Antwort. Du hast es genau richtig interpretiert. Die haupt vmdk ist die ORSwin-Bremer.vmdk und die zweite Platte die ORSwin-Bremer_1.vmdk. Die Snapshots wurden von Veeam Backup angelegt. Im Snapshot Manager steht Temporary Veeam Backup Snapshot. Den Backupjob habe ich allerdings nach der misslungenen Aktion rausgenommen. Die vmdk mit dem _1 habe ich ja nun fälschlicherweise aus dem Verzeichnis entfernt.

[Dayworker]

Brauchst du die 3 Snapshots noch?
Falls nicht, könntest du den aktuellen Datenbestand auch in eine neue VMDK clonen und würdest dir dann auch ein möglicherweise langwieriges Snapshot-Konsolidieren ersparen. Die entstehende VMDK würde dann genau dem jetzigen Datenbestand von "ORSwin-Bremer.vmdk" ohne die Snapshots entsprechen. Die "ORSwin-Bremer_1.vmdk" bleibt natürlich gelöscht.

Wenn ich dein "vmware.log" so Durchblättere, scheinst du aber bereits mehrfach die Konsolidierung angestossen zu haben. Das erklärt dann auch die relativ kleinen Snapshot-Dateien.

Poste oder besser verlinke mal bitte noch sämtliche VMSN-Dateien auf einen Freehoster. Mit etwas Glück kann man dein Problem noch andersweitig lösen. Dazu würde man dann mit etwas Vorarbeit einen weiteren Snapshot anlegen und diesen im nächsten Schritt sogleich wieder löschen.

[Nino]

Für mich ist nur wichtig, dass mir keine aktuellen Daten verloren gehen, da der Server wie gesagt produktiv läuft.
Zu besseren Verständnis, ist es so, dass die Snapshots alle Änderungen zum letzten Snapshot enthalten bzw. zur haupt vmdk ? Tut mir leid, dass ich so dumm fragen muss (Gibt es vielleicht eine gute Lektüre, in der man Snapshots verstehen kann ?). Theoretisch brauche ich die Snapshots nicht mehr, wenn ich den aktuellen Datenbestand in eine neue vmdk übernehmen kann.

Hier die vmsn Dateien:

http://dl.dropbox.com/u/15241619/ORSwin-Bremer-Snapshot723.vmsn

http://dl.dropbox.com/u/15241619/ORSwin-Bremer-Snapshot1008.vmsn

[Dayworker]

Die VMSNs waren hilfreich. Darin sieht man, daß du der VM unter scsi0:1 die Platte mit _1 im Namen zugewiesen hattest.
Lad mal bitte noch die 1KB-grosse VMSD-Datei hoch. Darin sollte sich die Snapshotkette nachvollziehen lassen.

[Nino]

Guten Morgen,

hier die vmsd Datei:

http://dl.dropbox.com/u/15241619/ORSwin-Bremer.vmsd

[Dayworker]

Ich bin mir über die Folgen nicht sicher, wenn du aus der Datei den Eintrag für die _1-Platte entfernst. Da die VM produktiv läuft, würde ich dort jedoch kein Risiko eingehen wollen.

[Nino]

Wir haben zwar noch ein Backup der Datenbank die in der Vm läuft aber ich will es auch nicht heraufbeschwören. Meinst du beide Zeilen aus der vmsd Datei löschen ?

Code: Alles auswählen

snapshot0.disk1.fileName = "ORSwin-Bremer_1.vmdk"
snapshot0.disk1.node = "scsi0:1"


[Nino]

Ich habe jetzt gerade im Veeam Forum gelesen, dass wenn man Snapshots im vSphere client löscht, die Daten automatisch in den vorherigen Snapshot bzw in die Basis vmdk übernommen werden. Wenn dies so wäre, könnte ich dann nicht die Snapshots löschen ohne einen Datenverlust zu bekommen ?

Hier der Link zum Post:

http://forums.veeam.com/viewtopic.php?f=2&t=1040

[Dayworker]

Den Snapshot kannst du ja gerade nicht mehr löschen, da es eine gewisse VMDK nicht mehr gibt und die Snapshot-Konsolidierung deswegen scheitert.
Ich bin jetzt allerdings mit solchen Feinheiten bei Snapshots überfragt, da Snapshots bei mir nur höchst selten überhaupt zum Einsatz kommen und sie ansonsten nur Mittel zum Zwecke eines Backups sind.
In meinen Augen bringt dir jetzt auch kein neuer Snapshot etwas, denn sobald du diesen Snapshot in die Basis-VMDK einpflegen willst, stolpert VMware ja wieder über die fehlende VMDK. Wenn die bereits wieder gelöschte VMDK nur leer und vor allem ohne Dateisystem war, könnte man vermutlich auch wieder eine VMDK gleichen Namens, gleichen VMDK-Typs und gleicher Grösse erstellen.
Die sicherste Lösung wäre, den unbedingten Weiterbestand der Snapshots zu klären, dann Wartungszeit zu beantragen und die VMDK über die vmkfstools mit dem jetzigen Datenbestand an einen anderen Ort zu clonen. Im nächsten Schritt würde man dann die entstandene VMDK anstatt der alten in die VMX-Datei eintragen und über einen VM-Start das Vorhandensein aller Daten überprüfen. Falls das klappt, kannst du entweder alle VMDKs im alten Ordner löschen und die neufunktionale VMDK an ihren alten Ort clonen oder du verschiebst alle Einstellungsdateien in den Ordner mit der neufunktionalen VMDK. In beiden Fällen würde ich die VMX-Datei erneut bearbeiten und an die lokale Gegebenheit anpassen, sprich den Pfad vor dem neufunktionalen VMDK-Namen löschen. Wenn du alle Einstellungsdateien in den Ordner mit der neufunktionalen VMDK verschoben hast, mußt du die VM einmal nur aus dem Inventory aufnehmen und wieder hinzufügen. Ich würde aber die erste Methode wählen und die neufunktionale VMDK an ihren alten Ort clonen. Dann sollte Veeam auch keine Probleme haben und seinen normalen Sicherungsrhythmus wieder aufnehmen.

[Nino]

Vielen Dank für die Lösungsvorschläge. Wenn ich mir deinen 1. Lösungsvorschlag angucke, ich habe noch eine Sicherungskopie der gelöschten vmdk und allen dazugehörigen Dateien mit _1. Würde es auch helfen diese einfach wieder in den DS zu legen und dann nochmal zu versuchen sie richtig zu entfernen?

[Dayworker]

Das könnte klappen. Es müßte sogar ausreichen, nur die _1.vmdk und die _1-flat.vmdk zurückzuspielen und dann alle bestehenden Snapshots zu löschen.
Dabei würden dann alle Änderungen in die jeweilige Bais-VMDK eingepflegt und die _1-VMDK kann danach wieder gefahrlos gelöscht werden.

Es ist also immer etwas unglücklich, wenn man bei bestehenden Snapshots Veränderungen an den Datenträgern vornimmt. Weshalb aber der ESXi dem nicht Einhalt geboten hat, kann ich dir leider nicht beantworten.

[Nino]

Dann werde ich mal sehen, dass ich ein Wartungsfenster bekomme. Ich würde dann folgendermaßen vorgehen.

- Die betroffene VM Herunterfahren ggf. noch weitere um ausreichend Platz im DS zu haben
- Die Orginaldateien wieder in das Verzeichnis übertragen
- Danach die VM wieder hochfahren oder nicht ? Er gibt mir ja jetzt die Meldung, dass konsolidiert werden muss, soll ich den Vorgang dann ausführen ?
- Anschließend würde ich dann die Snapshots entfernen, hier ist noch die Frage jeden einzelnd oder über den Button "Alle löschen" (VM ein oder ausschalten ?)?
- Dann würde ich die vmdk wieder in die VM einbinden und dann wieder mit der Option "Aus dem DS entfernen" löschen. Dann natürlich wie du geschrieben hast bei ausgeschalteter VM

Könntest du über den Ablauf nochmal drüberschauen ?

[Dayworker]

Snapshots können genauso groß, wie die Ursprungsplatte werden. Du solltest also mindestens diesen Platz freihaben.
Die VM brauchst du auch nicht wieder hochfahren. Du sagst, daß die Snapshots nicht mehr gebraucht werden, dann kannst du alle auch in einem Rutsch löschen. Paß dabei aber auf, daß du die richtige Schaltfläche erwischst. VMware ist rigoros beim löschen und weg bleibt weg.
Die Konsolidierungsmeldung kann ich leider in keiner Log-Datei finden. Richtig problematisch bei der ganzen Sache ist, daß du solange Veeam keinen Snapshot erstellen kann, du auch kein Backup dieser VM haben kannst. Im bestehenden "vmware.log" wird bereits "ORSwin-Bremer-Snapshot1009.vmsn" aufgelistet. Bei welcher aktuellen Nummer ist die VM jetzt angekommen?


Mir ist bei erneuter Durchsicht deines "vmware.log" aufgefallen, daß es immer nur an der gelöschten VMDK scheitert. Wenn man diese zurückspielt, kann man alle Snapshots löschen und die bereits zuvor gelöschte _1-VMDK wieder löschen. Dazu muß diese dann noch nicht mal in die VMX-Datei aufgenommen werden, denn in der VMX- und auch in der letzten von dir hochgeladenen VMSN-Datei taucht diese ja schon nicht mehr auf. Lediglich der Snapshot selbst enthält jetzt nicht mehr benötigte Daten oder auch nur noch einen Verweis auf diese Datei.
Wenn ich damit Recht habe und nichts schief geht, dürfte die Wartungszeit erfreulich kurz werden. Ich probiere da mal noch etwas auf meinem System aus.

Ausgehend von deinem bisherigen Verzeichnis-Listing enthalten die Snapshots nur wenige Schreibanforderungen. Wie groß war eigentlich die _1-VMDK? Reicht der Platz für alles aus, ohne das du andere VMs erst verschieben mußt?

[Nino]

Hallo, vielen Dank für die schnelle Antwort und das nachbauen. Dann werde ich es so machen wie von dir beschrieben. Ich spiele die vmdk zurück und lösche dann die Snapshots. Dann lösche ich die vmdk wieder und fahre die VM wieder hoch.
Die _1 vmdk war auch 50 Gb groß. Wenn ich alle VMs herunterfahre komme ich ca. auf die hälfte Platz im DS. Meinst du das könnte reichen ?

Schönes Wochenende

Gruß

[Dayworker]

Okay, gleiches Verhalten auch bei mir.

1. VM mit bestehenden Snapshot eine weitere vDISK zugewiesen und dann einen manuellen Snapshot ausgelöst. Als nächstes dann diese zweite vDISK aus der VM-Config wieder rausgenommen und erneuten einen Snapshot probiert zu erstellen. Dieses schlägt jedoch aufgrund der gelöschten zweiten vDISK immer fehl und noch viel ärgerlicher ist es, daß nach dem manuellen Editieren der Snapshotketten-Datei (VMSD) und auslösen eines erneuten Snapshots die VM sogar reproduzierbar abstürzt...
   
2. Erneut einer VM einen zweiten Datenträger gegeben, einen Snapshot ausgelöst und danach den Datenträger nur aus der VM-Config genommen. Wenn man jetzt einen Snapshot erstellt, kommt die Konsolidierungsmeldung und der Snapshot wird erstellt.
   
3. Erneut einer VM einen zweiten Datenträger gegeben, einen Snapshot ausgelöst und danach den zweiten Datenträger aus der VM-Config genommen sowie aus dem Ordner gelöscht.
   Solange die gelöschte VMDK noch irgendwo einen Eintrag im Snapshot hat, kann man keinen neuen Snapshot erstellen. Selbst wenn die VM abgeschaltet ist, bekommt man das nicht hin. Man erhält sogar noch die VMDB- und eine weitere Meldung, daß eine Datei nicht gefunden werden konnte.
   Gelöschte, noch mit dem Snapshot versehe VMDK nur wieder an ihren ursprünglichen Ort zurückkopiert und schon läßt sich ein Snapshot wieder anlegen. In diesem Zustand läßt sich dann auch der Snapshot wieder löschen, da die bereits gelöschte VMDK ja nicht mehr Bestandteil der VM-Config ist.
   
4. Selbe Vorgehensweise wie bei Versuch 3 und anstatt die als fehlend monierte VMDK wieder zurückzuspielen, einfach bei laufender VM nur die VMSD verschoben.
   VM läßt jetzt einen Snapshot wieder zu bzw ein Snapshot läßt sich jetzt auch wieder löschen.

[Dayworker]

@Nino
Ausgehend von meinen letzten Versuchen, ist in deinem Fall die einfachste Möglichkeit, nur die VMSD-Datei zu löschen. Dabei bleibt der jetzige Datenbestand erhalten und du kannst dann auch wieder Snapshots anlegen und löschen.

[Nino]

Hey danke. Einfach die vmsd rauslöschen ohne die Maschine herunterzufahren oder sonst irgendwas zu beachten ?
Gruß

[Dayworker]

Beachten mußt du da nichts weiter. Ich würde aber trotzdem Wartungszeit beantragen und diese auf höchste Priorität setzen. Da der Platz zum Zurückkopieren der Original-VMDK nicht ausreicht und ich mir auch nicht 100%ig sicher bin was passiert, wenn man eine schnellformatierte Thin-VMDK gleichen Namens und Grösse anstelle des Original hochlädt, habt ihr momentan überhaupt kein Backup mehr.

Die VMSD-Datei löschen ging bei mir auch bei laufender VM. Nach Auslösen eines Snapshot wurde halt eine neue VMSD-Datei angelegt und die bestehenden konsolidiert. Ich würde aber wegen des fehlenden Backups nichts riskieren und dann bei abgeschalteter VM sowohl die VMSD löschen als auch neuen Snapshot anlegen und gleich wieder löschen. Dann ist die VM snapshotfrei und hat immer noch den gleichen Datenbestand.

[Nino]

Okay so werde ich es machen. Ich schalte also die VM ab und lösche die vmsd Datei. Danach erstelle ich ein neuen Snapshot. Die zwei bestehenden Snapshots werden dann automatisch mit dem 3. konsolidiert, habe ich richtig verstanden ?? Ich brauche da auch jetzt bald eine Lösung, weil mir der DS weiter voll läuft, ich schätze mal , das es an nicht gelöschten Snapshots von dem Veeam B&R liegt.

[Dayworker]

Wegen dem Platzproblemen hatte ich dir ja die Wartungszeit auch mit höchster Priorität empfohlen.
Wenn du die VMSD-Datei löschst, sieht der ESXi nur noch die VMDK-Einträge in der VMX-Datei. Beim manuellen Anlegen eines weiteren Snapshots wird die VMX-Datei vom ESXi auf den neuen Snap umgeschrieben. Wenn du dann den oder in deinem Fall alle Snaps löschst, startet die Konsolidierung. Das Ergebnis ist dann eine snapshotfreie VMDK mit dem Datenbestand zum Zeitpunkt des VM-Shutdowns.

[continuum]

Hallo
sorry - hatte wenig Zeit heute.

Falls es noch akut ist - ich denke mann kann die zweite Platte auch ausserhalh der laufenden VM zusammensetzen und konsolidieren.
Bei Bedarf schau ich mal vorbei