Windows Update kann eine Proxmox-VM auf AMD EPYC lahmlegen

Ein Proxmox-Forums-Update vom August 2026 berichtet, dass eine Windows-Server-2019-VM nach einem Windows Update auf einem AMD-EPYC-Host mit dem benutzerdefinierten QEMU-Argument -cpu host,-hypervisor erneut nicht mehr bootete. Das ist ein konkretes, aus der Community gemeldetes Kompatibilitätsproblem – kein Beleg dafür, dass das August-Update jede Windows-VM auf Proxmox lahmlegt.

Microsoft veröffentlichte am 11. August 2026 das Windows-Server-2019-Update KB5120238 und hob das Betriebssystem auf Build 17763.9121. Microsofts Release-Notiz listet derzeit kein bekanntes Problem, das zum Proxmox-Bericht passt, weshalb eine sorgfältige Reproduktion wichtiger ist als pauschale Aussagen über Microsoft oder Proxmox.

Der Forumsverlauf ist aufschlussreich, weil derselbe Betreiber seit Januar 2026 ähnliche Bootfehler auf einem AMD-EPYC-7302P-System verfolgt hatte. Frühere CPU-Modell-Workarounds stellten das Booten nach vorherigen Updates wieder her. Am 16. August berichtete der Melder, dass diese früheren Workarounds für einen Windows-Server-2019-Gast nicht mehr funktionierten.

Ist das ein bestätigter Microsoft- oder Proxmox-Bug?

Aus den verfügbaren Belegen lässt sich öffentlich kein bestätigter Herstellerdefekt ableiten. Der stärkste Beleg ist ein lang laufender Proxmox-Forumsfall mit detaillierten Host- und Gast-Informationen, ergänzt um einen weiteren Teilnehmer, der eine andere AMD-EPYC-Generation testete und andere Ergebnisse meldete.

Diese Unterscheidung zählt. Microsoft sagt, KB5120238 habe derzeit keine bekannten Probleme. Proxmox hat keine Mitteilung veröffentlicht, wonach das August-Windows-Server-Update AMD-EPYC-Gäste breit lahmlegt. Ein einzelner reproduzierbarer Fall kann trotzdem real und wichtig sein, sollte aber als Kompatibilitätsbericht bezeichnet werden, bis die Grundursache isoliert ist.

Das ist normale Disziplin beim Infrastruktur-Troubleshooting. Beginnen Sie mit der kleinstmöglichen Aussage, die die Belege stützen. Eine Konfiguration hörte nach einem Update auf zu booten. Die Konfiguration enthält ein nicht standardmäßiges CPU-Argument. Ähnliche Fehler traten nach früheren Windows-Updates auf. Unterschiedliche CPU-Modelle veränderten das Ergebnis in früheren Tests.

Das reicht, um einen Testplan zu rechtfertigen. Es reicht nicht, jedem AMD-EPYC-Proxmox-Admin zu raten, Sicherheitsupdates zu deinstallieren.

Welches genaue Proxmox-Setup bootete nicht mehr?

Der ursprüngliche Januar-Bericht stammte von Proxmox VE 8.4 auf einem HPE DL325 Gen10 mit einem AMD EPYC 7302P, einem Zen-2-Rome-Prozessor. Zur gelisteten Software gehörten Kernel 6.8.12-18-pve, pve-manager 8.4.16, pve-qemu-kvm 9.2.0-7 und qemu-server 8.4.5.

Der Betreiber berichtete, dass Windows 10 ESU sowie Windows Server 2019, 2022 und 2025 als Gäste mit dem benutzerdefinierten Argument -cpu host,-hypervisor vor einem Windows-Update funktionierten, danach aber vor der normalen Boot-Animation hängen blieben. Dasselbe Verhalten ließ sich auf einem Intel-E-2346-System nicht reproduzieren, was die CPU-Darstellung sofort zu einem zentralen Teil der Untersuchung machte.

Beim Testen im Februar stellte der Melder fest, dass die Darstellung eines allgemeineren EPYC-Modells in manchen Fällen das Booten wiederherstellen konnte. Ein weiterer Teilnehmer mit PVE 9.1.5 und einer neueren AMD EPYC 9135 berichtete, dass Windows Server 2025 mit einer anderen Proxmox-CPU-Konfiguration bootete.

