Aug 16, 2022

7271

Vmware ESXI 7 - VM lässt sich nicht mehr starten

V-Umgebung: Vmware Essential Plus Version 7, also ESXI 7 und VCenter 7

Betroffenen VM: Windows Server 2016 Datacenter (1,02 von 1,45 TB beschrieben),
3 Partitionen | hier mit %VMNAME%

Backuplösung: Veeam Backup & Replication 11

Hergang:
Besagte VM hat gestern abernd nicht mehr gebackupt. Es sind in Veeam 3 retry-Anläufe eingestellt. In der zweiten Nachthälfte läuft außerdem eine Replication.
Der Veeam-Fehler beim ersten Versuch des Backups:
Failed to create VM snapshot. Error: CreateSnapshot failed, vmRef vm-76426, timeout 1800000, snName VEEAM BACKUP TEMPORARY SNAPSHOT, snDescription Please do not delete this snapshot. It is being used by Veeam Backup., memory False, quiesce False
Unable to release guest. Error: RPC function call failed. Function name: [BlobCall]. Target machine: [%VMNAME%]. RPC error:Der RPC-Server ist nicht verfügbar. Code: 1722
Error: An error occurred while saving the snapshot: Unable to save snapshot file. (An error occurred while saving the snapshot: Unable to save snapshot file., An error occurred while taking a snapshot: Unable to save snapshot file.)

