2026: Was tun, wenn Windows Server 2025 auf einer AMD-EPYC-VM nicht startet?

Geeignet, wenn Sie erst sichern und dann die Ursache eingrenzen

Am 21.05.2026 wurde Proxmox VE 9.2 mit einem aktualisierten Standardkernel und erneuerten Plattformkomponenten veröffentlicht, darunter QEMU; die Einzelheiten stehen in der offiziellen Veröffentlichung zu Proxmox VE 9.2. Daraus folgt nicht, dass ein Startfehler von Windows Server 2025 auf einer AMD-EPYC-VM automatisch durch das Update verursacht wurde. Sichern Sie zuerst einen wiederherstellbaren Zustand und prüfen Sie Firmware, Startreihenfolge, virtuellen Controller, CPU-Modell und jüngste Änderungen jeweils einzeln. Bei Produktionssystemen testen Sie in einer geklonten VM oder innerhalb eines freigegebenen Wartungsfensters, statt die einzige Instanz durch gleichzeitige Änderungen an mehreren Einstellungen weiter zu destabilisieren.

Geeignet: Sie betreiben Windows Server 2025 unter Proxmox und sehen einen Startkreislauf, eine Wiederherstellungsanzeige oder einen Abbruch vor der Anmeldung.
Nicht geeignet: Sie suchen eine pauschale, ungetestete Empfehlung, den Hostkernel, den Festplattencontroller oder den CPU-Typ sofort zu wechseln.

Der Leitfaden richtet sich an Proxmox-Administratoren und MSP-Teams, die eine Störung nach einem Plattform- oder Windows-Update prüfen. Ebenso hilft er IT-Verantwortlichen, vor einem geplanten Upgrade oder einer Bereitstellung auf einem eigenständigen AMD-Server eine belastbare Test- und Rückfallroutine festzulegen.

Zuletzt geprüft am 27.10.2026. Die Versionsangaben wurden mit der Proxmox-Veröffentlichung zu VE 9.2 und dem aktuellen Proxmox-Administrationshandbuch abgeglichen; die Systemanforderungen mit Microsofts Dokumentation zu den Hardwareanforderungen von Windows Server. Berichte aus Foren werden im Folgenden ausdrücklich als Einzelfälle behandelt.

Vor einem Upgrade: Rückfallpunkt und Ausgangszustand dokumentieren

Eine Wiederherstellung ist nur dann planbar, wenn Sie den bisherigen Zustand kennen und die Sicherung tatsächlich zurückspielen können. Notieren Sie vor Änderungen mindestens die installierte Windows-Server-Version, den VM-Namen beziehungsweise die VM-ID, die Proxmox-Version, den Hostkernel, das CPU-Modell der VM, die Firmware, die Boot-Reihenfolge und den virtuellen Festplattencontroller. Halten Sie außerdem fest, wann zuletzt Windows, Proxmox oder ein Treiber geändert wurde. So können Sie nach einem Fehler prüfen, welche Änderung zeitlich damit zusammenfällt, ohne daraus vorschnell eine Ursache abzuleiten.

Führen Sie die Sicherung nicht nur als administrativen Haken aus. Prüfen Sie, ob sie als wiederherstellbarer Stand verfügbar ist und ob das zuständige Team weiß, wie die VM auf einen sicheren Zustand zurückgesetzt werden kann. Wenn Sie die Wiederherstellung nicht testen können, führen Sie keine riskante Änderung an der Produktions-VM aus, solange kein akzeptierter Rückfallweg besteht. Eine Sicherung, deren Inhalt oder Wiederherstellung unklar ist, genügt nicht als belastbarer Rückfallpunkt.

Erfassen Sie die VM-Konfiguration und die Hostumgebung, bevor Sie Änderungen vornehmen. Auf dem Proxmox-Host geben beispielsweise diese Befehle einen Ausgangspunkt:

qm config <VMID>
pveversion -v
uname -r
qm status <VMID>

