Welche Hyper-V-Fehlermeldung bedeutet was? Fehlercodes und Statusmeldungen technisch einordnen

Fehlermeldungen und Statuscodes in Hyper-V: Ebenenmodell, Abhängigkeiten und Diagnosekontext (Host, Gast, Infrastruktur)

Hyper-V-Fehler wirken selten isoliert. Die Virtualisierungsschicht vermittelt zwischen Firmware und CPU-Features, Hostbetriebssystem und Treibern, Storage-Stack und Dateisystem, Switch-/NIC-Pfad sowie Gastbetriebssystem und Integrationsdiensten. Statusmeldungen und Fehlercodes sind deshalb primär Signale darüber, an welcher Stelle eine Abhängigkeit nicht erfüllt wird oder ein Garant (z. B. Ressourcenreservierung, Konsistenz, Sicherheit) nicht mehr gehalten werden kann. Für eine belastbare Diagnose ist eine Einordnung nach Ebenen und ein präziser Kontext aus Ereignisprotokollen, Hyper-V-Worker-Prozessen und WMI/VMMS zwingend.

Ebenenmodell: Wo Hyper-V tatsächlich „fehlschlägt“

Ein praxisnahes Ebenenmodell trennt (1) Hostebene (Hyper-V-Rolle, VMMS, vmwp.exe, Treiber, Security Token), (2) Infrastrukturebene (Storage/CSV/SMB, Netzwerk, Cluster, Domänendienste, Zeitquelle) und (3) Gastebene (Bootloader, Treiber, Dateisystem, Integrationsdienste). Meldungen wie „Allgemeiner Zugriff verweigert“ oder „Das System kann die angegebene Datei nicht finden“ erscheinen in Hyper-V-Dialogen häufig als generische Hülle; die Ursache liegt aber in einem vorgelagerten Stack, etwa im Filtertreiber eines AV-Produkts, in NTFS-Rechten, in einem SMB-Share-Zustand oder in einem fehlenden CPU-Virtualisierungsfeature.

Technisch wird die Ausführung einer VM durch den Virtual Machine Worker Process (vmwp.exe) getragen, dessen Lebenszyklus vom Hyper-V Virtual Machine Management Service (vmms.exe) gesteuert wird. Kommt es zu Start- oder Laufzeitfehlern, ist entscheidend, ob der Worker nicht erstellt werden kann (Host-/Security-/Ressourcenthema), ob der Worker startet, aber Ressourcen nicht binden kann (Storage/Netzwerk/Memory), oder ob der Gast zwar läuft, aber Integrationspfade ausfallen (Gastebene).

Abhängigkeiten als Fehlerverstärker: CPU, Firmware, Host-OS, Treiber

Hardwarevirtualisierung (Intel VT-x/AMD-V) und Second Level Address Translation (SLAT) sind nicht nur Voraussetzungen, sondern beeinflussen auch die Art der Fehlbilder. Fehlt die Virtualisierungserweiterung oder blockiert die Firmware-Konfiguration, scheitert bereits die Hypervisorinitialisierung. Kommt es dagegen zu Konflikten im Virtual Secure Mode oder mit anderen Hypervisoren, erscheinen Startfehler, obwohl die CPU-Fähigkeiten prinzipiell vorhanden sind. Ebenso kritisch sind Treiberketten: NDIS-Filter, Storage-Miniports, HBA-Firmware und Dateisystemfilter können Hyper-V-Meldungen auslösen, die semantisch nach „VM-Problem“ aussehen, tatsächlich aber Kernelpfade betreffen.

In der Praxis erleichtert ein Abhängigkeitscheck über Systeminformationen und Hyper-V-spezifische Abfragen die Einordnung. Relevant sind dabei Hypervisorstatus, VM-Konfiguration und Event-Korrelation. Der Diagnosekontext entsteht aus Zeitbezug (korrelierte Event-IDs), aus dem betroffenen Objekt (VM-GUID, VHDX-Pfad, vSwitch-Name) und aus der Ebene, auf der der erste Fehler auftritt.