Dann kam das August-Update. Der ursprüngliche Melder berichtete, dass eine Windows-Server-2019-VM mit -cpu host,-hypervisor erneut kaputtging und die älteren modellbasierten Workarounds das Problem nicht mehr behoben. Das ist der aktuelle Stand des öffentlichen Threads mit Datum vom 17. August.

Warum spielt das CPU-Flag -hypervisor eine Rolle?

Das benutzerdefinierte Argument ändert, welche CPU-Features QEMU dem Windows-Gast präsentiert. Proxmox erlaubt die Anpassung von CPU-Modellen und -Flags, weil Virtualisierungsfeatures, Migrationskompatibilität, verschachtelte Virtualisierung, Gast-Erkennung und Performance alle von der virtuellen CPU-Schnittstelle abhängen können.

Ein vorangestelltes Minuszeichen deaktiviert in der QEMU-Syntax ein CPU-Flag. In dieser Konfiguration verbirgt -hypervisor das hypervisorbezogene CPU-Flag vor dem Gast. Admins nutzen ähnliche Einstellungen historisch für spezielles Gastverhalten, Experimente mit verschachtelter Virtualisierung, Software-Kompatibilität oder Versuche, die Virtualisierung vor Anwendungen zu verbergen.

Das Problem ist, dass eine benutzerdefinierte CPU-Darstellung eine weitere Kompatibilitätsschicht schafft. Windows trifft Entscheidungen basierend auf Prozessorfamilie, Feature-Bits, Virtualisierungsfähigkeiten, Firmware und aktivierten Sicherheitsfunktionen, die es sieht. Ein monatliches Update kann Code ändern, der von diesen Signalen abhängt, selbst wenn sich der Hypervisor selbst nicht geändert hat.

Das macht benutzerdefinierte Flags nicht per se falsch. Es bedeutet, dass sie als Teil des Anwendungskompatibilitätsvertrags behandelt werden sollten. Hängt eine VM von -hypervisor ab, dokumentieren Sie warum. Weiß niemand mehr, wozu das Flag noch dient, ist das eine Konfigurationsschuld, die sich in einem kontrollierten Test entfernen lässt.

Warum halfen frühere CPU-Modell-Workarounds?

Früher im Forumsthread veränderte der Wechsel des virtuellen CPU-Modells das Bootergebnis. EPYC-Rome-v4 mit versteckten Hypervisor-Flag bootete in einem Test nicht, während eine allgemeinere EPYC-Darstellung es tat. Ein weiteres Experiment erzwang ein älteres EPYC-Modell und stellte das Booten ebenfalls eine Zeit lang wieder her.

Dieses Muster deutet darauf hin, dass der Gast auf die Kombination aus offengelegter Prozessoridentität und Virtualisierungs-Flags reagiert, nicht auf einen simplen Mangel an CPU-Leistung. Es sagt uns nicht, welcher Windows-Codepfad sich geändert hat oder ob das Verhalten beabsichtigt ist.

Hier wird pauschale Tuning-Empfehlung gefährlich. Einen CPU-String aus einem Forum zu kopieren, kann einen Gast zum Booten bringen und gleichzeitig still CPU-Fähigkeiten entfernen, das Migrationsverhalten ändern, verschachtelte Virtualisierung beeinträchtigen oder Monate später ein anderes Problem schaffen.

Mr.PlanBs Performance-Leitfaden zu Windows Server 2025 nutzt den sichereren Ansatz: kontrollierte Konfigurationen vergleichen, die Baseline dokumentieren und jeweils eine Variable ändern. Boot-Kompatibilität verdient dieselbe Disziplin.

Sollten Sie KB5120238 deinstallieren, wenn eine Proxmox-VM nicht mehr bootet?

Nicht als ersten Schritt. KB5120238 ist ein Sicherheitsupdate, und Microsoft empfiehlt die Installation aktueller Sicherheitsupdates. Es ohne Verständnis des Fehlers zu entfernen, kann ein Bootproblem gegen eine Sicherheitslücke eintauschen und das gleiche Problem nur bis zum nächsten kumulativen Update verschieben.

Bestätigen Sie zuerst den Zusammenhang. Klonen oder stellen Sie die VM nach Möglichkeit in einer isolierten Testumgebung wieder her. Dokumentieren Sie die exakte VM-Konfiguration, insbesondere CPU-Modell, benutzerdefinierte args, Maschinentyp, BIOS-Typ, TPM-Konfiguration, Anforderungen an verschachtelte Virtualisierung und den Windows-Build. Testen Sie dann denselben Gast mit der minimalen unterstützten CPU-Konfiguration, die den tatsächlichen Anforderungen des Workloads genügt.

Bootet die VM nur nach Entfernen eines benutzerdefinierten Flags, gibt Ihnen das eine deutlich bessere Spur, als Windows blind zurückzurollen. Schlägt die VM auch mit einer standardmäßig unterstützten Konfiguration fehl, wird der Fall für eine Eskalation an Microsoft und Proxmox mit reproduzierbaren Logs deutlich stärker.

Die Fallstudie zum Proxmox-9.1-Upgrade ist aus demselben Grund relevant. Infrastrukturausfälle lassen sich leichter diagnostizieren, wenn das Team einen bekanntermaßen funktionierenden Zustand bewahrt und eine Änderung gegen die andere vergleichen kann.

Wie sollten Produktionsteams Windows-Updates auf Proxmox testen?

Nutzen Sie vor einem breiten Rollout eine Kanarien-VM, die dem produktiven CPU-Modell und den ungewöhnlichen Flags entspricht. Eine generische Windows-Test-VM reicht nicht, wenn die Produktion von GPU-Passthrough, verschachteltem Hyper-V, VBS, benutzerdefinierten CPUID-Einstellungen, älterer Firmware oder einer bestimmten AMD-EPYC-Generation abhängt.

Die Kanarien-VM sollte nach dem Patchen booten, neu starten, herunterfahren und den echten Workload des Dienstes ausführen. Nutzt die Umgebung Windows Failover Clustering, verschachtelte Virtualisierung, SQL Server, Remote Desktop Services oder Sicherheitsfunktionen wie Credential Guard, testen Sie auch diese Funktionen.

Halten Sie den Rollback-Pfad unabhängig von der zu aktualisierenden VM. Snapshots können für einen kurzen Test nützlich sein, aber ein richtiges Backup ist für einen produktiven Rollback sicherer, weil Snapshots denselben zugrunde liegenden Storage und dieselbe Failure Domain teilen. Kann die VM nicht booten, brauchen Sie eine Wiederherstellungsmethode, die nicht davon abhängt, dass Windows erfolgreich startet.

Am wichtigsten: Exportieren Sie die VM-Konfiguration zusammen mit dem Backup-Prozess. Ein Disk-Image ohne die CPU-Flags, Firmware-Einstellungen, virtuelle Hardware und Boot-Reihenfolge reproduziert womöglich nicht den funktionierenden Zustand, den Sie wiederherstellen wollen.

Was würde ich heute mit diesem AMD-EPYC-Fall tun?

Ich würde die August-Windows-Sicherheitsupdates nicht wegen eines einzelnen Forumsberichts über einen gesamten Proxmox-Bestand blockieren. Ich würde alle Windows-Gäste mit benutzerdefinierten CPU-Argumenten wie -hypervisor identifizieren, besonders auf AMD-EPYC-Hosts, und diese Systeme in einen strengeren Pre-Production-Testring verschieben.

Für eine betroffene VM würde ich die funktionierende Konfiguration und ein wiederherstellbares Backup bewahren, dann eine Kopie mit den Standard-Proxmox-CPU-Einstellungen testen, bevor ich das Sicherheitsupdate entferne. Bootet die Standardkonfiguration, würde ich entscheiden, ob das benutzerdefinierte Flag noch wirklich benötigt wird. Falls nicht, würde ich Logs sammeln und Hersteller-Cases mit einer minimalen reproduzierbaren Konfiguration eröffnen.

Die wichtige Lektion ist nicht, dass Windows Update unsicher ist oder AMD EPYC eine schlechte Proxmox-Plattform wäre. Sie ist, dass benutzerdefiniertes virtuelles CPU-Verhalten Teil Ihrer Abhängigkeitskette wird. Monatliche Betriebssystem-Updates können diese Abhängigkeit Jahre nachdem jemand eine Zeile zu einer VM-Konfiguration hinzugefügt hat, offenlegen. Die Teams, die das gut meistern, sind jene, die wissen, welche VMs Besonderheiten haben, bevor der Patch Tuesday es ihnen beweist.