13
VMWare, nach Stromausfall funktionieren vmdk Dateien nicht mehr
Hallo zusammen,
wir hatten Vorgestern einen Stromausfall und seit dem laufen meine VM's nicht mehr. Im vSphere Client wird folgendes angezeigt:
Ich habe versucht, die Ordner über WinSCP zu kopieren, doch leider bekomme ich hier die Fehlermeldung "formatiertes Paket oder inkompatibles Protokoll" Fehlercode 5
Der Datastore inkl Ordnerstruktur wird mir angezeigt, habe auch schon versucht, eine neue VM anzulegen und dabei eine vorhandene vmdk ausgewählt. Wenn ich die VM dann einschalten möchte, bekomme ich die Fehlermeldung "Das Gerät Bootstrap ist nicht verfügbar.
Was kann ich noch testen, oder was könnte der Fehler sein?
wir hatten Vorgestern einen Stromausfall und seit dem laufen meine VM's nicht mehr. Im vSphere Client wird folgendes angezeigt:
Ich habe versucht, die Ordner über WinSCP zu kopieren, doch leider bekomme ich hier die Fehlermeldung "formatiertes Paket oder inkompatibles Protokoll" Fehlercode 5
Der Datastore inkl Ordnerstruktur wird mir angezeigt, habe auch schon versucht, eine neue VM anzulegen und dabei eine vorhandene vmdk ausgewählt. Wenn ich die VM dann einschalten möchte, bekomme ich die Fehlermeldung "Das Gerät Bootstrap ist nicht verfügbar.
Was kann ich noch testen, oder was könnte der Fehler sein?
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: 635733
Url: https://administrator.de/forum/vmware-nach-stromausfall-funktionieren-vmdk-dateien-nicht-mehr-635733.html
Ausgedruckt am: 23.12.2024 um 06:12 Uhr
13 Kommentare
Neuester Kommentar
moin...
hast du kein Backup ?
versuche mal die VMs neu zu registrieren... also löschen (nicht aus dem store) und neu anlegen...
Frank
hast du kein Backup ?
versuche mal die VMs neu zu registrieren... also löschen (nicht aus dem store) und neu anlegen...
Frank
Nabend,
Backup wäre hilfreich und außerdem mehr Details:
Ich würde vorerst keine Umkopieraktion starten, vielleicht ist es nur ein Kleinigkeit, es könnte ein Lock auf den Dateien liegen, der aber nach dem Neustart als der Strom wieder da war, nicht mehr aufgelöst werden kann.
Vgl. https://kb.vmware.com/s/article/2139179
[EDIT] Das könnte auch noch hilfreich sein: https://kb.vmware.com/s/article/10051?lang=de
Ansonsten bitte mal detaillierte Logs schicken.
Gruß und schöne Weihnachten
cykes
Backup wäre hilfreich und außerdem mehr Details:
- Welche VMWare ESXi Version (vSphere Client spricht ja für max. 6.0)? Free oder mit Lizenz?
- Was ist mit den beiden VMs "Sophos XG" und "Windows 10", liegen die auf einer anderen Datastore? Oder liefen die nicht beim Stromausfall?
Ich würde vorerst keine Umkopieraktion starten, vielleicht ist es nur ein Kleinigkeit, es könnte ein Lock auf den Dateien liegen, der aber nach dem Neustart als der Strom wieder da war, nicht mehr aufgelöst werden kann.
Vgl. https://kb.vmware.com/s/article/2139179
[EDIT] Das könnte auch noch hilfreich sein: https://kb.vmware.com/s/article/10051?lang=de
Ansonsten bitte mal detaillierte Logs schicken.
Gruß und schöne Weihnachten
cykes
Servus,
Wird denn der Datastore als richtig gemounted im vSphere angezeigt?
Entweder, wie mein Vorredner sagt, die vm aus dem vSphere entfernen (nicht löschen)! Und neu einbinden, oder mal mit einem frischen vSphere von USB Booten und die vmdk Dateien manuell in neue VM einbinden.
Alternativ die kompletten logs über winscp runterziehen und hier zur Verfügung stellen
Es ist ja sicherlich kein Produktivsystem, da du scheinbar kein Backup hast und die synology vm ja sowieso nur inoffiziell ist und diese es nicht als VM gibt
Wenn’s s doch ein Produktsystem ist und du ein Wartungsvertrag hast, kannst du dich auch an vmware wenden.
Gruß
Wird denn der Datastore als richtig gemounted im vSphere angezeigt?
Entweder, wie mein Vorredner sagt, die vm aus dem vSphere entfernen (nicht löschen)! Und neu einbinden, oder mal mit einem frischen vSphere von USB Booten und die vmdk Dateien manuell in neue VM einbinden.
Alternativ die kompletten logs über winscp runterziehen und hier zur Verfügung stellen
Es ist ja sicherlich kein Produktivsystem, da du scheinbar kein Backup hast und die synology vm ja sowieso nur inoffiziell ist und diese es nicht als VM gibt
Wenn’s s doch ein Produktsystem ist und du ein Wartungsvertrag hast, kannst du dich auch an vmware wenden.
Gruß
Meine ESXi-Version ist 6.0.0 und die letzten Backups sind schon etwas älter. Eine neue VM kann ich anlegen und wenn ich die vmdk Datei aus der vorhandenen VM auswähle, kann ich die VM nicht starten. Über WinSCP kann ich die vmdk Datei oder auch das letzte Log File nicht kopieren. Siehe Bild
Ältere Log Files lassen sich kopieren. Nur die letzten nicht.
So sieht es aus, wenn ich eine neue VM erstelle und die vorhandene vmdk auswähle
Ältere Log Files lassen sich kopieren. Nur die letzten nicht.
So sieht es aus, wenn ich eine neue VM erstelle und die vorhandene vmdk auswähle
Moin,
hast Du Dir die KB-Artikel, die ich oben verlinkt habe, wenigstens mal durchgelesen? Du musst natürlich ein wenig angepasst lesen & verstehen, da Du vermutlich die Free im Einsatz hast. Also erstmal ssh aktivieren und dort weitermachen. esxcli ist Dein Freund.
Ggf. bitte mal einen Screenshot vom Verzeichnisinhalt der nicht startenden VMs machen.
Gruß
cykes
Zusatzfrage: Lagen eventuell noch Snapshots in den originalen VMs? In dem Fall könnte es etwas komplizierter/zeitaufwändiger werden.
hast Du Dir die KB-Artikel, die ich oben verlinkt habe, wenigstens mal durchgelesen? Du musst natürlich ein wenig angepasst lesen & verstehen, da Du vermutlich die Free im Einsatz hast. Also erstmal ssh aktivieren und dort weitermachen. esxcli ist Dein Freund.
Ggf. bitte mal einen Screenshot vom Verzeichnisinhalt der nicht startenden VMs machen.
Gruß
cykes
Zusatzfrage: Lagen eventuell noch Snapshots in den originalen VMs? In dem Fall könnte es etwas komplizierter/zeitaufwändiger werden.
Die habe ich mir durchgelesen und ich habe auch einige Tests durchgeführt. Snapshots sollten keine mehr vorhanden gewesen sein. Auch über ssh kann ich das letzte log File nicht öffnen (ältere log Files funktionieren)
Hier mal ein Verzeichnisinhalt einer nicht mehr funktionierenden VM
Hier mal ein Verzeichnisinhalt einer nicht mehr funktionierenden VM
Am Verzeichnisinhalt der 'Windows 10' VM sieht man aber, dass
a) die Konfigurationsdatei der VM ('Windows 10.vmx') am 22.12. um 21:03 Uhr noch editiert/verändert wurde
b) ein Lock auf diese Datei besteht (-> Windows 10.vmx.lck)
b) musst Du anhand der KB-Artikel auflösen oder zumindest überprüfen.
Die Frage ob eine Lizenz vorhanden ist oder die Free verwenmdet wird, hast Du immer noch nicht beantwortet.
Außerdem hast Du ungewöhlich große Swap-Dateien (*.vswp) in diesem Verzeichnis. Wieviel vRAM hat diese VM konfiguriert und wieveil physischen RAM hat der Server?
Hier gibt's noch weitere Logdateien, die Du überprüfen kannst: https://kb.vmware.com/s/article/10051
(Hatte ich ja oben schon verlinkt und hattest Du ja durchgelesen ...)
a) die Konfigurationsdatei der VM ('Windows 10.vmx') am 22.12. um 21:03 Uhr noch editiert/verändert wurde
b) ein Lock auf diese Datei besteht (-> Windows 10.vmx.lck)
b) musst Du anhand der KB-Artikel auflösen oder zumindest überprüfen.
Die Frage ob eine Lizenz vorhanden ist oder die Free verwenmdet wird, hast Du immer noch nicht beantwortet.
Außerdem hast Du ungewöhlich große Swap-Dateien (*.vswp) in diesem Verzeichnis. Wieviel vRAM hat diese VM konfiguriert und wieveil physischen RAM hat der Server?
Hier gibt's noch weitere Logdateien, die Du überprüfen kannst: https://kb.vmware.com/s/article/10051
(Hatte ich ja oben schon verlinkt und hattest Du ja durchgelesen ...)
Sorry, eine Lizenz ist vorhanden und ich betreibe den Server nicht in einer Free-Version. Die Windows 10 VM habe ich 4GB RAM zugewiesen und insgesamt hat der Server 32GB. Es wird noch ein RAID-Controller (3Ware 9650SE-2LP AMCC 2-port PCIe SATA II RAID Controller) verwendet, kann es sein, dass dieser defekt ist oder das Dateisystem zerstört hat?
Laut KB soll ein anderer VMWare Host die VM sperren, aber das kann eigentlich nicht, da nur einer im Einsatz ist.
Laut KB soll ein anderer VMWare Host die VM sperren, aber das kann eigentlich nicht, da nur einer im Einsatz ist.
Du kannst Dir auch mal diesen Beitrag in der VMWare Community durchlesen: https://communities.vmware.com/t5/VMware-vSphere-Discussions/Problem-wit ...
Ich würde erstmal versuchen, genauere Informationen über den Lock mithilfe der vmkfstools zu bekommen.
Ggf. hilft auch eine Neuinstallation vom ESXi auf einen frischen USB-Stick.
Ansonsten kann es recht kompliziert und zeitaufwändig werden, der Kollege continuum in der VMWare Community ist aber ggf. noch erreichbar/aktiv.
Die Recovery-Methoden, die er vorschlägt, funktionieren (hab ich selbst schon mal getestet, sind aber mit Bedacht auszuführen, insbesondere da Du kein halbwegs aktuelles Backup hast.
Ich würde erstmal versuchen, genauere Informationen über den Lock mithilfe der vmkfstools zu bekommen.
Ggf. hilft auch eine Neuinstallation vom ESXi auf einen frischen USB-Stick.
Ansonsten kann es recht kompliziert und zeitaufwändig werden, der Kollege continuum in der VMWare Community ist aber ggf. noch erreichbar/aktiv.
Die Recovery-Methoden, die er vorschlägt, funktionieren (hab ich selbst schon mal getestet, sind aber mit Bedacht auszuführen, insbesondere da Du kein halbwegs aktuelles Backup hast.
2Zitat von @Mr.Heisenberg:
wird noch ein RAID-Controller (3Ware 9650SE-2LP AMCC 2-port PCIe SATA II RAID Controller) verwendet, kann es sein, dass dieser defekt ist oder das Dateisystem zerstört hat?
wenn der RAID Controller keine BBU hat....sehr wahrscheinlich!wird noch ein RAID-Controller (3Ware 9650SE-2LP AMCC 2-port PCIe SATA II RAID Controller) verwendet, kann es sein, dass dieser defekt ist oder das Dateisystem zerstört hat?
Noch schlimmer, wenn vor dem Server keine USV hängt.
Hier wurden scheinbar einige Kardinalfehler begannen
moin...
Frank
Zitat von @tech-flare:
Noch schlimmer, wenn vor dem Server keine USV hängt.
Hier wurden scheinbar einige Kardinalfehler begannen
der grßte Fehler, ist wohl, kein Backup zu haben....Zitat von @Mr.Heisenberg:
wird noch ein RAID-Controller (3Ware 9650SE-2LP AMCC 2-port PCIe SATA II RAID Controller) verwendet, kann es sein, dass dieser defekt ist oder das Dateisystem zerstört hat?
wenn der RAID Controller keine BBU hat....sehr wahrscheinlich!wird noch ein RAID-Controller (3Ware 9650SE-2LP AMCC 2-port PCIe SATA II RAID Controller) verwendet, kann es sein, dass dieser defekt ist oder das Dateisystem zerstört hat?
Noch schlimmer, wenn vor dem Server keine USV hängt.
Hier wurden scheinbar einige Kardinalfehler begannen
Frank
Zitat von @Mr.Heisenberg:
Sorry, eine Lizenz ist vorhanden und ich betreibe den Server nicht in einer Free-Version.
Mir ging es nicht um einen Lizenzcheck, sondern um die Verfügbarkeit von Tools, die nur in einer lizensierten Umgebung funktionieren.Sorry, eine Lizenz ist vorhanden und ich betreibe den Server nicht in einer Free-Version.
Die Windows 10 VM habe ich 4GB RAM zugewiesen und insgesamt hat der Server 32GB. Es wird noch ein RAID-Controller (3Ware 9650SE-2LP AMCC 2-port PCIe SATA II RAID Controller) verwendet, kann es sein, dass dieser defekt ist oder das Dateisystem zerstört hat?
Ist das ein selbstgebauter Server oder einer der großen Hersteller und sind Server und Komponenten in der VMware HCL?Grundsätzlich kann natürlich auch der Controller dafür (mit) verantwortlich sein. Alle Komponenten, die beim Stromausfall nicht sauber heruntergefahren wurden, können das auslösen. Wäre denn ein Upgrade auf bspw. 6.7 möglich?
Laut KB soll ein anderer VMWare Host die VM sperren, aber das kann eigentlich nicht, da nur einer im Einsatz ist.
Laut Deinem Screenshot hat der Host mit der MAC-Adresse 0025904659e9 (00:25:90:46:59:e9) den Lock ausgelöst, wobei Du ja jetzt im Verzeichnis der Synology VM bist. Das Problem ist, dass VMWare 'denkt', die VMs würden noch laufen (ermittelt wird das anhand der vorhandenen lck-Datei und der vswp Dateien.
Hi
habe gerade keien Zeit um die vorhandenen Antworten mal kurz durchzulesen wegen Redundanz:
ich würde darafu schließen das du einen Filesystemerror hast. Eigentlich repariert sich VMFS5+ selbst daher sind tools da "rar". Beim mounten wird normal die Selbstheilung angestoßen. Dank der guten Cachefunktion im ESX kann da viel beschädigt sein.... (je mehr ungenutzter RAM umso größer das Caching=Fehlerpotential)
Nachdem du nicht kopieren kannst hat ESX einfach keinen Zugriff mehr, weil es wohl meldet es sei "dirty".
Es gibt aber 3rd Party Programme um die Dateien auch beschädigt auszulesen Diskinternals "VMFS Recovery" nutze ich für solche Fälle=>
a) auslesen
b) löschen
c) zurückkopieren
Bevor du den Schritt aber gehst würde ich die Volumen mal entmounten (ich schätze Installation auf USB Sticks bei denen man mal kurz einen ESX Server (je höher desto mehr Logik ist reingewandert; 7.0U1b ist recht potent) hochziehen kann um die Shell zu erreichen mit seinen Tools) und öfters mal mounten, lange warten (man sollte Tätigkeit auf dem Array sehen) und wieder entmounten. Sobald du kopieren (sftp, cp, GUI, ....) darfst hast du gewonnen. Wenn nicht gibt es mit dem oberen (kostenpflichtigen) Tool die Möglichkeit die Heilungsfähigkeit des VM OSes zu "testen".
In der Firma (Datenrettung) haben wir recht gute Erfolge damit.
Gruß
Sam
habe gerade keien Zeit um die vorhandenen Antworten mal kurz durchzulesen wegen Redundanz:
ich würde darafu schließen das du einen Filesystemerror hast. Eigentlich repariert sich VMFS5+ selbst daher sind tools da "rar". Beim mounten wird normal die Selbstheilung angestoßen. Dank der guten Cachefunktion im ESX kann da viel beschädigt sein.... (je mehr ungenutzter RAM umso größer das Caching=Fehlerpotential)
Nachdem du nicht kopieren kannst hat ESX einfach keinen Zugriff mehr, weil es wohl meldet es sei "dirty".
Es gibt aber 3rd Party Programme um die Dateien auch beschädigt auszulesen Diskinternals "VMFS Recovery" nutze ich für solche Fälle=>
a) auslesen
b) löschen
c) zurückkopieren
Bevor du den Schritt aber gehst würde ich die Volumen mal entmounten (ich schätze Installation auf USB Sticks bei denen man mal kurz einen ESX Server (je höher desto mehr Logik ist reingewandert; 7.0U1b ist recht potent) hochziehen kann um die Shell zu erreichen mit seinen Tools) und öfters mal mounten, lange warten (man sollte Tätigkeit auf dem Array sehen) und wieder entmounten. Sobald du kopieren (sftp, cp, GUI, ....) darfst hast du gewonnen. Wenn nicht gibt es mit dem oberen (kostenpflichtigen) Tool die Möglichkeit die Heilungsfähigkeit des VM OSes zu "testen".
In der Firma (Datenrettung) haben wir recht gute Erfolge damit.
Gruß
Sam
