5
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
FehlerVersucht 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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 643478
Url: https://administrator.de/forum/esxi-6-5-fehlgeschlagen-zugriff-auf-eine-datei-nicht-moeglich-weil-sie-gesperrt-ist-643478.html
Ausgedruckt am: 22.12.2024 um 10:12 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
Hallo em-pi,
ich habe alle Veeam-Server (Zwei Stück) ausgeschaltet. Dann den ESXI mal durchgestartet. Leider scheint der Backup-Proxy nicht die Snaps zu sperren, den der Versuch, nach dem Neustart die Snaps zu löschen, ohne das die VMs gestartet sind, schlug fehl. Ich habe mal die Log mir angesehen:
hier bei ist mir dann das ins Auge gefallen:
Wenn der Backupproxy nicht sperrt? Wie geht es jetzt weiter? Ich habe schiess, mir die Maschine zu zerschissen
ich habe alle Veeam-Server (Zwei Stück) ausgeschaltet. Dann den ESXI mal durchgestartet. Leider scheint der Backup-Proxy nicht die Snaps zu sperren, den der Versuch, nach dem Neustart die Snaps zu löschen, ohne das die VMs gestartet sind, schlug fehl. Ich habe mal die Log mir angesehen:
2021-01-23T07:55:30.517Z| svga| I125: MKSScreenShotMgr: Taking a screenshot
2021-01-23T07:55:40.505Z| vmx| I125: VigorTransportProcessClientPayload: opID=602f635c seq=849: Receiving Snapshot.Delete request.
2021-01-23T07:55:40.611Z| vmx| I125: SNAPSHOT: SnapshotDeleteWork '/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/2.11-FS-ELO-xxx-GMH.vmx' : 2
2021-01-23T07:55:40.611Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH-000004-sesparse.vmdk" : open successful (21) size = 3274903552, hd = 0. Type 19
2021-01-23T07:55:40.611Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH-000004-sesparse.vmdk" : closed.
2021-01-23T07:55:40.611Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH-000003-sesparse.vmdk" : open successful (21) size = 3845578752, hd = 0. Type 19
2021-01-23T07:55:40.611Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH-000003-sesparse.vmdk" : closed.
2021-01-23T07:55:40.612Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH-000002-sesparse.vmdk" : open successful (21) size = 2435977216, hd = 0. Type 19
2021-01-23T07:55:40.612Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH-000002-sesparse.vmdk" : closed.
2021-01-23T07:55:40.612Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH-flat.vmdk" : open successful (21) size = 107374182400, hd = 0. Type 3
2021-01-23T07:55:40.612Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH-flat.vmdk" : closed.
2021-01-23T07:55:40.612Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_1-000004-sesparse.vmdk" : open successful (21) size = 2387566592, hd = 0. Type 19
2021-01-23T07:55:40.612Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_1-000004-sesparse.vmdk" : closed.
2021-01-23T07:55:40.612Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_1-000003-sesparse.vmdk" : open successful (21) size = 3022348288, hd = 0. Type 19
2021-01-23T07:55:40.612Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_1-000003-sesparse.vmdk" : closed.
2021-01-23T07:55:40.612Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_1-000002-sesparse.vmdk" : open successful (21) size = 1111130112, hd = 0. Type 19
2021-01-23T07:55:40.612Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_1-000002-sesparse.vmdk" : closed.
2021-01-23T07:55:40.612Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_1-flat.vmdk" : open successful (21) size = 53687091200, hd = 0. Type 3
2021-01-23T07:55:40.613Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_1-flat.vmdk" : closed.
2021-01-23T07:55:40.613Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b172-35b3eb22-e104-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_2-000004-sesparse.vmdk" : open successful (21) size = 2402336768, hd = 0. Type 19
2021-01-23T07:55:40.613Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b172-35b3eb22-e104-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_2-000004-sesparse.vmdk" : closed.
2021-01-23T07:55:40.613Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b172-35b3eb22-e104-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_2-000003-sesparse.vmdk" : open successful (21) size = 2271318016, hd = 0. Type 19
2021-01-23T07:55:40.613Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b172-35b3eb22-e104-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_2-000003-sesparse.vmdk" : closed.
2021-01-23T07:55:40.613Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b172-35b3eb22-e104-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_2-000002-sesparse.vmdk" : open successful (21) size = 2185232384, hd = 0. Type 19
2021-01-23T07:55:40.613Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b172-35b3eb22-e104-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_2-000002-sesparse.vmdk" : closed.
2021-01-23T07:55:40.613Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b172-35b3eb22-e104-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_2-flat.vmdk" : open successful (21) size = 536870912000, hd = 0. Type 3
2021-01-23T07:55:40.613Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b172-35b3eb22-e104-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_2-flat.vmdk" : closed.
2021-01-23T07:55:40.613Z| vmx| I125: SNAPSHOT: SnapshotDiskTreeAddFromSnapshot: Trying to add snapshot 2.11-FS-ELO-xxx-GMH-Snapshot3.vmsn to disk /vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH.vmdk which already has snapshot 2.11-FS-ELO-xxx-GMH-Snapshot2.vmsn.
2021-01-23T07:55:40.613Z| vmx| I125: SNAPSHOT: SnapshotGenerateDeleteDisks Failed to fetch disk tree: One of the disks in this virtual machine is already in use by a virtual machine or by a snapshot (21)
2021-01-23T07:55:40.613Z| vmx| I125: SNAPSHOT: SnapshotDeleteNode failed: One of the disks in this virtual machine is already in use by a virtual machine or by a snapshot (21)
2021-01-23T07:55:40.613Z| vmx| I125: SNAPSHOT: Snapshot_Delete failed: One of the disks in this virtual machine is already in use by a virtual machine or by a snapshot (21)
2021-01-23T07:55:40.613Z| vmx| I125: VigorTransport_ServerSendResponse opID=602f635c seq=849: Completed Snapshot request.
2021-01-23T07:55:49.057Z| vmx| I125: GuestRpc: Got error for channel 1 connection 7: Remote disconnected
2021-01-23T07:55:49.087Z| vmx| I125: GuestRpc: Got error for channel 1 connection 8: Remote disconnected
2021-01-23T07:55:50.121Z| vmx| I125: GuestRpc: Got error for channel 1 connection 9: Remote disconnected
2021-01-23T07:55:51.142Z| vmx| I125: GuestRpc: Got error for channel 1 connection 10: Remote disconnected
2021-01-23T07:55:52.142Z| vmx| I125: GuestRpc: Got error for channel 1 connection 11: Remote disconnected
2021-01-23T07:55:53.184Z| vmx| I125: GuestRpc: Got error for channel 1 connection 12: Remote disconnected
2021-01-23T07:55:54.219Z| vmx| I125: GuestRpc: Got error for channel 1 connection 13: Remote disconnected
2021-01-23T07:55:55.229Z| vmx| I125: GuestRpc: Got error for channel 1 connection 14: Remote disconnected
2021-01-23T07:55:56.235Z| vmx| I125: GuestRpc: Got error for channel 1 connection 15: Remote disconnected
2021-01-23T07:55:57.306Z| vmx| I125: GuestRpc: Got error for channel 1 connection 16: Remote disconnected
2021-01-23T07:55:58.302Z| vmx| I125: GuestRpc: Got error for channel 1 connection 17: Remote disconnected
2021-01-23T07:55:59.308Z| vmx| I125: GuestRpc: Got error for channel 1 connection 18: Remote disconnectedhier bei ist mir dann das ins Auge gefallen:
2021-01-23T07:55:40.611Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH-000004-sesparse.vmdk" : closed.
2021-01-23T07:55:40.611Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH-000003-sesparse.vmdk" : closed.
2021-01-23T07:55:40.612Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH-000002-sesparse.vmdk" : closed.
2021-01-23T07:55:40.612Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH-flat.vmdk" : closed.
2021-01-23T07:55:40.612Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_1-000004-sesparse.vmdk" : closed.
2021-01-23T07:55:40.612Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_1-000003-sesparse.vmdk" : closed.
2021-01-23T07:55:40.612Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_1-000002-sesparse.vmdk" : closed.
2021-01-23T07:55:40.613Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b156-49b67454-f8dc-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_1-flat.vmdk" : closed.
2021-01-23T07:55:40.613Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b172-35b3eb22-e104-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_2-000004-sesparse.vmdk" : closed.
2021-01-23T07:55:40.613Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b172-35b3eb22-e104-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_2-000003-sesparse.vmdk" : closed.
2021-01-23T07:55:40.613Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b172-35b3eb22-e104-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_2-000002-sesparse.vmdk" : closed.
2021-01-23T07:55:40.613Z| vmx| I125: DISKLIB-VMFS : "/vmfs/volumes/5f81b172-35b3eb22-e104-80615f082f26/2.11-FS-ELO-xxx-GMH/FS-ELO-xxx-GMH_2-flat.vmdk" : closed. Wenn der Backupproxy nicht sperrt? Wie geht es jetzt weiter? Ich habe schiess, mir die Maschine zu zerschissen
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
Hallo Em-Pie,
danke das du dir so viel Mühe gemacht hast. Ich habe das Problem jetzt auf eine vielleicht sehr blöde weise gelöst, aber es war für mich jetzt ein gangbarer Weg, das ganze Problem zu lösen!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 habe die VM mit einer ISO von Acronis gesichert
- Registrierung in ESXI aufgehoben
- Ordner im Datastorage via SSH umbenannt: ...old...
- VM neu erstellt und wieder hergestellt
- In Veeam Task angepasst auf die neue VM
Fertig!
PS: Was lernen wir aus der Ganzen Sache? Snaps in Kombi mit Veeam-Backup ist keine gute Idee. Entweder das eine oder andere! Eigentlich sollte das auch so funktionieren im Kombi. aber kann eben auch in die Hose gehen, wie man gesehen hat!
Lieben Dank für deine Hinweise
danke das du dir so viel Mühe gemacht hast. Ich habe das Problem jetzt auf eine vielleicht sehr blöde weise gelöst, aber es war für mich jetzt ein gangbarer Weg, das ganze Problem zu lösen!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 habe die VM mit einer ISO von Acronis gesichert
- Registrierung in ESXI aufgehoben
- Ordner im Datastorage via SSH umbenannt: ...old...
- VM neu erstellt und wieder hergestellt
- In Veeam Task angepasst auf die neue VM
Fertig!
PS: Was lernen wir aus der Ganzen Sache? Snaps in Kombi mit Veeam-Backup ist keine gute Idee. Entweder das eine oder andere! Eigentlich sollte das auch so funktionieren im Kombi. aber kann eben auch in die Hose gehen, wie man gesehen hat!
Lieben Dank für deine Hinweise
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