Ersetzen Sie <VMID> durch die Kennung der betroffenen VM. Bewahren Sie die Ausgabe außerhalb der VM auf und ergänzen Sie sie um die aktuelle Startreihenfolge sowie die im Gast verwendete Firmware. Änderungen an VM-Konfiguration und Host sollten Sie im Proxmox-Administrationshandbuch gegen die tatsächlich installierte Version prüfen; eine Befehlsausgabe allein sagt nicht, ob Windows mit der aktuellen Kombination starten kann.

Für ein Upgrade auf Proxmox VE 9.2 gilt: Testen Sie den geplanten Zustand zunächst mit einer Kopie der betroffenen VM, wenn Ihre Infrastruktur das zulässt. Ist das nicht möglich, vereinbaren Sie ein Wartungsfenster mit benanntem Verantwortlichen, dokumentiertem Rückfallpunkt und klarer Abbruchbedingung. Ein Startfehler nach mehreren gleichzeitig vorgenommenen Änderungen lässt sich deutlich schwerer zuordnen als ein Fehler nach einer einzeln protokollierten Änderung.

Direkt nach dem Fehler: Hostproblem und Gastproblem auseinanderhalten

„Die VM startet nicht“ beschreibt mehrere unterschiedliche Fehlerlagen. Die Proxmox-Verwaltung kann erreichbar sein, während nur Windows nicht startet. Die VM kann bereits beim Start durch den Hypervisor scheitern. Oder Windows kann die Wiederherstellungsumgebung erreichen und dort eine interne Fehlermeldung anzeigen. Diese Fälle verlangen unterschiedliche Prüfungen: Ein nicht erreichbarer Host ist zunächst ein Verwaltungs- oder Hostproblem; ein gestarteter VM-Prozess mit Windows-Fehler verweist dagegen auf die Gaststartkette, ohne damit bereits deren Ursache festzulegen.

Notieren Sie, was tatsächlich sichtbar ist: den Fehlercode, den letzten angezeigten Startschritt, eine etwaige automatische Reparatur, den Zeitpunkt des Fehlers sowie die letzte Änderung an Host, VM oder Gast. Prüfen Sie, ob der Host noch über SSH administrierbar ist und ob andere VMs normal laufen. Ändern Sie während dieser Bestandsaufnahme keine weiteren Einstellungen. Andernfalls verlieren Sie den Vergleich zwischen dem dokumentierten Ausgangszustand und dem fehlerhaften Zustand.

Auch ein zeitlicher Zusammenhang beweist keine Kausalität. Im Proxmox-Forum wurde ein Startproblem nach einem Update diskutiert; eine Diskussion in der Proxmox-Community auf Reddit enthält ebenfalls Hinweise zu Windows Server 2025 und VM-Konfigurationen. Das sind Berichte einzelner Nutzer, keine offizielle Bestätigung eines allgemeinen Fehlers und kein Nachweis dafür, dass AMD EPYC die gemeinsame Ursache ist. Vergleichen Sie daher Ihren eigenen Zustand mit den konkreten Angaben im jeweiligen Bericht, statt dessen vorgeschlagene Rückfallmaßnahme ungeprüft zu übernehmen.

Startkette prüfen: Firmware, Boot-Eintrag und Controller

Windows kann nicht von einem Laufwerk starten, das die VM nicht mehr in derselben Form sieht, in der es eingerichtet wurde. Prüfen Sie deshalb zuerst, ob die virtuelle Festplatte in der VM-Konfiguration vorhanden ist, welche Firmware die VM verwendet und ob die Boot-Reihenfolge weiterhin auf das richtige Gerät verweist. Bewerten Sie dabei die tatsächliche Konfiguration: Ein Wechsel zwischen SeaBIOS und UEFI ist keine allgemeine Reparaturmaßnahme, sondern kann die erwartete Startumgebung verändern.