• Hypervisor-Präsenz/Startzustand (Host): systeminfo.exe (Abschnitt „Hyper-V-Anforderungen“), bcdedit /enum {current} (Wert hypervisorlaunchtype), Ereignisanzeige Microsoft-Windows-Hyper-V-Hypervisor
• VM-Konfiguration und Laufzeitstatus (Host): Get-VM -Name <VM> | Format-List *
Get-VMFirmware -VMName <VM>
Get-VMProcessor -VMName <VM>
• Worker-/Dienstkontext (Host): Get-Process vmwp -IncludeUserName zur Token-/Identitätsprüfung, Dienststatus via Get-Service vmms
• Storage-Bindung und Pfade (Infrastruktur/Host): Get-VMHardDiskDrive -VMName <VM> (VHDX-Pfade), Get-Item -LiteralPath <Pfad> (Existenz/Rechte), bei SMB: Get-SmbConnection
• Netzwerkpfad (Host/Infrastruktur): Get-VMSwitch, Get-VMNetworkAdapter -VMName <VM>, Host-NIC-Status via Get-NetAdapter

Diagnosekontext: Fehlerwortlaut, Codefamilien und Ereigniskorrelation

Hyper-V transportiert Fehler in mehreren Formen: klassische Win32-Fehler (z. B. 0x80070005 für „Zugriff verweigert“), COM-/HRESULT-Codes (z. B. 0x80004005 als unspezifischer E_FAIL), NTSTATUS-Fehler aus Kernelpfaden sowie hypervisorspezifische Codes (u. a. aus VMMS/Worker). Ein identischer Dialogtext kann je nach Ebene unterschiedliche Ursachen haben. „Der Vorgang ist fehlgeschlagen, weil ein erforderliches Objekt nicht gefunden wurde“ ist in Storage-Szenarien oft ein Pfad-/Rechteproblem, im Netzwerkbereich aber ein fehlender Switch oder Portprofilzustand. Deshalb gilt: Wortlaut ohne Code und ohne Event-Quelle bleibt technisch mehrdeutig.

Die zuverlässigste Zuordnung gelingt über die Quelle und den Zeitpunkt der ersten Abweichung: Ein VMMS-Fehler vor dem Start des Workers deutet auf Hostkonfiguration, Security oder Ressourcenmanagement. Fehler im Worker nach erfolgreicher Initialisierung sind häufiger an gebundene Ressourcen gekoppelt (VHDX öffnen, vNIC attachen, Checkpoint mergen). Meldungen aus Microsoft-Windows-Hyper-V-Integration oder aus dem Gast selbst sind dagegen typische Indikatoren für eine funktionierende VM-Ausführung bei gleichzeitig gestörtem Management-/Servicepfad.

Statusmeldungen als Frühwarnsystem: Auswirkungen auf HA, Performance, Datensicherheit

Statusmeldungen wie pausierte VMs, verzögerte Checkpoint-Merges oder degradierte Netzwerkpfade sind operative Signale, die oft lange vor einem harten Ausfall auftreten. In Clusterumgebungen führt ein Storage-Glitch nicht zwangsläufig sofort zum Stillstand, kann aber CSV-Umleitungen, erhöhte Latenzen und schließlich Heartbeat-Ausfälle provozieren. Ähnlich wirken instabile vSwitch-/NIC-Zustände: Der Gast läuft weiter, verliert aber Konnektivität; Management bewertet das als „läuft“, Applikationen verhalten sich jedoch wie bei einem partiellen Ausfall.

Für Hochverfügbarkeit ist die Ebene entscheidend: Ein reiner Gastfehler (z. B. Bootproblem) löst Failover nur aus, wenn Health-/Heartbeat-Mechanismen anschlagen. Ein Infrastrukturfehler (SMB/CSV) kann dagegen mehrere VMs gleichzeitig betreffen, inklusive Checkpoint-Ketten und laufender Sicherungen. Datensicherheit hängt dabei weniger von der sichtbaren Fehlermeldung ab als von der Konsequenz im I/O-Pfad: abgebrochene Merge-Vorgänge, wiederholte Timeouts und erzwungene Resets erhöhen das Risiko inkonsistenter Zustände, auch wenn Hyper-V anschließend „Erfolg“ meldet. Der Diagnosekontext muss deshalb immer I/O-Integrität (Storage), Kommunikationsintegrität (Netzwerk) und Steuerintegrität (Host-/Security-Kontext) gemeinsam betrachten.

VM-Start- und Laufzeitfehler: Konfiguration, Firmware/CPU-Virtualisierung, Integrationsdienste, Ressourcen- und Treiberabhängigkeiten

Start- und Laufzeitfehler virtueller Maschinen entstehen in Hyper-V selten „isoliert“ innerhalb der VM. Meist scheitert eine Kette aus Abhängigkeiten: Konfiguration (Generation, Secure Boot, Bootreihenfolge), Firmware/CPU-Virtualisierung (VT-x/AMD-V, SLAT, DEP), Host-Ressourcen (RAM/NUMA, CPU-Zeit, I/O), Geräte- und Treiberstacks (VHDX-Filter, Storage-Controller, vSwitch/NIC) sowie Integrationsdienste im Gast. Die Fehlermeldung markiert oft nur den Punkt, an dem Hyper-V die VM nicht weiter in einen konsistenten Zustand überführen kann.

Konfigurations- und Zustandsfehler beim VM-Start

Viele Startabbrüche werden von der Virtual Machine Management Service (VMMS) und dem Workerprozess (vmwp.exe) ausgelöst, wenn die gespeicherten Metadaten nicht zu Hostfähigkeit, Gerätetopologie oder Sicherheitsrichtlinien passen. Typisch sind Konflikte zwischen VM-Generation und Firmwaremodus (UEFI vs. BIOS), falsche Bootgerätezuordnung, unzulässige Secure-Boot-Templates oder eine inkonsistente VM-Konfiguration nach Storage-Migrationen. In Clustern tritt zusätzlich der Fall auf, dass der VM-Zustand zwar in der Konfiguration als „registriert“ gilt, die zugehörigen Ressourcen (CSV, vNIC-Port, VHDX) aber auf dem startenden Knoten nicht konsistent erreichbar sind.

Die gleiche Zeichenkette „failed to start“ kann verschiedene HRESULT-Codes tragen. Für die technische Zuordnung ist daher der Code entscheidend, nicht nur der Text. Besonders bei 0x80070005 ist die Ursache häufig nicht die VM selbst, sondern NTFS-/SMB-Berechtigungen auf dem Storagepfad, fehlende Rechte auf ein Zertifikat/Key Protector, oder ein blockierender Sicherheitsfiltertreiber im Host.

Firmware, CPU-Virtualisierung und Hypervisor-Initialisierung

Fehler dieser Klasse entstehen, bevor der Gast überhaupt „CPU-Zeit“ erhält. Der Hypervisor benötigt Hardware-Virtualisierung (Intel VT-x oder AMD-V), Second Level Address Translation (SLAT/EPT/NPT) für moderne Betriebsmodi und korrekt aktivierte Ausführungs-/Speicherschutzfunktionen (DEP/NX). Außerdem kollidieren konkurrierende Virtualisierer (z. B. andere Hypervisoren oder bestimmte VBS/Isolationsmodi) mit der exklusiven Kontrolle des Hypervisors über VMX/SVM. In der Praxis ist die Fehlermeldung oft ein Symptom für Firmwarezustände (BIOS/UEFI), Bootloader-Konfiguration oder Treiber, die den Hypervisorstart verhindern.

• Hypervisor nicht aktiv (Hostebene): Virtual machine 'VMNAME' could not be started because the hypervisor is not running. / 0xC0351000; häufig korreliert mit deaktiviertem VT-x/AMD-V oder einem Boot ohne Hypervisor-Layer. Diagnostik typischerweise über systeminfo.exe (Abschnitt „Hyper-V-Anforderungen“) und die Bootkonfiguration bcdedit /enum (Eintrag hypervisorlaunchtype).
• Nested Virtualization/VM-Konfiguration vs. Hostfähigkeit (Hostebene): Startfehler treten auf, wenn eine VM-Einstellung CPU-Features voraussetzt, die der Host nicht bereitstellt (z. B. fehlende SLAT oder gesperrte Virtualisierungs-Erweiterungen). Prüfung über Get-VMProcessor -VMName VMNAME sowie Host-Capabilities via Get-ComputerInfo (relevante Hyper-V/Virtualization-Felder).
• CPU-Feature-Inkonsistenz nach Live Migration (Infrastrukturebene): Laufzeitabbrüche oder Startverweigerung können folgen, wenn CPU-Features zwischen Knoten nicht kompatibel sind. Abhilfe erfolgt über Prozessor-Kompatibilitätsmodus (je nach Szenario) und konsistente Host-Generationen; Prüfung über Get-VMHostSupportedVersion und VM-Konfigurationsversionen mit Get-VM -Name VMNAME | Select Version.

Integrationsdienste, Bootpfad und Gastabhängigkeiten

Integrationsdienste sind kein „Treiberpaket“ im klassischen Sinn, sondern eine Kombination aus VMBus-Komponenten, Zeit-/Shutdown-Schnittstellen, Heartbeat und (abhängig vom Gast) Storage- und Netzwerkpfaden. Bei modernen Windows-Gästen werden die relevanten Komponenten über den normalen Updatekanal gepflegt; bei vielen Linux-Gästen sind sie Teil des Kernels. Laufzeitmeldungen wie „Heartbeat“ oder „KVP“ markieren in der Regel Gastzustände (z. B. Boot hängt, Kernel panic, initramfs-Fehler), werden aber als Hyper-V-Statusereignis sichtbar. Startfehler rund um das Bootdevice sind dagegen meist Konfigurations- oder Storagepfadfehler: falscher Controller (SCSI/IDE), fehlendes UEFI-Bootmedium bei Generation 2, oder ein nicht erreichbarer Datenträgerpfad.

• Gast startet, aber bleibt „ohne Lebenszeichen“ (Gastebene als Ursache, Host zeigt Symptom): Integrationsstatus „Heartbeat“ kann ausbleiben, obwohl die VM „Running“ ist; Auslöser sind häufig Boot- oder Kernelprobleme im Gast. Korrelation über Gastkonsole und Hostdaten Get-VMIntegrationService -VMName VMNAME.
• Herunterfahren/Zeitsynchronisation ohne Wirkung (Gastebene): Wenn „Shutdown“/„Time Synchronization“ als deaktiviert oder „not operational“ erscheint, fehlt oft ein funktionierender VMBus im Gast oder ein passender Kernel-/Treiberstand. Statusprüfung mit Get-VMIntegrationService -VMName VMNAME | Select Name,Enabled,PrimaryStatusDescription,SecondaryStatusDescription.

Ressourcen- und Treiberabhängigkeiten im Laufzeitbetrieb

Laufzeitfehler werden häufig von Ressourcenknappheit, I/O-Stalls oder Treiberketten ausgelöst, die Hyper-V lediglich „sichtbar“ machen. Beim Arbeitsspeicher kollidieren Start-RAM, Dynamic Memory Minimum/Maximum und Host-Commit. Bei CPU sind es weniger „zu wenig Kerne“, sondern Scheduling-Druck, NUMA-Topologie und Hostlast, die Timeouts und Watchdogs begünstigen. Storage- und Netzwerkfehler sind oft durch Filtertreiber (Antivirus, DLP, Backup), Multipath/Offload-Funktionen oder NIC-Teaming-Interaktionen geprägt; Hyper-V reagiert dann mit Geräte-Resets, Pfadverlust oder Portzustandswechseln, die als VM-Fehler erscheinen.

• Arbeitsspeicherzusage scheitert (Hostebene): 0x8007000E beim Start oder beim Wiederaufnehmen gespeicherter Zustände deutet auf fehlende Commit-/RAM-Reserve hin; Gegenprüfung über Get-VM -Name VMNAME | Select MemoryStartup,DynamicMemoryEnabled,MemoryMinimum,MemoryMaximum und Hostspeicherindikatoren in Get-Counter (z. B. Commit/Available).
• Zugriff auf VM-Ressourcen verweigert (Host-/Infrastrukturebene): 0x80070005 tritt häufig bei VHDX auf SMB, bei CSV-Rechten oder bei fehlenden ACLs für die VM-spezifischen Identitäten; technische Prüfung der Zugriffswege über icacls "D:\VMs\VMNAME" bzw. SMB-Freigaben und, in Clustern, über die Besitz-/Redirected-I/O-Situation.
• Workerprozess/Device-Stack instabil (Hostebene): Wenn vmwp.exe neu startet oder Geräte mehrfach „re-attached“ werden, liegt die Ursache häufig in Storage-/Netzwerktreibern oder Filtertreibern. Einordnung über Eventlogs Microsoft-Windows-Hyper-V-Worker/Admin und Korrelation mit Storage/NIC-Events im Systemlog.

