Hyper-V: VM startet nicht – Checkpoint-Kette reparieren

Eine virtuelle Maschine bleibt in Hyper-V im Status „Wird gestartet“ hängen, bricht mit 0x80070057 ab oder lässt sich gar nicht erst einschalten. Häufig steckt keine defekte Festplatte dahinter, sondern eine Kette aus Prüfpunkten, die nie zusammengeführt wurde.

Der folgende Ablauf zeigt, wie Admins die Kette sichtbar machen, verwaiste AVHDX-Dateien sauber mergen und den Fehler künftig vermeiden – ohne Laborumgebung, mit den Bordmitteln von Windows Server.

Ursache: Ein Prüfpunkt, der nie aufgeräumt wurde

Seit Windows Server 2012 R2 schreibt Hyper-V alle Änderungen während eines Prüfpunkts in eine differenzierende AVHDX-Datei. Die ursprüngliche VHDX bleibt unverändert und wird zur Elternplatte. Wird der Prüfpunkt gelöscht, führt Hyper-V die Änderungen automatisch zurück.

Genau dieser Schritt scheitert in der Praxis oft: Backup-Software erzeugt Prüfpunkte über VSS und muss sie nach dem Job entfernen. Bricht die Sicherung ab, fehlt Platz oder hält ein Virenscanner die Datei, bleibt die Kette stehen. Hyper-V-Manager zeigt dann unter Umständen gar keinen Prüfpunkt mehr an, obwohl im VM-Ordner mehrere AVHDX-Dateien liegen.

Typische Fehlerbilder sind 0x80070032 (Kette beschädigt oder unterbrochen), 0x80070020 (Datei gesperrt) und die Meldung „Catastrophic failure“ beim Löschen eines Prüfpunkts.

Diagnose: Kette und Sperren sichtbar machen

Drei PowerShell-Befehle auf dem Hyper-V-Host genügen für den ersten Überblick. Wichtig ist der Wert ParentPath: Steht dort eine AVHDX, hängt die VM an einer Kette.

Get-VM -Name "FS01" | Select-Object Name, State, Status
Get-VMSnapshot -VMName "FS01"
Get-VMHardDiskDrive -VMName "FS01" | ForEach-Object {
    Get-VHD -Path $_.Path | Select-Object Path, ParentPath, VhdType
}

Zusätzlich lohnt ein Blick in den VM-Ordner: Alle Dateien mit den Endungen .avhdx, .mrt und .rct sollten sich in der Kette wiederfinden. Was dort liegt, aber nirgends referenziert wird, ist ein Kandidat für einen verwaisten Prüfpunkt.

Parallel das Ereignisprotokoll Microsoft-Windows-Hyper-V-VMMS/Admin prüfen und den freien Speicher auf dem Volume erfassen. Für einen Merge wird im Idealfall Platz in Größe der virtuellen Festplatte benötigt – fehlt er, bricht Hyper-V mitten im Zusammenführen ab.

Lösung 1: Sichtbare Prüfpunkte regulär entfernen

Zeigt Hyper-V-Manager die Prüfpunkte an, ist der Weg kurz. Der folgende Befehl löscht alle Prüfpunkte der VM und stößt das Zusammenführen an:

Get-VMSnapshot -VMName "FS01" | Remove-VMSnapshot

Fehlt der Eintrag „Prüfpunkt löschen“ im Kontextmenü, den Prüfpunkt markieren und die Entf-Taste drücken – das entspricht demselben Vorgang. Hängt der Merge anschließend, hilft ein kontrolliertes Herunterfahren der VM: Der Shutdown startet den Merge erneut, sofern die Dateien nicht gesperrt sind.

Bleibt es dabei, führt der manuelle Weg über den Hyper-V-Manager: Datenträger bearbeiten → AVHDX auswählen → Zusammenführen → Mit übergeordnetem Datenträger. Bei mehreren Dateien von der jüngsten zur ältesten Kette arbeiten.

Lösung 2: Verwaiste AVHDX manuell zusammenführen

