Virtuelle Festplatte aus DS entfernen

[Dayworker]

Sein Problem ist eine bereits willentlich gelöschte VMDK, die nicht mehr in der VMX- sondern nur noch in der VMSD-Datei auftaucht. Dadurch kann er momentan keine Snaps erstellen oder löschen und sein DS läuft daher voll.
Ich hab testhalber probiert meine VMSD bei laufender VM zu editieren und wurde danach bei Snapshoten mit einem VM-Absturz bedacht.

[Nino]

Hallo

ich habe es noch nicht durchgeführt, aber werde es heute Abend wie beschrieben tun, dann habe ich etwas Wartungszeit.

[Dayworker]

Je nach Grösse der Snapshots kann das Konsolidieren geraume Zeit in Anspruch nehmen, also nicht gleich schreinen, wenn es eine Stunde dauert und unabhängig von der Plattenperformance werden die restlichen auf diesem ESXi-Server laufenden VMs massiv ausgebremst, da die Konsolidierung jedes IO anfordert.
Verhindern liese sich diese Bremse nur, wenn man ein Storage hat und für einzelne Aktivitäten Grenzen setzen kann.

[Nino]

Ich konnte die Konsolidierng der betroffenen VM heute leider nicht durchführen, da das Backup der Datenbank, die in der VM läuft, fehlgeschlagen ist. Ich werde dies dann Morgen Abend erneut versuchen. Ich konnte allerdins die Snapshots der anderen Maschinen erfolgreich konsolidieren und habe so wieder ca 70 GB im DS frei. Alle Maschinen laufen einwandfrei und Veeam führt die Backupjobs korrekt aus. Wie gesagt ich werde die verbleibende VM dann morgen bearbeiten. Vielen Dank für die Hilfe schonmal bis hierhin.

[Dayworker]

Hast du rausbekommen, weshalb das Backup fehlgeschlagen ist?

[Nino]

Ich habe leider keinen Vollzugriff auf den Server, aber ich denke mal der Admin hat den falschen Backup Pfad verwendet.

[Dayworker]

Mit welchem Produkt sichert ihr die DB innerhalb der VM, wenn ihr die VMDKs über Veeam sichert?
Eventuell konnte die DB auch deshalb nicht gesichert werden, weil die VMware-Tools keinen konsistenten Zustand erreichen konnten. So ein Fall könnte dann existieren, wenn der Snapshot über die Tools und dessen Verlängerung VMware-VSS-Writer die DB nicht zum Leeren ihres Caches bewegen kann. Ich hab keine Doku zur Hand, inwieweit oder welcher Art die Strecke Snapshot -> VMware-Tools -> VMware-VSS-Writer auch Rückmeldungen bzw Kommunikation in die Gegenrichtung zuläßt.

[Nino]

Ich habe die Schritte gestern Abend nun ausführen können. Das fehlgeschlagene Backup lag tatsächlich an einem falschen Pfad. Nach der Ausführung lief die Maschine wieder wie gewohnt hoch und die Snapshots wurden erfolgreich konsolidiert. Die Fehlermeldungen im vSphere Client sind verschwunden. Ich habe danach nochmal in das Verzeichnis der VM auf dem ESXi Host geschaut und dort liegen die Snapshot Dateien noch. Gibt es eine Möglichkeit diese auch noch loszuwerden. Damit Veeam nach der Konsolidierung wieder korrekt sichert muss man das Changed Block Tracking der VM zurücksetzen wie hier beschrieben:

http://www.veeam.com/kb1113

leider weiß ich bei der betroffenen VM nicht genau welche Dateien ich im Verzeichnis löschen kann, da dort mehrere ctk Dateien liegen, die noch zu den alten Snapshot Dateien gehören.

[Nino]

Hier sind nochmal die Dateien des Verzeichnisses:

Code: Alles auswählen

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
   0 -rw-r--r--    1 root     root           13 Apr 11 18:44 ORSwin-Bremer-aux.xml
4194304 -rw-------    1 root     root         4.0G Apr 11 18:44 ORSwin-Bremer-cd80e098.vswp
4096 -rw-------    1 root     root         3.1M Apr 11 18:45 ORSwin-Bremer-ctk.vmdk
52428800 -rw-------    1 root     root        50.0G Apr 12 07:28 ORSwin-Bremer-flat.vmdk
1024 -rw-------    1 root     root         8.5k Apr 11 23:10 ORSwin-Bremer.nvram
   0 -rw-------    1 root     root          566 Apr 11 18:44 ORSwin-Bremer.vmdk
   0 -rw-r--r--    1 root     root           43 Apr 11 18:44 ORSwin-Bremer.vmsd
   8 -rwxr-xr-x    1 root     root         2.8k Apr 11 18:45 ORSwin-Bremer.vmx
   0 -rw-r--r--    1 root     root          268 Apr 11 18:42 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
1024 -rw-r--r--    1 root     root       111.1k Apr 11 18:19 vmware-10.log
1024 -rw-r--r--    1 root     root       111.8k Apr 11 18:43 vmware-11.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       687.8k Apr 11 17:53 vmware-9.log
1024 -rw-r--r--    1 root     root        95.4k Apr 11 18:46 vmware.log
47104 -rw-------    1 root     root        46.0M Apr 11 18:44 vmx-ORSwin-Bremer-3447775384-1.vswp
6144 -r--------    1 root     root         5.4M Mar 27 12:17 vmx-zdump.000


[Dayworker]

Ausgehend von deinem letzten Verzeichnislisting würde ich nur die beiden alten VMSNs (ORSwin-Bremer-Snapshot1008 und ORSwin-Bremer-Snapshot723), beide vmmcores-1/2.gz und den vmx-zdump.000 löschen.
Beide VSWP-Dateien und sämtliche "vmware.log" dagegen würde ich in Ruhe lassen.

Wenn du dich genau an deinen Veeam KB-Eintrag How to reset CBT hältst, kannst du nach Abschalten von CBT und den dazu nötigen VM-Shutdowns und -Restarts zur Übernahme neuer CBT-Einstellungen, alle CKT-Dateien löschen. Im neunten und letzten Schritt kannst du dann wieder neue CBT-Einstellungen vornehmen.

[Nino]

Hallo,

vielen Dank für die Antworten. ich habe mein Problem nach deiner Anleitung nun vollständig lösen können. Hat alles geklappt wie beschrieben. Vielen Dank