Storage-, Checkpoint- und Netzwerkfehler: VHDX/AVHDX, CSV/SMB, Berechtigungen, VMSwitch/VFP, Live Migration und Auswirkungen auf HA/Performance/Datenschutz

Fehlerbilder in Hyper-V wirken in diesem Themenfeld selten isoliert. VHDX/AVHDX, Cluster Shared Volumes (CSV), SMB-Backends, Checkpoints und die virtuelle Switch- und Filterpipeline (VMSwitch/VFP) bilden eine Kette aus Abhängigkeiten. Ein scheinbar „virtueller“ Start- oder Laufzeitfehler lässt sich häufig auf blockierte I/O-Pfade, inkonsistente Differencing-Disks, falsch delegierte Berechtigungen, gestörte Namensauflösung oder Paketfilterregeln zurückführen. Die technischen Symptome zeigen sich dann als Hyper-V-Manager-Meldung, als Ereignis im Kanal Microsoft-Windows-Hyper-V-Worker/Hyper-V-VMMS oder als Fehler in Failover Clustering und SMBClient.

VHDX/AVHDX- und Checkpoint-Probleme: Differencing-Ketten, Sperren und Metadaten

Checkpoint-bezogene Störungen betreffen fast immer die AVHDX-Kette (Differencing Disk), die Merge-Logik sowie die Zugriffssemantik des Storage-Backends. Hyper-V hält während des Betriebs Handles auf VHDX/AVHDX offen; Drittprozesse (Backup-Agenten, AV-Scanner, Indexer) oder Storage-Funktionen (Snapshots, tiering-bedingte Reparse Points) können mit exklusiven Locks, Verzögerungen oder inkonsistenten Metadaten kollidieren. In der Praxis häufen sich dann Stop-/Save-State-Eskalationen, Merge-Staus und verlängerte Wiederanlaufzeiten nach Host-Neustarts.

Typische Fehler treten beim Erstellen, Anwenden oder Zusammenführen von Checkpoints auf, wenn die Kette beschädigt ist, Dateien fehlen oder Berechtigungen nicht konsistent sind. Besonders kritisch sind orphaned AVHDX-Dateien (gelöschte oder verschobene Parent-VHDX) und lange Merge-Phasen, die CSV-Redirected I/O auslösen können. Das erhöht Latenzen, beeinträchtigt Live Migration und verschlechtert die Recovery Point Objectives, weil Backup-Fenster und Replikationsläufe nicht mehr planbar sind.

• VMMS-Fehler bei Dateizugriff: General access denied error (0x80070005) – Host/Storage-Ebene; häufig NTFS/ReFS-ACLs auf VM-Ordnern, fehlende Rechte des Computerkontos (bei Clusterrollen) oder SMB-Freigabe-/NTFS-Mismatch.
• Datei nicht gefunden: The system cannot find the file specified. (0x80070002) – Infrastruktur/Storage; typisch bei verschobenen .vhdx/.avhdx, defekten Mountpoints, nicht gemounteten CSV-Pfaden C:\ClusterStorage\VolumeX oder veralteten Pfadreferenzen in der VM-Konfiguration.
• Ungültiger Parameter beim Datenträger: The parameter is incorrect. (0x80070057) – Storage/Dateisystem; häufig Hinweis auf beschädigte VHDX-Metadaten, fehlerhafte Offload-Mechanismen oder nicht unterstützte Storage-Features auf dem Zielpfad.
• Ressource wird verwendet: The process cannot access the file because it is being used by another process. (0x80070020) – Host/Backup/AV; kollidierende Filtertreiber oder VSS/Backup-Handles können Merge- oder Startvorgänge blockieren.
• Nicht genügend Speicherplatz: There is not enough space on the disk. (0x80070070) – Infrastruktur; wirkt sich auf Checkpoint-Erstellung, Merge und dynamisches VHDX-Wachstum aus; führt im Extremfall zu Gast-IO-Fehlern und potenzieller Dateisystemkorruption im Gast.
• Merge hängt/übermäßig langsam: Status Merging disks in Hyper-V-Manager – Host/Storage; meist Indiz für hohe Latenz im Backend, CSV-Redirected I/O oder konkurrierende I/O (Backup, ReFS-Integritätsprüfungen). Technisch kritisch, weil bis zum Abschluss der Merge-Kette zusätzliche AVHDX-Schichten bestehen bleiben und der I/O-Pfad länger wird.