Die Fehlermeldungen bei den Retry-Anläufen sowie bei allen Replication-Versuchen:
Error: Failed to open VDDK disk [[%STORAGENAME%] %VMNAME%/%VMNAME%_2-000001.vmdk] ( is read-only mode - [true] ) Logon attempt with parameters [VC/ESX: [%IP_VCENTER%];Port: 443;Login: [%LOGIN_USERNAME%];VMX Spec: [moref=vm-76426];Snapshot mor: [snapshot-180870];Transports: [nbd];Read Only: [true]] failed because of the following errors: Failed to open disk for read. Failed to upload disk. Skipped arguments: [vddkConnSpec>]; Agent failed to process method {DataTransfer.SyncDis

anscheinend wurde hier abgeschnitten.

Die VM hat angeblich keine Snapshots. Sie war einfach aus und es stand aber die gelbe Warnmeldung in der Vmware, dass die VM snapshots enthält, die konsolidiert werden müssen.

Beim Versuch, die VM zu starten, gibt es am ESXI die Fehlermeldung:

Power On VM
Schlüssel: haTask-62-vim.VirtualMachine.powerOn-3288757539
Beschreibung: Schaltet diese virtuelle Maschine ein.
Virtuelle Maschine: %VMNAME%
Zustand: Fehlgeschlagen - Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Fehler: Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Dateisystemspezifische Implementierung von loctl[file] fehlgeschlagen
Die übergeordnete Festplatte dieser virtuellen Festplatte konnte nicht geöffnet werden
Die Festplatte „/vmfs/volumes/%datastorepath%/%VMNAME%/%VMNAME%_2-000016.vmdk“ oder eine der Snapshot-Festplatten, auf die sie angewiesen ist, konnte nicht geöffnet werden.
Einschalten des Moduls „Disk“ fehlgeschlagen.
Das Starten der virtuellen Maschine ist fehlgeschlagen.

Ich habe bereits versucht, mittels

vmkfstools -x check /vmfs/volumes/<datastorepath>/<vm name>/<vm name main base disk>.vmdk

und

vmkfstools -x repair /vmfs/volumes/<datastorepath>/<vm name>/<vm name main base disk>.vmdk

sowie

vmkfstools -x check /vmfs/volumes/<datastorepath>/<vm name>/%VMNAME%_2-000016.vmdk

und

vmkfstools -x repair /vmfs/volumes/<datastorepath>/<vm name>/%VMNAME%_2-000016.vmdk

Jedoch stand da immer als Ergebnis: "Disk is error free".

Da die VM doch eine gewisse Größe hat, wäre das Zurückspielen aus dem Backup von Vorgestern nicht so toll, denn erfahrungsgemäß dauert das viel zu lang.

Die Frage ist also, was ich noch machen kann, um die VM vielleicht in einen Zustand zu bekommen, dass sie sich wieder starten lässt.

Please also mark the comments that contributed to the solution of the article

Content-Key: 3664163947

Url: https://administrator.de/contentid/3664163947

Printed on: April 28, 2024 at 03:04 o'clock

26 Comments

Latest comment

Auch kein Hallo.

Zitat von @Mondragor
Die VM hat angeblich keine Snapshots. Sie war einfach aus und es stand aber die gelbe Warnmeldung in der Vmware, dass die VM snapshots enthält, die konsolidiert werden müssen.

Hast du das denn durchgeführt? Sind in der ESX Snapshotverwaltung welche zu sehen?

Das Backup regelmäßig zu testen ist hier offensichtlich nicht passiert.

Gerade wenn es sich um eine wichtige Maschine handelt, sollte man so etwas periodisch durchführen.

Da die VM doch eine gewisse Größe hat, wäre das Zurückspielen aus dem Backup von Vorgestern nicht so toll, denn erfahrungsgemäß dauert das viel zu lang.

Trotzdem machen. Sonst weißt du nämlich nicht, ob deine Backup Strategie auch wirklich funktioniert.

Wenn der Restore gelingt, hast du zumindest eine lauffähige VM.

Falls nicht, hast du andere Probleme.

Auch kein Gruß
Marc

Aus dem Bauch heraus, du hast noch etwas Storage Platz frei?

Ansonsten Veeam kam nicht mehr auf den Server:
RPC error:Der RPC-Server ist nicht verfügbar. Code: 1722

Und konnte keine Snapshot erstellen:
Error: An error occurred while saving the snapshot: Unable to save snapshot file.

Error: Failed to open VDDK disk [[%STORAGENAME%] %VMNAME%/%VMNAME%_2-000001.vmdk] ( is read-only mode - [true] )
gibt es die Platte?

Hier sind wir schon bei 16 Snapshots:
%_2-000016.vmdk

Kannst du denn einfach Snapshots konsoldieren? Auch wenn keine da sind ...

Parallel würde ich schon mal das Backup starten, , wenn du Platz dafür hast.

@radiogugu

In der Snapshotverwaltung sind keine Snapshots zu sehen und ich achte auch darauf, dass die VMs nicht zu viele Snapshots haben. In der Snapshotverwaltung wir auch nicht ein einziger angezeigt.

Was genau meinst Du mit "das Backup regelmäßig zu testen" ?

@Deepsys
Okay, anscheinend ist das System gestern Abend nach 19:00 Uhr ausgestiegen.
Das erklärt dann das Problem mit fehlgeschlagenen Erstellen der snapsots.

Die Platte ..._2-000001.vmdk
gibt es, ja.
In einem anderen Fall habe ich gelesen, dass unter einem ähnlichen Problem dazu geraten wurde, den ESX Host neu zu starten, was in dem Fall auch zum Erfolg geführt hatte.

Achso und das "Alle löschen" unter Snapshots habe ich versucht, allerdings sind die vmdk-Dateien bis 000016 noch da.

in einem anderen Fall habe ich gelesen, dass unter einem ähnlichen Problem dazu geraten wurde, den ESX Host neu zu starten, was in dem Fall auch zum Erfolg geführt hatte.

Ja dann wenn das möglich ist, mach das zuerst.
Ansonsten frage mal den VMware Support.

Evtl. stimmen da ein paar Dinge in der vmx Datei nicht, aber das soll dann lieber VMware machen

Und von den Zeitstempeln laut stat sieht es so aus, dass die Snapshots alle etwa zu der Zeit entstanden, als die Backups liefen. Laut Scheduler startet das Backup um 19:00 Uhr. 19:04 bekamen wir vom zabbix erstmals den Hinweis, dass die Maschine nicht mehr erreichbar ist.

Daher liegt für mich die Vermutung nahe, dass der erste Backupversuch irgendwie für das Ganze verantwortlich sein könnte. Seit dem letzten Update von VMWare und Veeam ist das bereits 3 mal passiert, 2 mal mit einer anderen VM.
Nun erstmals mit dieser.

Moin,

Aus dem Bauch heraus, du hast noch etwas Storage Platz frei?

Das wäre auch meine erste Vermutung. Prüfe also mal den Datastore, auf dem die VM liegt.

Ansonsten würde ich auch mal den ESXI rebooten.

Wie sieht denn unter dem ESXi die Snapshot-Kette aus? VEEAM sollte die ja eigentlich nach einem erfolgreichem Backup selbst löschen.

Gruß
em-pie

@em-pie
Das Datastore hat noch 8,5 TB frei, das sollte in Ordnung sein.

Reboot werde ich kommende Nacht versuchen.

Die Snapshotkette auf GUI-Ebene ist leer und das Ausführen von "alle löschen" bewirkt auch nichts. Läuft in 3 Sekunden durch und die Dateien mit _2-0000xx sind immer noch auf dem Datastore.

Screenshot vom ESXI Snapshot-Menü

Anfrage beim VMWare-Support läuft natürlich parallel.

Zitat von @Mondragor:
Was genau meinst Du mit "das Backup regelmäßig zu testen" ?

Na einen Restore Versuch unternehmen und schauen, ob Dienste in der VM hochfahren (mit und ohne Netzwerk > falls die original VM noch läuft) und ob alles klappt

Gruß
Marc

Zitat von @Mondragor:

@radiogugu

In der Snapshotverwaltung sind keine Snapshots zu sehen und ich achte auch darauf, dass die VMs nicht zu viele Snapshots haben. In der Snapshotverwaltung wir auch nicht ein einziger angezeigt.

Was genau meinst Du mit "das Backup regelmäßig zu testen" ?

Genau das was es heißt, nicht nur immer backupen und hoffen, dass alles gut ist, sondern 1x die Woche oder Monat das Backup auch hochfahren (ohne Netzwerk) und sehen ob alles passt.

Zitat von @radiogugu:

Na einen Restore Versuch unternehmen und schauen, ob Dienste in der VM hochfahren (mit und ohne Netzwerk > falls die original VM noch läuft) und ob alles klappt

Ich fürchte bei der Größe, den unsere wichtigen VMs teils haben, würde das mehrere Tage dauern und vermutlich die Backup-Infrastruktur belasten, sodass die scheduled Backups / Replications möglicherweise in die Produktionszeit rein laufen. Bislang hatte es immer geklappt, die nicht mehr startende VM zu löschen, dann den letzten erfolgreichen Bachupstand wiederherzustellen und dann lief es. Aber da waren bei 100 GB belegt schon 4 Stunden rum oder so.

Aber das "Dies und das hast du versäumt!" bringt mich ja in meinem Problem nicht weiter.

Also das Wichtigste zuerst: Es muss genügend freier Speicher vorhanden sein für so gut wie alle Operationen betreffend Snapshots, Restore, etc. 8.5 TB wären natürlich genug vorausgesetzt das Storage zeigt die nicht nur an sondern die stehen wirklich nutzbar zur Verfügung. Ich hatte nach einer Storage Erweiterung auch schon falsche Angaben dazu. Das kannst du aber gut testen in dem du den Restore der VM einfach mal auf das selbe Storage machst, natürlich unter Verwendung eines andern Pfads/Namens.

Dadurch testest du die Datensicherung, testest ob sich der Restore booten lässt und hast eine Option falls deine produktiv VM stirbt. Zeit wirst du auf jeden Fall investieren müssen um bei der Sache nicht durch Fehler alles schlimmer zu machen.

Die fehlerhafte VM würde ich als erstes konsolidieren wenn VMware das anbietet, wenn ich das richtig verstehe hat das noch nicht statt gefunden. Das kann aber auch sehr lange dauern, ich habe schon Konsolidierung von ~8h gehabt die keine sichtbaren Fortschritte gemacht haben aber am Ende fehlerfrei abgeschlossen wurden.

Sorry ja ich weiß, aber wenn 100GB 4h Restorezeit sind, dann bist du echt schlecht aufgestellt. (7-8mb/s)
Außerdem kann man bei VBR11 auch "onthefly" starten, also vom Backup Medium starten und im Laufenden Betrieb wieder zurück auf den Server schieben, mit kurzer Unterbrechung wenn fertig.

-> Backup Kontrolle ist wichtig!!! Ich kenne einen Kunden, bei dem hat das Backup auch immer "funktioniert" bis er es gebaucht hat.

Vor allem musst du ja bei VBR11 nicht die VM löschen, sondern sagst einfach diesen Stand wiederherstellen und er spielt nur die "paar" GB zurück, die sich geändert haben...

Ich würden den ESX einfach mal Neu starten (am Abend), evtl. lösen sich gewisse Probleme dann von selbst (konsolidieren funktioniert wieder,....)

@silent daniel
reden wir jetzt über Backups oder Replicas?
Ich kenne das so, dass ich ein Backup zurückspielen muss, um es dann aufzustarten und das dauert relativ lange.
Eine Replica kann ich aufstarten, auch im Dummynetz oder ohne Netzerk, was aber bei multi-Server-Systemen bedeutet, dass beispielsweise vom gleichen Zeitpunkt SQL-Server- ANWENDUNGX-Webserver. ANWENDUNGX-Applicationserver und weitere davon abhängige Server mit Lizenzservern und so weiter zurückgespielt werden müssten / aufgestartet werden müssten. Das ist relativ komplex und bei den großen VMs teils schwer zu handhaben.
Der besagte Server ist jetzt auch kein solcher, bei dem es um Leben und tot geht, aber da das jetzt das dritte Mal ist, dass eine VM in diesem Zustand hängt, dachte ich, vielleicht bin ich ja nicht der erste oder der einzige, der das erlebt und vielleicht hat jemand eine Idee, wie man möglicherweise auch die Ursache ausfindig machen könnte.

Gruß,
Christian

Moin,

aber wenn 100GB 4h Restorezeit sind, dann bist du echt schlecht aufgestellt.

nicht immer fährt man ein Backup2Disk2Tape. Aus welchen Gründen auch immer...
Manche sichern direkt auf Band und dann kann es mitunter schon mal etwas dauern. Insbesondere, wenn das Tape im Server per SAS hängt und der Backupserver nur mit 1GBit (oder n x 1GBit/s) am LAN hängt. Beim normalen Backup ist es ja wurscht, ob dann das tägliche Delta 1h oder 3h benötigt (sofern Nachts nicht gearbeitet wird)...

Gruß
em-pie

@silent-daniel
Okay, da haben sich die zeiten überschnitten, diese Funktion von VBR11 war mir bislang so nicht bekannt.
Unter diesen Umständen wird das wahrscheinlich einfacher gehen. Ich werde das mal testen, wenn der Neustart vollzogen ist und dann hoffentlich die Snapshots auch wieder entdeckt und konsolidiert werden können.
Wie man sie auf shell-Ebene konsolidieren kann, weiß ich nicht, und im GUI werden sie nicht gesehen.

Da werde ich mich entsprechend weiter bilden müssen...

Grüße,
Christian

auch wenn ich nicht daran glaube, aber du könntest mal schauen, ob du per PowerCLI irgendwelche Snapshots siehst:

Import-Module VMware.VimAutomation.Core
Connect-VIServer vCenter.company.tld

$SRV = Get-VM | Get-Snapshot | select VM, Name, Created

$SRV | sort VM, created | ft 

Write-Host "Count: " ($SRV | Measure).Count  

Achja: in welchem Status hängt Veeam mit dem Backup? Beende dort mal den ganzen Job (auf Disable setzen). Nicht, dass VEEAM da auch noch seine Finger mit im Spiel hat...

Powercli habe ich offenbar nicht installiert.
Ist das aufm VCenter oder ESXI?

Die Backups hängen nicht fest, ich habe aber beide (backup und replica) deaktiviert.
Es passt von den Zeiten her so zusammen, dass alle 16 Snapshots durch die Veeam-Prozesse angestoßen wurden.
Der Scheduler beginnt um 19:00, ab 19:04 sieht das Monitoring-Tool zabbix die VM nicht mehr.
Es wurden 4 Backups und 4 Replicas versucht und alle sind mit Error abgebrochen.
Es wurden nach dem ersten Fehlschlag auch noch weitere Versuche gestartet und die Erstellungszeitpunkte der snapshot vmdk-Dateien passen zeitlich mit den retrys und replicas.... zusammen.
Ich verstehe aber nicht, warum erfolgreich 2 Snapshots erstellt werden je versuch, wie es aussieht, aber keiner mehr gelöscht wurde.

Irgendwie scheint der erste Versuch das System in einen Zustand geschossen zu haben, in dem keine Snapshots mehr sichtbar waren von ESXI oder VCenter und die VM nicht mehr startet.

Sollte ich das Backup bei Misserfolg des Restores on the fly wiederherstellen, was passiert dann mit diesen ganzen vmdk-Dateien?

Grüße,
Christian

bzgl. PowerCLI:
https://docs.vmware.com/de/VMware-vSphere/7.0/com.vmware.esxi.install.do ...

Die Backups hängen nicht fest, ich habe aber beide (backup und replica) deaktiviert.
Es passt von den Zeiten her so zusammen, dass alle 16 Snapshots durch die Veeam-Prozesse angestoßen wurden.

Ich hab mit den Replicas, zugegeben, null komma garkeinen Plan, aber so generell: Die Jobs laufen sequentiell und nicht parallel, oder?

Nicht, dass da die Jobs parallel laufen und sich gegenseitig abschießen...

Zitat von @em-pie:
Nicht, dass da die Jobs parallel laufen und sich gegenseitig abschießen...

Nein, die reihen sich ein, falls das backup noch laufen sollte. Wenn eini Replica desselben Rechners gestartet wird, wenn der Backupkob schon läuft, wartet der meines Wissens nach.

Aber hier war das nicht der Fall, der Backup war einer der ersten, die loslaufen.

Also der Neustart des ESXi mit und ohne laufenden VCenter (nach migrieren der aktiven VMs auf einen anderen ESXi) hat nicht zum Erfolg geführt. Auch das Migrieren auf einen anderen ESXi hat nicht geholfen.

Letztlich blieb nur die Möglichkeit, die silent-daniel vorgeschlagen hat:

Zitat von @silent-daniel:

Sorry ja ich weiß, aber wenn 100GB 4h Restorezeit sind, dann bist du echt schlecht aufgestellt. (7-8mb/s)
Außerdem kann man bei VBR11 auch "onthefly" starten, also vom Backup Medium starten und im Laufenden Betrieb wieder zurück auf den Server schieben, mit kurzer Unterbrechung wenn fertig.

-> Backup Kontrolle ist wichtig!!! Ich kenne einen Kunden, bei dem hat das Backup auch immer "funktioniert" bis er es gebaucht hat.

Vor allem musst du ja bei VBR11 nicht die VM löschen, sondern sagst einfach diesen Stand wiederherstellen und er spielt nur die "paar" GB zurück, die sich geändert haben...

Ich würden den ESX einfach mal Neu starten (am Abend), evtl. lösen sich gewisse Probleme dann von selbst (konsolidieren funktioniert wieder,....)

Allerdings konnte ich die VM nicht eingeschaltet lassen, während der Storage-Migration. Das ließ angeblich die Lizenz nicht zu. Die Frage wäre dann wohl, ob das Mit EssentialPlus normalerweise gehen sollte oder nicht. Ansonsten muss ich die eingespielten Lizenzen noch einmal überprüfen.

Aber im ausgeschalteten Zustand ließ sich die VM innerhalb von ca. 5-6 Stunden auf den produktiven Datastore migrieren.

Sehr gut an dieser Option finde ich, dass das Storage, auf das die Backups laufen, nicht einmal unbedingt auf der Kompatibilitätsmatrix der Vmware-Version passen muss. Veeam BR11 bastelt da quasi sein eigenes, kompatibeles Format zusammen.
Gut zu wissen.

Abschließend noch einmal herzlichen Dank an alle, die helfen wollten.

Grüße,
Christian

Nein Essential Plus beinhaltet tatsächlich kein Storage vMotion im eingeschalteten Zustand, nur Host vMotion. Wir haben die Lizenz auch.

Okay, dann werde ich mal bei vmware und veeam nachhaken, ob irgendwas von dem Verhalten bekannt ist.
Grüße,
Christian

Um das abzuschließen: Das Starten auf dem Backup-Laufwerk hat geklappt, der lief auch. Das Bewegen habe ich dann aber im ausgeschalteten Zustand gemacht.
Ursache für die extrem langsame Wiederherstellung war allerdings, dass ich im Veeam / der VMWare keine entsprechenden Proxies eingerichtet hatte. Nicht nur die Backups, auch die Replications dauern jetzt nicht mehr so lang und das Zurückspielen geht auch viel schneller, sagt der Support. Glücklicherweise ist das seither nie wieder vorgekommen und ich drücke die Daumen, dass es dabei bleibt.

German solved Question VMware Virtualization

Hotly discussed

Developer diary: Release 6.1admtech

End of availability for classic Teams clientDani