Sind die Prüfpunkte im Manager unsichtbar, müssen die Dateien direkt verarbeitet werden. Zuvor die VM ausschalten und alle AVHDX-Dateien wegkopieren – ein Merge ist nicht umkehrbar. Danach Kind für Kind in die Elternplatte führen:

Merge-VHD -Path "D:\VMs\FS01\FS01-2.avhdx" -DestinationPath "D:\VMs\FS01\FS01-1.avhdx"
Merge-VHD -Path "D:\VMs\FS01\FS01-1.avhdx" -DestinationPath "D:\VMs\FS01\FS01.vhdx"

Anschließend die VM-Konfiguration auf die Basis-VHDX umbiegen, sonst zeigt sie weiter auf eine Datei, die es nicht mehr gibt:

Set-VMHardDiskDrive -VMName "FS01" -ControllerType SCSI -ControllerNumber 0 `
    -ControllerLocation 0 -Path "D:\VMs\FS01\FS01.vhdx"

Bei mehr als 50 Prüfpunkten ist Geduld gefragt: dann sequenziell mergen und mit Pausen arbeiten. Ein Merge bei laufender VM ist nur mit einem Skript möglich, das die Kette über Get-VHD rekursiv abarbeitet.

Lösung 3: Platz, Sperren und Rechte prüfen

0x80070020 bedeutet fast immer eine Dateisperre. ProcMon oder die Ressourcenüberwachung zeigen, welcher Prozess die AVHDX offen hält; häufig ist es der Backup-Dienst oder ein Virenscanner. Nach dem Beenden des Prozesses Hyper-V-Verwaltung und VSS neu starten und den Merge wiederholen.

Bei Rechteproblemen muss die Gruppe NT VIRTUAL MACHINE\Virtual Machines das Recht „Als Dienst anmelden“ besitzen und Vollzugriff auf den VM-Ordner haben. Für den Ordner setzt dieser Befehl die Rechte neu:

icacls "D:\VMs\FS01" /grant "NT VIRTUAL MACHINE\Virtual Machines:(OI)(CI)F" /T

Vorbeugung im Alltag

Im Produktivbetrieb ausschließlich Produktionsprüfpunkte verwenden und AVHDX-Dateien niemals im Explorer löschen. Der Backup-Job sollte die Prüfpunkte selbst aufräumen; ein Blick in die Job-Historie zeigt, ob das zuverlässig passiert. Eine Speicherwarnung bei 20 Prozent freiem Platz auf dem VM-Volume verhindert abgebrochene Merges.

Zusätzlich gehören die VM-Ordner in die Ausnahmeliste des Virenscanners – empfohlen sind .vhdx, .avhdx und der Prozess vmwp.exe. Sonst kollidiert der Echtzeitscanner genau in dem Moment mit dem Merge, in dem die Datei exklusiv geöffnet wird.

Fazit

Ein Großteil der Startprobleme in Hyper-V ist kein Hardwaredefekt, sondern eine liegengebliebene Prüfpunkt-Kette. Wer Zustand, Kette und freien Speicher prüft, bevor er mergt, kommt ohne Datenverlust durch – und mit einer sauberen Backup-Überwachung gar nicht erst in die Lage.

FAQ

Kann ich die AVHDX einfach löschen? Nein. In der AVHDX stecken alle Änderungen seit dem Prüfpunkt – Löschen bedeutet Datenverlust bis zum Stand der Elternplatte.

Warum startet die VM nach dem Merge nicht? Meist zeigt die Konfiguration noch auf die entfernte AVHDX oder der Elternpfad passt nicht. Mit Get-VHD prüfen und den Pfad per Set-VMHardDiskDrive korrigieren.

Geht das ohne Downtime? Nur mit einem Skript, das die Kette bei laufender VM abarbeitet – und ausreichend freiem Speicher. Im Zweifel ist ein Wartungsfenster der sichere Weg.

Quellen

Hinweis: Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz (KI) erstellt.

Tags

No responses yet

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert