Wenn eine Hyper-V-VM nicht gestartet werden kann, weil sie im Zustand „Gespeicherter Status“ feststeckt, kommt Ihre Arbeit zum Erliegen. Dieses Problem tritt häufig bei IT-Administratoren auf – insbesondere nach einem Neustart des Hosts oder während der Notfallwiederherstellung. In dieser Anleitung erklären wir, was ein gespeicherter Status in Hyper-V ist, warum Ihre VM möglicherweise nicht aus diesem Zustand heraus starten kann, welche Auswirkungen das Löschen dieses Zustands hat und wie Sie Schritt für Schritt eine festgehangene VM wieder zum Laufen bringen. Außerdem behandeln wir erweiterte Fehlerbehebungsmethoden für komplexe Umgebungen und geben bewährte Verfahren an die Hand, um solche Probleme künftig zu vermeiden.
Was ist der gespeicherte Zustand in Hyper-V?
Der gespeicherte Zustand in Hyper-V erfasst zu einem bestimmten Zeitpunkt sämtliche Informationen über Ihre laufende virtuelle Maschine – darunter den Inhalt des Arbeitsspeichers und den Status der Geräte –, sodass Sie die Arbeit unterbrechen und zu einem späteren Zeitpunkt fortsetzen können, ohne Fortschritte zu verlieren. Wenn Sie eine virtuelle Maschine in den gespeicherten Zustand versetzen, erstellt Hyper-V zwei wichtige Dateien im zugehörigen Ordner: .bin für die Arbeitsspeicherdaten und .vsv für den Gerätekontext.
Mit diesen Dateien kann Hyper-V die Aktivität Ihrer virtuellen Maschine sicher anhalten. Die Datei mit der Endung .bin enthält eine exakte Kopie dessen, was im Arbeitsspeicher (RAM) gespeichert war, als Sie die virtuelle Maschine mithilfe der Option Save anstelle von Turn Off oder Shut Down pausiert oder heruntergefahren haben. Die Datei mit der Endung .vsv speichert Details wie CPU-Register und Puffer der Netzwerkadapter.
Warum ist das wichtig? Wenn Sie Ihren Host-Server neu starten oder Wartungsarbeiten durchführen müssen, aber möchten, dass Ihre virtuellen Maschinen genau dort weitermachen, wo sie zuvor unterbrochen wurden – und nicht einfach nur neu gestartet werden –, sind Sie auf diese Dateien angewiesen. Einige Sicherungstools aktivieren zudem gespeicherte Zustände, um konsistente Momentaufnahmen zu erstellen, ohne die Gastbetriebssysteme herunterfahren zu müssen.
Es ist wichtig, gespeicherte Zustände nicht mit Wegmarken (Momentaufnahmen) zu verwechseln. Wegmarken umfassen auch Änderungen an der Festplatte; gespeicherte Zustände bewahren ausschließlich Daten des flüchtigen Arbeitsspeichers.
Warum startet meine Hyper-V-VM nicht?
Wenn Ihre VM beim Wiederherstellen aus einem gespeicherten Zustand hängen bleibt und nicht hochfährt, lautet die Fehlermeldung oft etwa folgendermaßen
„Fehler beim Wiederherstellen des Zustands der virtuellen Maschine“ oder
„Die virtuelle Maschine ist nicht mit dem physischen Computer kompatibel.“
Dieses Problem weist darauf hin, dass bei der Speicherung und Wiederherstellung dieser Arbeitsspeicher-Sicherungskopie etwas schiefgelaufen ist. Wir gehen nun mögliche Ursachen durch:
Zunächst verhindern beschädigte .bin- oder .vsv-Dateien das Fortsetzen, da kritische Informationen fehlen oder nicht lesbar sind. Hardwareänderungen sind ein weiterer Grund: Wenn Sie eine VM zwischen Hosts mit unterschiedlichen CPUs verschieben oder die Hardwareeinstellungen ändern (z. B. Netzwerkadapter hinzufügen oder entfernen), passt das alte Arbeitsspeicherabbild möglicherweise nicht mehr zu den Anforderungen der neuen Hardware.
Ressourcenengpässe sind ebenfalls verbreitet – ein Host mit unzureichendem freiem Arbeitsspeicher oder Festplattenspeicher kann große Speicherabbilder einfach nicht wieder in den Betrieb laden. Speicherprobleme wie getrennte Laufwerke oder geänderte Laufwerksbuchstaben bedeuten, dass Hyper-V diese lebenswichtigen Dateien überhaupt nicht finden kann.
Berechtigungen sind ebenfalls wichtig: Wenn die Windows-Sicherheitseinstellungen den Zugriff auf einen Teil des VM-Ordners blockieren – auch nachdem Antiviren-Scans Dateien gesperrt haben – werden Fehlermeldungen zu verweigertem Zugriff angezeigt.
Schließlich können unterbrochene Sicherungsaufgaben manchmal virtuelle Maschinen mitten im Prozess in einem nicht verwendbaren Zustand zurücklassen.
Für Clusterumgebungen mit gemeinsam genutztem Speicher (Clusterfreigegebene Volumes) ergibt sich zusätzliche Komplexität: Live-Migrationen zwischen Knoten können zu Versionskonflikten führen, wenn die Hosts unterschiedliche Versionen von Windows Server ausführen oder unterschiedliche Patch-Stände aufweisen.
Manchmal hilft sogar das Löschen des gespeicherten Zustands nicht, wenn tiefer liegende Konfigurationsprobleme vorliegen – beispielsweise inkompatible Firmware-Typen (VMs der 1. vs. der 2. Generation) oder unterschiedliche Versionen der Integrationsdienste auf den Hosts.
Was passiert, wenn Sie den gespeicherten Status in Hyper-V löschen?
Durch das Löschen des gespeicherten Status werden sowohl die Dateien .bin als auch .vsv aus dem Ordner Ihrer virtuellen Maschine entfernt. Dadurch wird Ihre virtuelle Maschine gezwungen, neu zu starten – so, als hätte jemand ihr stromversorgungskabel gezogen, anstatt sie ordnungsgemäß herunterzufahren.
Was bedeutet dies für Ihre Daten? Alle nicht gespeicherten Arbeiten, die sich ausschließlich im Arbeitsspeicher (RAM) befinden, gehen für immer verloren; hingegen bleiben alle Daten, die auf virtuelle Festplatten geschrieben wurden, sicher, da diese durch das alleinige Löschen von Arbeitsspeicherabbildern nicht betroffen sind.
Dieser Ansatz löst häufig Inkompatibilitätsprobleme, die durch beschädigte Zustände verursacht werden – vergewissern Sie sich jedoch stets, dass Sie vor dem Entfernen dieser Dateien auf Produktionssystemen Sicherungskopien besitzen! Das Löschen ist in der Regel sicher, führt aber zu einem unwiderruflichen Verlust nicht gespeicherter Anwendungsdaten innerhalb der Gastbetriebssysteme.
Wenn Sie Clusterhosts mit gemeinsam genutzten Clustervolumes (CSV) betreiben, beachten Sie, dass das Löschen gespeicherter Statusinformationen, während andere Knoten weiterhin auf sie verweisen, zu weiteren Synchronisationsproblemen führen kann, es sei denn, dies wird sorgfältig über den Failover-Cluster-Manager durchgeführt.
So beheben Sie einen Hyper-V-VM, der im gespeicherten Zustand hängen geblieben ist
Wir gehen gemeinsam Lösungen durch – von einfachen Korrekturen bis hin zu fortgeschrittenen Wiederherstellungsmethoden, die auch für Unternehmensumgebungen geeignet sind, einschließlich Cluster. Jede Methode beginnt mit einer Übersicht, bevor auf die einzelnen Schritte eingegangen wird, sodass Sie bereits vor dem eigenen Ausprobieren verstehen, warum sie funktioniert.
Methode 1. Gespeicherten Zustand mithilfe des Hyper-V-Managers löschen
Die meisten Administratoren beginnen hier, da dies schnell – und oft wirksam – kleine Probleme im Zusammenhang mit beschädigten Sicherungsdateien behebt.
Beginnen Sie damit, den Hyper-V-Manager zu öffnen, und wählen Sie dann Ihre fehlerhafte VM aus der Liste im linken Bereich aus. Klicken Sie im rechten Bereich unter Actions auf Delete Saved State; bestätigen Sie die Aufforderung. Versuchen Sie nun erneut, Ihre VM über Start unter Aktionen zu starten – sie sollte sauber booten, als wäre sie zuvor ausgeschaltet worden.
Methode 2: Überprüfen Sie die Host-Ressourcen und den verfügbaren Speicherplatz
Falls das Löschen nicht geholfen hat – oder nicht verfügbar ist – sollten Sie als Nächstes prüfen, ob Ressourcenengpässe den Startvorgang behindern.
Stellen Sie zunächst sicher, dass auf Ihrem Host-Server ausreichend freier Arbeitsspeicher verfügbar ist; öffnen Sie den Task-Manager, wechseln Sie zur Registerkarte Performance und überprüfen Sie die verfügbare Arbeitsspeichermenge, während alle anderen Workloads normal ausgeführt werden.
Als Nächstes überprüfen Sie den verfügbaren Speicherplatz: Öffnen Sie den File Explorer, klicken Sie mit der rechten Maustaste auf das bzw. die Systemlaufwerke und wählen Sie Properties. Vergleichen Sie dann die angezeigten Werte für den freien Speicherplatz mit den erwarteten Anforderungen für große VMs.
Falls VMs auf externen Laufwerken oder SAN-/NAS-Geräten gespeichert werden, die über Laufwerksbuchstaben zugeordnet sind, vergewissern Sie sich bitte zweimal, dass diese Zuordnungen seit dem letzten erfolgreichen Start nicht geändert wurden; falsche Pfade verhindern Wiederherstellungsversuche.
Für Clusterbereitstellungen mit CSVs stellen Sie sicher, dass alle Knoten über den Failover-Cluster-Manager identische Speicherpfade sehen – andernfalls können fehlerbedingte Probleme im Zusammenhang mit der Migration auftreten.
Methode 3. Berechtigungen für Virtual-Machine-Dateien korrigieren
Fehler „Zugriff verweigert“ deuten normalerweise auf beschädigte NTFS-Berechtigungen in Ihren VM-Ordnern hin – häufig nach manuellen Verschiebungen oder Kopiervorgängen außerhalb unterstützter Tools.
Stellen Sie sicher, dass das Konto mit dem Namen NT VIRTUAL MACHINE\<GUID> über die Berechtigung „Vollzugriff“ auf alle enthaltenen Elemente verfügt (.vhdx, .bin, *.vsv). Falls diese Berechtigung fehlt:
1. Klicken Sie auf Add
2. Geben Sie den Objektnamen genau ein
3. Vollzugriff gewähren
4. Rekursiv anwenden
Alternativ Command-Eingabeaufforderung als Administrator starten (nicht PowerShell), dann folgenden Befehl ausführen:
icacls.exe "C:\Pfad\Zum\VM\{VM-GUID}.bin" /grant "NT VIRTUELLE MASCHINE\{VM-GUID}":(F)
icacls.exe "C:\Pfad\Zum\VM\{VM-GUID}.vsv" /grant "NT VIRTUELLE MASCHINE\{VM-GUID}":(F)Falls die Berechtigungsvererbung vollständig gestört zu sein scheint, verwenden Sie die Option /reset:
icacls.exe "C:\Pfad\Zur\VM\" /reset /T
Überprüfen Sie die Ergebnisse stets erneut, indem Sie vor dem erneuten Startversuch den Zugriff über den Datei-Explorer testen.
Methode 4: Gespeicherte Statusdateien manuell löschen
Manchmal lösen weder die grafische Benutzeroberfläche noch Berechtigungskorrekturen das Problem – in diesem Fall ist eine direkte Löschung erforderlich.
Bevor Sie fortfahren:
1) Bestätigen Sie, dass keine aktiven Sicherungen/Prüfpunkte vorhanden sind
2) Verwenden Sie den Ressourcenmonitor (resmon.exe) > Registerkarte „CPU“ > Suchleiste „Zugeordnete Handles“; geben Sie einen Teil des Dateinamens ein (.bin, .vsv), um sicherzustellen, dass keine Anwendung die Zieldateien blockiert.
3) Falls gesperrt, den betreffenden Prozess/dienst zuerst beenden
Jetzt:
1) Betroffene VM vollständig herunterfahren, falls möglich
2) Dienste-Konsole öffnen (services.msc)
3) Suchen Sie den Dienst mit dem Namen Hyper-V Virtual Machine Management
4) Rechtsklicken > Stop auswählen
5) Navigieren Sie erneut zu C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines
6) Löschen Sie sowohl die Dateien .bin als auch .vsv, die zur hängenden Instanz-GUID passen.
7) Verwaltungsdienst über dieselbe Konsole neu starten (Start)
8) Versuchen Sie, die betroffene VM erneut zu starten
Methode 5: Aktualisieren der Konfigurationsversion der virtuellen Maschine
Ältere virtuelle Maschinen, die unter früheren Versionen von Windows Server erstellt wurden, speichern möglicherweise Speicherzustandsformate, die nach Upgrades oder Migrationen mit neueren Hosts inkompatibel sind – ein häufiges Problem bei der Erneuerung der Infrastruktur.
In solchen Fällen:
1) Stellen Sie sicher, dass die Ziel-VM vollständig heruntergefahren ist – nicht nur angehalten oder gespeichert!
2) Öffnen Sie den Hyper-V-Manager
3) Gewünschte Instanz auswählen
4) Klicken Sie im Bereich „Aktionen“ auf Upgrade Configuration Version
5) Bestätigen Sie das Upgrade, wenn Sie dazu aufgefordert werden
Anschließend versuchen Sie erneut den normalen Start; die meisten Kompatibilitätsprobleme verschwinden, sobald die Metadaten den aktuellen Plattformstandards entsprechen.
Methode 6: Netzwerkadapter-Konflikte und Host-Kompatibilitätsprobleme beheben
Fehlermeldungen bezüglich einer Unkompatibilität resultieren häufig aus falschen Konfigurationen des Netzwerkadapters nach Migrationen zwischen Hosts oder nach Umbenennung bzw. Entfernung zugehöriger virtueller Switches.
Öffnen Sie den Open Virtual Network Manager innerhalb der Hyper-V-Manager-Oberfläche; stellen Sie sicher, dass jeder angehängte Adapter mit gültigen Switch-Namen übereinstimmt, die lokal auf dem bzw. den neuen Hostknoten vorhanden sind.
Falls erforderlich:
Umbenennen Sie die Switches wieder um, damit die Namen auf den Quell- und Zielservern übereinstimmen
Adapter direkt im Einstellungsdialog des jeweils betroffenen Gasts neu zuweisen
Für fortgeschrittene Benutzer: Überprüfen Sie die Eindeutigkeit der MAC-Adresse über alle Adapter mithilfe von PowerShell:
Get-VMNetworkAdapter -All | Select Name,MacAddress
Doppelte MAC-Adressen können insbesondere nach dem gleichzeitigen Importieren oder Exportieren mehrerer Gastsysteme zu subtilen Verbindungsproblemen führen.
Methode 7: Exportieren und erneutes Importieren der Konfiguration der virtuellen Maschine
Falls ein Neuaufbau zu störend erscheint, die Beschädigung jedoch weiterhin auf Konfigurationsebene besteht, versuchen Sie stattdessen, die Metadaten zu exportieren und wieder zu importieren:
1) PowerShell-Fenster mit erhöhten Rechten starten
2) Führen Sie Export-VM -Name "<Your_VM_Name>" -Path "<Export_Directory>" aus.
3) Entfernen Sie die ursprüngliche Instanz aus dem Bestand (löschen Sie die Festplatten nicht!)
4) Importieren Sie die VM erneut mithilfe von Import-VM -Path "<Export_Directory>\<Config_File>.xml"
5) Vorhandene Festplatten während der Assistentenabfragen beim Importieren anhängen
Dieser Vorgang aktualisiert interne Referenzen, ohne die Benutzerdaten in den angehängten Volumes zu verändern.
Methode 8: Virtuelle Maschine mithilfe vorhandener Festplatten neu erstellen (letzter Ausweg)
Als letzte Maßnahme dokumentieren Sie zunächst alle aktuellen Einstellungen – darunter zugewiesene CPUs, RAM und Netzwerkkonfiguration – über die ursprünglichen Konfigurationsbildschirme im Verwaltungswerkzeug.
Löschen der fehlgeschlagenen Instanz ohne weitere Überprüfung (ENTFERNEN Sie NICHT die .vhdx/.avhdx-Dateien!)
Erstellen Sie eine völlig neue Gästezuordnung gemäß den vorherigen Spezifikationen.
Wählen Sie im Assistenten die Option „Vorhandene virtuelle Festplatte verwenden“, die direkt auf die gesicherte(n) Speicherdatei(en) verweist.
Neue Instanz starten – sie sollte sich identisch verhalten, läuft jedoch nun auf einer sauberen Metadaten-/Konfigurationsebene.
Schützen Sie Ihre Hyper-V-Virtuellen Maschinen mit Vinchin
Um unerwartete Ausfallzeiten durch Probleme wie „gespeicherter Status kann nicht gestartet werden“ weiter zu vermeiden, sollten Sie einen leistungsstarken Sicherungsschutz für Ihre Umgebung implementieren. Vinchin zeichnet sich als Enterprise-Lösung aus, die speziell für professionelle Sicherungen virtueller Maschinen auf über 15 gängigen Plattformen entwickelt wurde – darunter vollständige Unterstützung für Microsoft Hyper‑V neben VMware, Proxmox VE, oVirt, OLVM, RHV, XCP-ng, XenServer, OpenStack, ZStack und anderen.
Vinchin bietet umfassende Funktionen wie inkrementelle Sicherungen für immer (zur Minimierung des Speicherplatzbedarfs), integrierte Deduplizierung und Komprimierung (zur Optimierung der Leistung), nahtlose plattformübergreifende V2V-Migration, geplante oder wiederholte Sicherungen zur Automatisierung – und vieles mehr.
Mit der intuitiven Webkonsole von Vinchin erfolgt die Sicherung einer Hyper‑V‑VM in nur vier Schritten:
1. Wählen Sie den spezifischen Hyper‑V-Computer aus dem Bestand aus;
2. Wählen Sie den Speicherort für die Sicherungskopien aus;
3. Konfigurieren Sie Strategien wie Terminplanung, Entduplizierung und Verschlüsselung entsprechend den Anforderungen der jeweiligen Richtlinie;
4. Die Aufgabe einreichen.
Von Tausenden Organisationen weltweit vertraut – mit durchgehend hohen Bewertungen – bietet Vinchin eine risikofreie Möglichkeit, seine volle Leistungsfähigkeit durch eine kostenlose 60-Tage-Testlizenz kennenzulernen, die sämtliche verfügbaren Funktionen abdeckt.
FAQs zu Hyper‑V-Gespeicherten Zuständen, die nicht gestartet werden können
F1: Kann ein Update meines Windows Servers dazu führen, dass gespeicherte Zustände laufender virtueller Maschinen nicht mehr gestartet werden können?
A1: Ja – ein größeres Update kann zugrundeliegende Komponenten verändern, wodurch alte Speicherstände inkompatibel werden, bis sie manuell gelöscht oder ordnungsgemäß aktualisiert werden.
F2: Wie kann ich schnell überprüfen, welcher Prozess meine .bin/.vsv-Datei blockiert?
A2: Ressourcenmonitor öffnen > Registerkarte „CPU“ > einen Teil des Dateinamens in der Spalte „Zugeordnete Handles“ eingeben > den sperrenden Prozess/dienst sofort identifizieren!
F3: Was muss ich tun, wenn ein Clusterknoten während der Live-Migration ausfällt und mehrere VMs hängen bleiben?
A3: Failover-Cluster-Manager verwenden > Rollenbesitz vorübergehend verschieben > den Zustand manuell pro betroffenem Gast löschen/speichern, bevor die Workload-Besitzrechte zurückgegeben werden.
Fazit
Ein „gespeicherter Zustand“, der hängen bleibt, kann den Geschäftsbetrieb stören – doch gezielte Fehlersuche lässt die meisten virtuellen Maschinen rasch wieder starten und vermeidet unnötige Neuinstallationen. Regelmäßige Sicherungen bleiben unverzichtbar. Vinchin macht den Schutz selbst komplexer Multi-Host-Umgebungen einfach, zuverlässig und effizient. Probieren Sie Vinchin noch heute aus – und halten Sie Ausfallzeiten fern!