Kontrollieren Sie anschließend den virtuellen Festplattencontroller. Maßgeblich ist, welcher Controller bei der Windows-Installation verwendet wurde und ob der Gast die dafür benötigte Unterstützung besitzt. Wechseln Sie den Controller nicht probeweise auf der einzigen Produktionsinstanz. Erkennt die Wiederherstellungsumgebung ein Laufwerk, ist das ein nützlicher Diagnosehinweis; es beweist jedoch weder, dass der normale Startpfad korrekt eingerichtet ist, noch dass Treiber und darunterliegende Speicherung fehlerfrei arbeiten.

Erreichen Sie die Windows-Wiederherstellungsumgebung, sichern Sie zuerst die angezeigte Meldung und prüfen Sie, welche Laufwerke dort sichtbar sind. Microsoft beschreibt in der Anleitung zum Einsatz von WinRE bei Startproblemen diagnostische Schritte für Windows-Startfehler. Verwenden Sie diese Informationen als Gastdiagnose, nicht als Beleg, dass der virtuelle Controller oder der Host bereits ausgeschlossen wurde. Auch die Dokumentation zu den WinRE-Wiederherstellungsfunktionen hilft bei der Einordnung der verfügbaren Reparaturmöglichkeiten.

Wenn Sie ein Gerät oder einen Firmwareparameter ändern, notieren Sie den alten Wert und ändern Sie nur diese eine Variable. Starten Sie anschließend die Testkopie und protokollieren Sie, ob sich der Fehlerort, die Meldung oder das Verhalten verändert. Bleibt der Zustand gleich, stellen Sie den vorherigen Wert wieder her, bevor Sie die nächste Hypothese prüfen. Damit vermeiden Sie, dass mehrere Änderungen einen neuen, schwerer diagnostizierbaren Fehler erzeugen.

Windows Server 2025 nach einem Proxmox-Upgrade: erst vergleichen, dann zurückrollen

Bei einem Startfehler nach einem Proxmox-Upgrade vergleichen Sie den dokumentierten Zustand vor und nach dem Upgrade. Prüfen Sie zuerst, ob sich neben der Hostversion auch VM-Einstellungen, Gastupdates, virtuelle Geräte oder Treiber geändert haben. Die veröffentlichten Informationen zu Proxmox VE 9.2 nennen einen aktualisierten Standardkernel und Änderungen an Plattformkomponenten; daraus lässt sich jedoch keine bestimmte Ursache für einen individuellen Windows-Fehler ableiten. Verwenden Sie die offizielle VE-9.2-Veröffentlichung für den Versionskontext und das Administrationshandbuch für die jeweils passende Konfiguration.

Unter Windows können Sie in WinRE die angezeigten Diagnoseinformationen sichern und prüfen, ob das Systemlaufwerk erkannt wird. Halten Sie außerdem den exakten Fehlertext und den Punkt fest, an dem der Start abbricht. Ein sichtbares Laufwerk bedeutet nicht automatisch, dass der Boot-Eintrag gültig ist; umgekehrt beweist ein fehlender Start nicht, dass der Datenträger beschädigt ist. Trennen Sie daher Geräteerkennung, Firmwarekonfiguration und Windows-Reparatur als eigene Prüfschritte.

Bei einem AMD-EPYC-System sollten Sie den in der VM eingestellten CPU-Typ ebenfalls dokumentieren. Ein Wechsel des CPU-Modells kann die für den Gast sichtbaren Eigenschaften ändern, aber ohne reproduzierbaren Vergleich ist er keine verlässliche Reparatur. Ändern Sie den Typ nur dann testweise, wenn Sie eine Kopie, einen dokumentierten Rückweg und eine klar definierte Prüfung haben. Dass ein Nutzer in einem Forum nach einem Kernel- oder CPU-Wechsel einen Erfolg meldet, ist kein Beleg dafür, dass derselbe Schritt in Ihrer Umgebung sicher ist.

Entscheidung nach Befund: gezielt ändern oder auf den letzten Stand zurückgehen

