VMDK Files lassen sich nicht löschen
Guten Morgen Gemeinde
Ich habe hier ein etwas nerviges Problem.
Vorgeschichte: Raidcontroller in T350 schmiert ab. Controller wurde ersetzt. System bootet.
1. Problem: Die VMs starten nichtmehr.
2. Problem: Ein neues hinzufügen ist nicht möglich - warum auch immer.
Lösung:
Natürlich hat man Backups. Ich konnte ohne Probleme den DC (nicht live, heisst nur so) wieder per Synology Active Backup zurückspielen.
Problem:
Fileserver kann ich nur per "Sofortige Wiederherstellung" zurückspielen, da der Speicher für eine "Vollständige VM-Wiederherstellung" nicht reicht.
Warum reicht es nicht? Weil ich dem FS 600 GB zugewiesen habe, die noch von der "korrupten" VM belegt werden. Leider kann ich diese VMDK NICHT löschen. Lustigerweise ist ein verschieben innerhalb des Datastores möglich. Eine VM dazu existiert auch nicht mehr.
Wie bekomme ich diese blöde verwaiste Maschine weg? Eingesetzt wird ESXi 7.0.3.
Fehlermeldung:
Löschen der Datei oder des Verzeichnisses /vmfs/volumes/644806df-3721546f-6efb-6c3c8c6b1641/ISOs/XXX-XXX von datastore1 wurde von „Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36@10.150.236.10“ eingeleitet und mit dem Status „Fehler“ abgeschlossen
Ich habe hier ein etwas nerviges Problem.
Vorgeschichte: Raidcontroller in T350 schmiert ab. Controller wurde ersetzt. System bootet.
1. Problem: Die VMs starten nichtmehr.
2. Problem: Ein neues hinzufügen ist nicht möglich - warum auch immer.
Lösung:
Natürlich hat man Backups. Ich konnte ohne Probleme den DC (nicht live, heisst nur so) wieder per Synology Active Backup zurückspielen.
Problem:
Fileserver kann ich nur per "Sofortige Wiederherstellung" zurückspielen, da der Speicher für eine "Vollständige VM-Wiederherstellung" nicht reicht.
Warum reicht es nicht? Weil ich dem FS 600 GB zugewiesen habe, die noch von der "korrupten" VM belegt werden. Leider kann ich diese VMDK NICHT löschen. Lustigerweise ist ein verschieben innerhalb des Datastores möglich. Eine VM dazu existiert auch nicht mehr.
Wie bekomme ich diese blöde verwaiste Maschine weg? Eingesetzt wird ESXi 7.0.3.
Fehlermeldung:
Löschen der Datei oder des Verzeichnisses /vmfs/volumes/644806df-3721546f-6efb-6c3c8c6b1641/ISOs/XXX-XXX von datastore1 wurde von „Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36@10.150.236.10“ eingeleitet und mit dem Status „Fehler“ abgeschlossen
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 9879675820
Url: https://administrator.de/forum/vmdk-files-lassen-sich-nicht-loeschen-9879675820.html
Ausgedruckt am: 22.12.2024 um 08:12 Uhr
8 Kommentare
Neuester Kommentar
Ggf. hängt sie wegen Backup o.ä. an z.B. an Acronis?
Erste Regel ist immer: Ruhe bewahren und nicht mit der Brechstange. Finde gerade das Kommando nicht. Man kann aber bequem unter ESXi nach Einträgen in anderen Maschinen o.ä. schauen.
Bei mir hingen die noch an Acronis CyberBackup. Finde leider gerade den Beitrag nicht mehr. Auf jedenfall erstmal die Finger von taskkill pid irgendwas lassen. Der ESXi sperrt normal nicht ohne Grund.
Google mal nach orphaned VMDK o.ä. Da gibt es entsprechende Suchbefehle und er Vorgehensweisen.
Erste Regel ist immer: Ruhe bewahren und nicht mit der Brechstange. Finde gerade das Kommando nicht. Man kann aber bequem unter ESXi nach Einträgen in anderen Maschinen o.ä. schauen.
Bei mir hingen die noch an Acronis CyberBackup. Finde leider gerade den Beitrag nicht mehr. Auf jedenfall erstmal die Finger von taskkill pid irgendwas lassen. Der ESXi sperrt normal nicht ohne Grund.
Google mal nach orphaned VMDK o.ä. Da gibt es entsprechende Suchbefehle und er Vorgehensweisen.
https://blah.cloud/infrastructure/safely-checkremove-orphaned-vmdk-files ...
https://www.dnsstuff.com/zombie-vmdk
Meine ich nutzte den 1. Link. Safely check/remove sind die Zauberworte! Es gibt 1 Mio. Prozesse auf den Host. Da wild Task zu beenden ist unschön. Würde anhand solcher Guides probieren die Zombie VMDK einzufangen.
https://www.dnsstuff.com/zombie-vmdk
Meine ich nutzte den 1. Link. Safely check/remove sind die Zauberworte! Es gibt 1 Mio. Prozesse auf den Host. Da wild Task zu beenden ist unschön. Würde anhand solcher Guides probieren die Zombie VMDK einzufangen.
Also wenn alles nichts hilft kannst du das Hyper-V-Service stoppen und anschließend die ganze VM vom FileSyszem löschen.
Wie @Crusher79 aber schon schreibt, sollte das die letzte Möglichkeit sein.
Ich könnte mir aber vorstellen, dass in den einzelnen VMs in den Settings z.B. ein virtuelle Adapter hinterlegt ist, den es in den globalen Settings nicht gibt. Prüfe das mal.
Wie @Crusher79 aber schon schreibt, sollte das die letzte Möglichkeit sein.
Ich könnte mir aber vorstellen, dass in den einzelnen VMs in den Settings z.B. ein virtuelle Adapter hinterlegt ist, den es in den globalen Settings nicht gibt. Prüfe das mal.
Zitat von @mazenauer:
Hallöle zusammen
Danke für eure Inputs. Ich habe per Putty versucht die VMDK zu löschen und erhielt input / output Error. Ich schätze, da hat irgendwas doch nicht ganz sauber mit dem Controllerwechsel gepasst.
Habe den Datenspeicher gelöscht und neuerstellt, Backup eingespielt - et voila.
Gruss
Christof
Hallöle zusammen
Danke für eure Inputs. Ich habe per Putty versucht die VMDK zu löschen und erhielt input / output Error. Ich schätze, da hat irgendwas doch nicht ganz sauber mit dem Controllerwechsel gepasst.
Habe den Datenspeicher gelöscht und neuerstellt, Backup eingespielt - et voila.
Gruss
Christof
Hast du auch das entsprechende Hyper-V-Service gestoppt? Solange das läuft ist eine ei gehängte VM natürlich gesperrt. Noch mehr, wenn Snapshots vorhanden sind usgl.
Aber das Problem ist gelöst. Das ist das Wichtigste.
Auch VHDX, aber hast recht. Da habe ich vmdk wie vhdx gelesen 🤦♂️