CSV- und SMB-Backends: Redirected I/O, Witness, Namensauflösung und Kerberos

In Clusterumgebungen verschiebt CSV den I/O-Pfad je nach Zustand zwischen Direct I/O und Redirected I/O über den Coordinator Node. Storage-Störungen oder Netzwerkprobleme führen dann nicht nur zu „langsamerem Storage“, sondern zu veränderten Datenpfaden, anderen Sperrregeln und zusätzlichem Traffic. Bei SMB-basiertem VM-Storage (z. B. Scale-Out File Server) wird die VM-Verfügbarkeit unmittelbar von SMB Multichannel/RDMA, Kerberos/Delegation, kontinuierlicher Verfügbarkeit und stabiler DNS-/SPN-Auflösung abhängig.

In diesem Kontext sind Fehler häufig Mischsignale aus Failover Clustering, SMBClient und Hyper-V. Ein Hyper-V-Fehler beim Starten einer VM kann der Endpunkt einer Kette sein, die mit einem verlorenen SMB-Session-Key, einer fehlgeschlagenen Kerberos-Authentifizierung oder einem kurzzeitigen CSV-Ownership-Wechsel begann. Für Hochverfügbarkeit ist entscheidend, ob die VM-Ressource im Cluster sauber failovern kann oder in einem „Failed“-Zustand verbleibt, weil Storage- oder Netzwerkabhängigkeiten nicht wiederherstellbar sind.

• SMB-Authentifizierung scheitert: The username or password is incorrect. (0x8007052E) – Infrastruktur/Sicherheit; häufig bei fehlender constrained delegation für Live Migration/Storage-Zugriff oder bei SPN/DNS-Inkonsistenzen zwischen Host, CNO und Fileserver.
• Doppel-Hop/Delegationssymptom: A specified logon session does not exist. It may already have been terminated. (0x80070520) – Infrastruktur/Sicherheit; typisch, wenn Kerberos nicht genutzt wird und NTLM nicht delegieren kann, oder wenn Tickets durch Zeitabweichung/Domain-Probleme ungültig werden.
• Netzwerkpfad nicht erreichbar: The network path was not found. (0x80070035) – Netzwerk/DNS/Routing; wirkt sich auf \\SOFS\Share-basierte VM-Speicherpfade aus und führt zu VM-Offline oder fehlgeschlagenen Start-/Failover-Vorgängen.
• CSV in umgeleitetem Modus (Symptom): Status Redirected Access in Cluster-Ansichten – Infrastruktur/Storage/Netzwerk; Indikator für Pfadprobleme zum Storage, Node-Isolation oder SMB/RDMA-Störungen; typische Folge sind erhöhte Latenz und schwankende VM-Performance.

Virtuelles Netzwerk: VMSwitch, VFP, Offloads und Host-Firewall als Fehlerverstärker

Das virtuelle Netzwerk ist in Hyper-V nicht nur ein „Switch“, sondern eine Pipeline aus Switch-Erweiterungen, Richtlinien, VFP-Flowtabellen (insbesondere bei SDN/Network Controller), Offload-Funktionen der NIC (VMQ, VMMQ, SR-IOV, RSS) und der Windows Filtering Platform. Fehler werden deshalb oft als VM-Konnektivitätsproblem wahrgenommen, obwohl die Ursache im Treiber, in inkonsistenten VFP-Regeln oder in einer falschen NIC-Teaming-/Switch-Embedded-Teaming-Konfiguration liegt. Besonders Live Migration und Storage over SMB reagieren empfindlich, weil sie durch kurzzeitige Paketverluste oder MTU-Inkonsistenzen sofort neu verhandeln oder abbrechen.