Nutzen Sie die folgende Abzweigung, bevor Sie die Produktions-VM verändern:

• Wenn ein wiederherstellbarer Sicherungsstand vorliegt und der Fehler auf einer VM-Kopie reproduzierbar ist, dann testen Sie eine einzelne, begründete Änderung an der Kopie und vergleichen Sie den Start mit dem Ausgangszustand.
• Wenn eine einzelne dokumentierte Änderung unmittelbar vor dem Fehler erfolgte und deren Rücknahme in der Kopie den Fehler reproduzierbar beseitigt, dann planen Sie den Rückweg für die Produktions-VM innerhalb eines freigegebenen Wartungsfensters.
• Wenn mehrere Komponenten gleichzeitig geändert wurden oder keine Wiederherstellung geprüft ist, dann ändern Sie weder CPU-Typ noch Controller noch Kernel auf der einzigen Instanz; schaffen Sie zunächst einen belastbaren Rückfallpunkt.
• Wenn Windows WinRE erreicht, das Laufwerk aber nicht sichtbar ist, dann prüfen Sie Controller und Gasttreiber, ohne aus der Anzeige allein einen Defekt des physischen Datenträgers abzuleiten.
• Wenn nur die Proxmox-Verwaltung ausfällt oder der Host nicht mehr erreichbar ist, dann behandeln Sie den Fall als Host- beziehungsweise Verwaltungsstörung und trennen ihn von der Windows-Reparatur.

Ein Rückrollen des Hostkernels ist kein allgemeiner Reparaturweg. Dass eine ältere Version in einem einzelnen Community-Bericht geholfen hat, bestätigt weder die Eignung für Ihre Installation noch die Kompatibilität mit anderen Änderungen. Prüfen Sie den Rückweg mit den offiziellen Proxmox-Unterlagen, sichern Sie die VM und legen Sie vorab fest, wer die Änderung ausführt und wann der Versuch abgebrochen wird. Wenn die Testkopie den Fehler nicht reproduziert, behalten Sie die Produktionsumgebung unverändert, bis Sie eine besser belegte Hypothese haben.

Nach der Wiederherstellung: Start, Dienste und Betrieb dokumentieren

Ein einmaliger erfolgreicher Start ist noch keine Abnahme. Prüfen Sie nach einer Reparatur, ob Windows den erwarteten Startpfad durchläuft, die erforderlichen virtuellen Geräte erkennt und die geschäftskritischen Dienste verfügbar sind. Führen Sie einen kontrollierten Neustart durch und vergleichen Sie das Ergebnis mit dem vorherigen Fehlerbild. Notieren Sie die geänderten Einstellungen und die Versionen, mit denen der erfolgreiche Test durchgeführt wurde. Ohne diese Aufzeichnung können spätere Neustarts oder Änderungen an Treibern nicht zuverlässig mit dem Ergebnis verglichen werden.

Verwenden Sie WinRE nur für eine gezielte Diagnose oder Wiederherstellung, deren Wirkung Sie verstehen. Microsofts Anleitung zur Fehlerbehebung beim Windows-Server-Start gibt den Rahmen für Gastmaßnahmen vor; sie ersetzt keine Sicherung und keine Prüfung der VM-Konfiguration. Vor Reparaturaktionen, die Bootdaten oder Systemdateien verändern können, müssen Sie wissen, wie Sie auf den vorherigen Stand zurückkehren. Bei einer produktiven VM gehören Wartungsfenster, verantwortliche Person und Abbruchkriterium zur technischen Vorbereitung, nicht erst zur nachträglichen Dokumentation.

