Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!

Korrupte ctk.vmdk in Datastore

Moderatoren: irix, Dayworker

Member
Beiträge: 25
Registriert: 16.02.2009, 22:11

Korrupte ctk.vmdk in Datastore

Beitragvon basstscho » 03.11.2016, 07:20

Hallo zusammen,

nach einem Systemabsturz sind auf einem Datastore eines ESXi 5.5 zwei defekte *-ctk.vmdk-Dateien vorhanden. Allerdings auf eine etwas ungewöhnliche Art: Es sieht so aus, als ob das Dateisystem die Datei noch gelinkt hat, diese aber nicht vorhanden ist. Zumindest interpretiere ich den ls und das rm so. Hat jemand von euch ein Idee, wie ich diese Datei gelöscht bekomme? Die VM ist mittlerweile umgezogen und ich würde gerne den gesamten Ordner löschen (geht auch, bis auf die eine Datei).

Bild

Danke und Grüße,
Johannes

Member
Beiträge: 186
Registriert: 01.12.2015, 18:35

Beitragvon Stefan.r » 03.11.2016, 08:39

kannst du im notfall den ESX restarten?, sollange nix auf den Pfad zugreift kannste den ordner eigentlich schmerzfrei mit "rm -rf" oder halt winscp löschen

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 03.11.2016, 13:45

Bevor er den ESXi komplett rebootet, würde ich es erstmal mit dem Re-Start der Management-Services probieren. Das geht bedeutend schneller und Neustarten kann er danach ja immer noch, falls das doch nicht ausreicht.

Experte
Beiträge: 1823
Registriert: 04.10.2011, 14:06

Beitragvon JustMe » 03.11.2016, 17:24

Ich persoenlich wuerde meinen, dass der erwaehnte "Systemabsturz" als ESXi-Reboot eigentlich ausreichen sollte, um eventuelle Locks zu loeschen...

Hier wird vmtl. tatsaechlich was im VMFS durcheinander geraten sein.

Entweder kann "continuum" helfen, oder man verschafft sich mit Using vSphere On-disk Metadata Analyzer (VOMA) to check VMFS metadata consistency erst einmal einen Ueberblick. Ganz Mutige koennten auch versucht sein, mit einem ESXi6-Boot die Repair-Funktion zu testen...

Benutzeravatar
UNSTERBLICH(R.I.P.)
Beiträge: 14759
Registriert: 09.08.2003, 05:41
Wohnort: sauerland
Kontaktdaten:

Beitragvon continuum » 03.11.2016, 19:35

Die VM ist mittlerweile umgezogen und ich würde gerne den gesamten Ordner löschen (geht auch, bis auf die eine Datei).


Hast du deinem automatischem Backuptool von dem Umzug erzählt ?
Du solltest zur Sicherheit die CTK-vmdks der besagten VM neu erstellen lassen.
Siehe
https://www.veeam.com/de/kb1113
- Das Verfahren passt auch wenn du kein Veeam verwendest.
Vor dem Wiederanschalten der VM in Schritt 6 sollten sich auch die ctk-vmdks löschen lassen.
Nach neuem Start der VM solltest du ein Vollbackup erstellen - es könnte gut sein, dass die letzten inkrementellen Backups sich nicht wiederherstellen lassen.

Ganz Mutige koennten auch versucht sein, mit einem ESXi6-Boot die Repair-Funktion zu testen...

Für meinen Geschmack hat dass mit Mut nichts zu tun - ich würde das eher Sabotage-Versuch nennen und kann nur dringend davon abraten.
Im Zweifelsfall ruf lieber an - nach meiner Erfahrung wird der Schaden mit der genannten Funktion eher schlimmer !

.... VOMA

Meiner Ansicht nach hat VOMA nur eine einzige Funktion: das Gewissen der VMFS-Entwickler zu beruhigen. In der Recoverypraxis verwende ich es praktisch überhaupt nicht und IMHO sind die Diagnose-Resultate für die meisten User nicht hilfreich.
Allein die Voraussetzungen für den VOMA-einsatz an sich sind schon daneben.
Ein Diagnosetool sollte auch während eines Produktiveinsatzes ensetzbar sein - ansonsten macht es keinen wirklichen Sinn. Was hat man von einer Diagnose mit unbrauchbaren, kryptischen Aussagen, wenn man dafür die Produktion lahm legen muss und dann trotzdem keine wirkliche "Repairfunktion" bekommt ?
IMHO wird VOMA komplett überbewertet - wie gesagt ich benutze es praktisch nie ....

Member
Beiträge: 25
Registriert: 16.02.2009, 22:11

Beitragvon basstscho » 04.11.2016, 07:04

Guten Morgen,

besten Dank für die Rückmeldungen. Ein einfaches Löschen mittles rm -rf funktioniert nicht. Neugestartet wurde der ESXi zwischenzeitlich auch (der Systemabsturz ist schon eine Weile her).
Ich vermute leider auch fast, dass es ein Problem mit dem Dateisystem ist. Von daher wird wohl langfristig nur ein Formatieren etwas bringen.

Es gibt noch eine Test-VM auf dem System, die das selbe Verhalten aufzeigt. Diese würde ich nun aber gerne kurzfristig mit ins Backup aufnehmen und daher natürlich auch gerne CBT aktivieren. Dies schlägt allerdings immer fehl. Vermutlich, weil die -CTK.vmdk nicht anständig schreib/lesbar ist. Spricht etwas dagegen, wenn ich in der .vmdk einfach den Eintrag der Korrupten ctk.vmdk

Code: Alles auswählen

changeTrackPath="hdd-ctk.vmdk"

zu

Code: Alles auswählen

changeTrackPath="hdd-neu-ctk.vmdk"

abändere? Natürlich zunächst VM herunterfahren, über die config deaktivieren und dann aktivieren und abändern.

Danke und Grüße,
Johannes

Benutzeravatar
UNSTERBLICH(R.I.P.)
Beiträge: 14759
Registriert: 09.08.2003, 05:41
Wohnort: sauerland
Kontaktdaten:

Beitragvon continuum » 04.11.2016, 07:57

Deine Vorschläge machen keinen Sinn.
Wenn "irgendwas" beim Change-block-tracking" nicht klappt - dann sind entweder in deinem Backuptool noch VMDKs gemountet - die schon lange wieder unmountet sein sollten - oder mit den vmware-tools in der betroffenen VM stimmt was nicht ....
Die Lage würde duch die Änderung des Pfades nicht besser denn schon mit dem aktuellen Pfad stimmt etwas nicht.
Was verwendest du denn für die Backups ?
Probier das Verfahren aus der Veeam-knowledgebase


Zurück zu „vSphere 5.5 / ESXi 5.5“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 9 Gäste