ESXI 6.5 Fehlgeschlagen - Zugriff auf eine Datei nicht möglich, weil sie gesperrt ist
Hallo Zusammen,
da meint man es gut und dann geht es in die Hose...
Aber erst mal zum IST-Zustand:
- ESXI 6.5 U1 (Standalone)
- VM 2016 mit drei VM-HDDs auf zwei verschiedenen Datastorage intern
- Zwei manuell erstellte Snaps im Abstand von zwei Tage
- Laufendes Veeam 9.5 Backup
Was ist passiert?
Wie oben beschrieben, habe ich im Abstand von 24 Stunden zwei manuelle Snaps gemacht. Im Hintergrund hat Veeam dann noch seinen Backup-Auftrag, als Task ausgeführt. Das ging wohl vor 48 Stunden noch gut! Jedoch letzte Nacht hat wohl der ESXI den Befehl zum löschen des erstellten Snap von Veeam nicht richtig empfangen, warum auch immer.
Nun habe ich diese Ansicht in der Snap-Verwaltung der VM:
Konsolidierung oder Snaps löschen, schlägt fehlt, egal ob einzeln/alle...
Versucht habe ich schon:
Removing Stuck VMDK’s from the Veeam Proxy ohne Erfolg.
Neustart ESXI brachte natürlich auch nichts. Hat jemand eine Idee?
PS: Veeam Backup schlägt natürlich fehlt, habe ich gestoppt, also den Task...
Wenn jemand noch ein paar Info brauch, dann einfach fragen.
Danke
da meint man es gut und dann geht es in die Hose...
Aber erst mal zum IST-Zustand:
- ESXI 6.5 U1 (Standalone)
- VM 2016 mit drei VM-HDDs auf zwei verschiedenen Datastorage intern
- Zwei manuell erstellte Snaps im Abstand von zwei Tage
- Laufendes Veeam 9.5 Backup
Was ist passiert?
Wie oben beschrieben, habe ich im Abstand von 24 Stunden zwei manuelle Snaps gemacht. Im Hintergrund hat Veeam dann noch seinen Backup-Auftrag, als Task ausgeführt. Das ging wohl vor 48 Stunden noch gut! Jedoch letzte Nacht hat wohl der ESXI den Befehl zum löschen des erstellten Snap von Veeam nicht richtig empfangen, warum auch immer.
Nun habe ich diese Ansicht in der Snap-Verwaltung der VM:
Konsolidierung oder Snaps löschen, schlägt fehlt, egal ob einzeln/alle...
Remove All Snapshots
Schlüssel
haTask-8-vim.VirtualMachine.removeAllSnapshots-188591317
Beschreibung
Entfernen Sie alle Snapshots, die dieser virtuellen Maschine zugeordnet sind.
Virtuelle Maschine:
2.11-FS-ELO
Zustand
Fehlgeschlagen - Ein allgemeiner Systemfehler ist aufgetreten: vim.fault.GenericVmConfigFault
Fehler
Versucht habe ich schon:
Removing Stuck VMDK’s from the Veeam Proxy ohne Erfolg.
Neustart ESXI brachte natürlich auch nichts. Hat jemand eine Idee?
PS: Veeam Backup schlägt natürlich fehlt, habe ich gestoppt, also den Task...
Wenn jemand noch ein paar Info brauch, dann einfach fragen.
Danke
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 643478
Url: https://administrator.de/contentid/643478
Ausgedruckt am: 22.11.2024 um 01:11 Uhr
5 Kommentare
Neuester Kommentar
Moin,
hatte jüngst, glaube ich, ähnlichen Fall.
Allerdings bei uns nicht mit VEEAM sondern einem anderen Backup-Tool.
Die Fehlermeldung war zwar eine andere, klingt aber alles danach.
Der Sicherungsproxy, der zwischen VMware und der Backup-Software hängt, hatte einen Snapshot gesperrt (also eine vmdk).
Ich habe dann den Proxy heruntergefahren, geschaut, welche vmdks der so gemountet hat, die vmdk aus dem Proxy entfernt und danach konnte ich die eigentliche VM wieder konsolidieren.
Ich hatte bei uns mir nen Wolf gesucht, was di Ursache ist.
Per CLI kann man herausfinden, welche MAC-Adresse welche VMDK sperrt
Hier kannst du mal schauen, wie das klappt:
https://kb.vmware.com/s/article/10051
die MAC war dann einer unserer Host. Dachte mir 'alles klar, den Host von allen VMs befreien, neu starten und gut" Allerdings wanderte die MAC-Adresse mit dem Sicherungsproxy (das ist auch eine VM)... Bis ich das aber herausfand, dass die VM der Übeltäter war...
Egal, versuche obiges:
VEEAM-Server herunterfahren und prüfe, ob da noch irgendeine VMDK gelocked ist.
Danach mal weiter schauen.
Edit: Ich sehe gerade, dass der Link oben quasi das trennen der VMDK beinhaltet. Hätte ich mal eher schauen sollen ^^
Aber den VEEAM-Server würde ich trotzdem einmal herunterfahren. Sicher ist sicher.
Gruß
em-pie
hatte jüngst, glaube ich, ähnlichen Fall.
Allerdings bei uns nicht mit VEEAM sondern einem anderen Backup-Tool.
Die Fehlermeldung war zwar eine andere, klingt aber alles danach.
Der Sicherungsproxy, der zwischen VMware und der Backup-Software hängt, hatte einen Snapshot gesperrt (also eine vmdk).
Ich habe dann den Proxy heruntergefahren, geschaut, welche vmdks der so gemountet hat, die vmdk aus dem Proxy entfernt und danach konnte ich die eigentliche VM wieder konsolidieren.
Ich hatte bei uns mir nen Wolf gesucht, was di Ursache ist.
Per CLI kann man herausfinden, welche MAC-Adresse welche VMDK sperrt
Hier kannst du mal schauen, wie das klappt:
https://kb.vmware.com/s/article/10051
die MAC war dann einer unserer Host. Dachte mir 'alles klar, den Host von allen VMs befreien, neu starten und gut" Allerdings wanderte die MAC-Adresse mit dem Sicherungsproxy (das ist auch eine VM)... Bis ich das aber herausfand, dass die VM der Übeltäter war...
Egal, versuche obiges:
VEEAM-Server herunterfahren und prüfe, ob da noch irgendeine VMDK gelocked ist.
Danach mal weiter schauen.
Edit: Ich sehe gerade, dass der Link oben quasi das trennen der VMDK beinhaltet. Hätte ich mal eher schauen sollen ^^
Aber den VEEAM-Server würde ich trotzdem einmal herunterfahren. Sicher ist sicher.
Gruß
em-pie
Zitat von @zeroblue2005:
Wenn der Backupproxy nicht sperrt? Wie geht es jetzt weiter? Ich habe schiess, mir die Maschine zu zerschissen
Nachvollziehbar.Wenn der Backupproxy nicht sperrt? Wie geht es jetzt weiter? Ich habe schiess, mir die Maschine zu zerschissen
Kannst du ein Backup der VM erstellen, irgendwie auf File-Ebene?
Also mit Knoppix oder ähnlichem?
Sprich: die VM über eine LiveDistribution starten und dann sichern.
Dann ist die Kiste schon mal gesichert. Zuvor noch RAM und CPU-Daten notieren, sowie größe und Anzahl der einzelnen VMDKs
Somit kannst du im schlimmsten Fall eine neue VM aufsetzen, und die Daten dann wieder zurückschieben.
Wird aber vermutlich dauern, da es ja - so wie ich es mal deute - ein DMS von ELO ist!?
Wenn das Backup steht, geht es weiter.
- SSH auf dem Host aktivieren.
- mit Putty dorthin verbinden
- für jede gefundene VMDK einmal folgendes ausführen (hier am Beispiel einer vmdk):
vmfsfilelockinfo -p /vmfs/volumes/5f81b172-35b3eb22-e104-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_2-flat.vmdk
Die Ausgabe müsste dann irgendwo eine MAC-Adresse ausspucken.
Anschließend schauen, wo die MAC-Adresse hingehört..
Bzw. schauen, welche vmdk gesperrt ist, den dahinter stehenden Prozess identifizieren und der Prozess gibt dann auskunft, welche VM der Übeltäter ist.
Am besten, den o.g. Link einmal durchackern: https://kb.vmware.com/s/article/10051
den habe ich auch noch gefunden:
https://www.veeam.com/de/kb1681
Hier "spannend": Entferne mal nach und nach die Snapshots (NACHDEM du die VM gesichert hast)...
Anschließed
Ich hasse es, in den ESXI Eingeweiden rum zu fummeln bzw. mit CLI wenn es sich irgendwie umgehen lässt. Ausschlag gaben mir deine Worte VM-Sichern...
Ich bin da auch immer vorsichtig, ein falscher Parameter und man ist am Ar*** In dem obigen Skripten "guckst" du aber nur, und führst keine Änderungen durch.
Aber mit einem "anderen" Backup und wenigen Daten geht das ja auch.
Wenn man allerdings eine VM mit mehreren TBs hat, überlegt man sich das zweimal, bis alles gesichert ist
Snapshots durch einen selber + die der Backup-Software sind kein Problem. Man sollte halt nur mit dem eigenen warten, bis der Backup-Job durch ist und die Software (VEEAM, Arcserve, IBM SP, ...) den eigenen Snapshot nach erfolgreicher Sicherung selbst wieder gelöscht hat.
Dann kannst du abschließend ja jetzt
Wie kann ich einen Beitrag als gelöst markieren?
machen