Mehrdeutig sind Fälle, in denen die Gast-VM „läuft“, aber Dienste ausfallen: DNS und Kerberos sind dann meist erste Opfer, weil Zeitouts und Retransmits nicht als klarer Link-Down sichtbar werden. Das schlägt direkt auf Cluster-Heartbeats, CSV-Konnektivität und damit auf Hochverfügbarkeit durch. Zusätzlich entsteht ein Datenschutzrisiko, wenn Live Migration nicht verschlüsselt ist oder fehlerhaft auf ungewollte Netzpfade ausweicht; umgekehrt führen erzwungene Verschlüsselung oder falsche Zertifikate zu Migrationsabbrüchen.

• VMSwitch-Erstellung/Bindung scheitert: General access denied error (0x80070005) – Host/Sicherheit; häufig durch fehlende Rechte (lokale Gruppen), Härtungsrichtlinien oder blockierte Treiber-/Filterbindungsoperationen.
• NIC/Offload-Inkompatibilität als Symptom: Ereignisse im Kanal Microsoft-Windows-Hyper-V-VmSwitch oder NDIS mit Paketdrop-/Reset-Hinweisen – Host/Netzwerk; typische Auswirkung sind sporadische Verbindungsabbrüche, besonders unter Last (Backup, Live Migration, SMB Multichannel).
• MTU-/Jumbo-Frame-Mismatch: Live-Migration-/SMB-Fehler mit The semaphore timeout period has expired. (0x80070079) – Netzwerk/Infrastruktur; verursacht durch fragmentierungsfreie Pfade, die nicht durchgängig jumbo-fähig sind, oder durch fehlerhafte NIC-Firmware/Offloads.

Live Migration: Authentifizierung, Speicherzugriff und Abbruchkaskaden

Live Migration kombiniert Netzwerktransport, Authentifizierung (Kerberos oder Zertifikat), Speicherzugriff (Shared Nothing oder Shared Storage) und einen koordinierten Zustandstransfer von Arbeitsspeicher und Geräte-Emulation. Ein Abbruch ist daher selten „nur Netzwerk“. Häufig entstehen Kaskaden: Erst steigt Latenz (SMB/CSV), dann verlängert sich die Pre-Copy-Phase, schließlich überschreiten Timeouts den Grenzwert, und am Ende bricht die Migration ab oder hinterlässt temporäre Artefakte (z. B. teilverschobene Konfigurationsfragmente bei Shared-Nothing-Workflows).

• Authentifizierung/Delegation: The credentials supplied are not sufficient to access this virtual machine. (0x8009030E) – Infrastruktur/Sicherheit; typisch bei Kerberos-Fehlkonfiguration (SPN, constrained delegation) oder bei nicht passender Migrationseinstellung (Kerberos vs. CredSSP in gemischten Betriebsmodellen).
• Netzwerk-/Timeout-Abbruch: The semaphore timeout period has expired. (0x80070079) – Netzwerk/Transport; oft ausgelöst durch Paketverluste, MTU-Probleme, überbuchte Migration-Netze oder RDMA-Fehlfunktionen bei SMB-basierten Pfaden.
• Speicherzugriff auf Ziel scheitert: Insufficient system resources exist to complete the requested service. (0x800705AA) – Host/Storage; kann bei Ressourcenknappheit (Nonpaged Pool, Filtertreiber), zu hohen Handle-Counts oder Storage-Subsystem-Überlast auftreten und verhindert das Anlegen/Öffnen von VHDX am Ziel.

Für HA und Datenschutz ist der Modus entscheidend: Live Migration über SMB oder dedizierte Migration-Netze kann verschlüsselt werden; ein erzwungener Wechsel der Authentifizierung oder ein Zertifikatsproblem führt jedoch zu unmittelbaren Abbrüchen und damit zu gescheiterten Wartungs- oder Failover-Prozeduren. Storage-Engpässe wirken dabei als Multiplikator: Sie erhöhen die Migrationsdauer, verlängern Lock-Zeiten auf VHDX/AVHDX und verschärfen die Auswirkungen kleiner Netzstörungen, weil das Zeitbudget schrumpft.