Vor dem nächsten Plattformupgrade wiederholen Sie den Test mit einer VM-Kopie, sofern verfügbar. Prüfen Sie, ob die Kopie mit derselben Firmware, demselben Controller und demselben CPU-Typ startet, die auch für die Produktion vorgesehen sind. Weicht der Testaufbau von der Produktions-VM ab, dokumentieren Sie die Abweichung; andernfalls könnten Sie ein Ergebnis auf eine Konfiguration übertragen, die gar nicht geprüft wurde. Halten Sie zudem fest, welche Änderung im Test den Fehler ausgelöst oder behoben hat und ob sich das Verhalten reproduzieren ließ.

Hostplanung: VM-Abnahme ist keine Kapazitätszusage

Die erfolgreiche Inbetriebnahme einer Windows-VM sagt nicht aus, wie viele weitere VMs ein Host zuverlässig tragen kann. Planen Sie CPU- und Arbeitsspeicherzuweisung anhand des tatsächlichen Arbeitsprofils, der Lastspitzen, der Windows-Server-Lizenzierung und der Verantwortlichkeit für Sicherung und Wiederherstellung. Microsofts Hardwareanforderungen für Windows Server sind eine technische Grundlage für die Gastbetriebssysteme; sie ersetzen keine Kapazitätsmessung Ihrer Anwendungen und keine Prüfung der jeweils geltenden Lizenzbedingungen.

Wenn Sie einen eigenständigen AMD-Server als Virtualisierungshost erwägen, vergleichen Sie ihn mit Ihrer aktuellen Plattform anhand von vier konkreten Punkten: Wie stabil bleibt die Leistung unter gleichzeitiger VM-Last? Können Sie Firmware, virtuelle Geräte und Gastbetriebssysteme passend zu Ihrer Betriebsweise konfigurieren? Sind die Kosten der dauerhaft benötigten Ressourcen und der Windows-Lizenzen transparent? Haben Sie einen eigenen, getesteten Sicherungs- und Wiederherstellungsweg? Ein gemeinsam genutzter Cloud-Host kann für kurzlebige Testsysteme oder geringe, variable Last sinnvoll sein. Bei dauerhaftem Betrieb können geteilte Ressourcen, nicht vollständig kontrollierbare Hostkonfigurationen und schwer vergleichbare Gesamtkosten dagegen die Fehlersuche und Kapazitätsplanung erschweren.

Wenn Sie den Arbeitsspeicherbedarf mehrerer Gäste dimensionieren, beziehen Sie auch Betriebssystem, Anwendungen und Reserve für den Host ein; eine VM, die beim Test startet, kann unter realer Last trotzdem zu knapp geplant sein. Für eine ergänzende Einordnung zur Planung von Arbeitsspeicher und Datenträgern finden Sie eine passende Übersicht. Prüfen Sie außerdem vor einer Bereitstellung die Lizenzfragen für die geplante Windows-Server-Umgebung, etwa anhand der Hinweise zur Windows-Server-2025-Lizenzprüfung. Diese Punkte sollten vor dem Rollout geklärt sein, nicht erst, wenn zusätzliche Gäste bereits produktive Aufgaben übernehmen.

Wenn Sie Ihre nächste VM-Plattform auswählen, vergleichen Sie deshalb nicht nur den ersten erfolgreichen Start, sondern auch die Kontrolle über Hostressourcen, die Wiederholbarkeit von Änderungen und den Aufwand für Rücksicherung. Für langfristig laufende Windows-Workloads mit Bedarf an eigenständiger Rechenleistung kann ein gemieteter AMD-Bare-Metal-Server geeigneter sein als ein geteilter VPS oder eine öffentliche Cloud-Instanz, bei denen Sie Hostressourcen und Plattformdetails nicht in gleicher Weise selbst festlegen. Wenn Sie dagegen nur kurzzeitig eine Test-VM benötigen oder Ihre Last sehr gering und stark wechselnd ist, kann eine geteilte Umgebung wirtschaftlicher bleiben. Prüfen Sie für einen konkreten Vergleich die aktuell veröffentlichten Optionen von OSFP Cloud und wählen Sie erst, wenn Ressourcen, Lizenzierung und Ihr eigener Wiederherstellungsplan zusammenpassen.