VMware-Forum

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).



Danke und Grüße,
Johannes

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

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.

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...

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 ....

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

zu

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

Danke und Grüße,
Johannes

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