[English]In den letzten Monaten klagten einige Administratoren über Boot-Probleme von virtuellen Maschinen mit Windows in Verbindung mit den monatlichen Sicherheits-Updates. In vielen Fällen ließ sich dies auf VMware-Produkte wie ESXi zurückführen – oder das Ausschalten des Secure Boote half dabei, dass die VMs wieder starteten. Es gibt aber einen Bug in bestimmten Versionen des Virtualisierers KVM, der z.B. QUEMU- oder Proxmox-Nutzer ab Version 7.x betrifft. Dann booten virtuelle Windows-Maschinen nicht mehr, wenn sie länger als 11 Tage gelaufen sind. Ich ziehe das Thema mal separat heraus.
Anzeige
Zittern bei Windows-Boots
Seit Februar zittern Administratoren virtualisierter Windows Server-Systeme vor jedem Patchday. Der Hintergrund: Das zum 14. Februar 2023 für Windows Server 2022 veröffentlichte Sicherheitsupdate KB5022842 hatte zur Folge, dass virtuelle Maschinen unter diversen ESXi-Versionen anschließend nach einem Reboot nicht mehr starten konnten. Es wurden entweder die Systemlaufwerke nicht mehr gefunden, oder die VMs lösten beim Booten einen Secure Boot-Fehler aus. Dieser Fehler ist durch ein ESXi-Update behoben (siehe Windows Server 2022: VMware ESXi 7.0 U3k-Patch für Secure Boot-Problem (Update KB5022842, Feb. 2023)).
Zudem habe ich im Blog-Beitrag Windows Server 2022 Feb. 2023 Patchday: Secure Boot-Problem auch auf Bare-Metal-Systemen! auf Fälle hingewiesen, wo der durch das Sicherheitsupdate KB5022842 verursacht Secure Boot-Fehler auch auftritt. Hier muss Secure Boot weiterhin ausgeschaltet bleiben. Treten Boot-Probleme mit virtualisierten) Windows auf, werden seit dieser Erfahrung gerne Windows-Updates als Ursache vermutet. Aber die Ursache könnte auch an anderer Stelle liegen.
KVM-Bug verhindert Boot
Im März 2023 ist mir dann im Blog ein ganz interessanter Kommentar von Joachim zugegangen, und er hatte mich auch nochmals per E-Mail darauf hingewiesen. Ausgangspunkt war, dass Blog-Leser Markus S. in diesem Kommentar Probleme mit Windows Server 2019 in Verbindung mit dem Patchday und der Update-Installation erwähnte. Der Server fror bei der Update-Installation ein. Joachim fragte in diesem Kommentar nach dem Virtualisierer, der verwendet wird.
Welchen Hypervisor hast Du? Das ist zb ein bekanntes Problem bei KVM und hat nichts mit Windows Updates zu tun. Der Fehler war recht schwer zu finden, weil es nur VMs betrifft, die 11 Tage oder länger gelaufen sind.
In seiner Ergänzungsmail an mich schrieb mir Joachim (danke dafür, hatte das Thema eh auf dem Radar für einen Blog-Beitrag):
Anzeige
Windows VMs, die auf einem Hypervisor mit einer bestimmten Version von KVM länger als 11 Tage laufen, können beim Booten hängen bleiben. Für Admins sieht es in fast allen Fällen dabei so aus, als ob ein Windows Update daran schuld wäre.
Details: Wir haben einen Hyper-Converged Hypervisor, der auf KVM aufsetzt. Vor ca. 2 Monaten gab es ein Upgrade, währenddessen einige VMs neu gestartet wurden und drei VMs nicht mehr erreichbar waren.
Die VMs zeigten einen schwarzen Schirm mit der Windows Bootanimation (Kreis), aber noch ohne Windows Logo.
Zuerst haben wir das als Anomalie abgetan, aber dann hat sich das in den Wochen danach gehäuft. Wir hatten alles in Verdacht (Windows Updates, Antivirus usw.) aber natürlich war der Zusammenhang mit dem Upgrade des Hypervisors auch im Blickfeld, auch wenn der Support meinte, das wäre sicher nicht das Upgrade, denn kein anderer Kunde hatte das Problem.
Das sind dann die Situationen, die kein Administrator ersehnt, denn die Ursachen sind nur mit Aufwand, viel testen und Recherche zu finden. Mir fällt der Blog-Beitrag Hyper-V: VMs und Host hängen sich auf; kein Netzwerkping außerhalb der eigenen VM ein, der wohl mit Tausch des Main-Boards behoben zu sein scheint. Joachim ist bei Recherchen auf einen exotischen Bug in KVM gestoßen, den er folgendermaßen beschreibt:
Einen Monat später habe ich selber durch Recherche das Problem per Zufall im Proxmox Forum gefunden: KVM hatte ab einer gewissen Version ein Problem mit VMs, die länger als 11 Tage gelaufen sind und dann neu gestartet wurden: Windows VMs stuck on boot after Proxmox Upgrade to 7.0 | Page 3 | Proxmox Support Forum (wir verwenden nicht Proxmox!)
Im Proxmox-Forum wird das Problem von einer Reihe Administratoren bestätigt. Es gibt zudem einen GitLab-Bug-Eintrag für Quemu (qemu 7.0.0 stuck at Windows boot logo with SeaBios and MBR disk), der folgendes Fehlerbild beschreibt:
When trying to boot an MBR Windows guest with SeaBios, it is stuck at the blue Windows boot logo, before the loading circle. Changing the vGPU doesn't help, 0% cpu load just frozen. Even if I boot a WinPE iso, the same happens. Even after 30 minutes, the same. Rebooted host multiple times. Since SeaBios is the default in qemu and virt-manager I imagine many VMs are installed as MBR and thus will be stuck.
Also auch ein Effekt, der vielen Administratoren bei der Update-Installation unter Windows bekannt vorkommen könnte. Joachim schrieb mir dazu:
Warum ist das interessant für Ihre Leser? Weil fast jeder das Problem auf Windows-Updates geschoben hat und ich das Problem bisher in keinem Blog gesehen habe! Siehe z.B. Kommentar von Peter S. hier Patchday: Windows 10-Updates (14. März 2023) Denn in 99% der Fälle wird das Problem ja erst beim ersten Neustart einer VM bemerkt – und Neustarts gibt es meist nach Windows Updates.
Auch hat der Hersteller unseres Hypervisors das Problem nicht in den aktuellen Release Notes vermerkt, obwohl das Problem durch die neue Version gelöst wurde. Auf Nachfrage wurde mir gesagt, dass das Problem zwar tatsächlich vorhanden war, aber außer uns kein Kunde ein Ticket eröffnet hat. Ich habe versucht klarzumachen, dass kaum ein Admin auf die Idee kommt, dass der Hypervisor das Problem ist, wenn eine Windows VM nach Windows Updates beim Start hängen bleibt. Das stieß aber auf taube Ohren. Damit bleibt den wenigen Admins, die Release Notes lesen, leider verborgen, dass eben nicht „wieder mal Windows Updates" daran schuld waren. Daher wäre schön, wenn Sie das veröffentlichen würden.
An dieser Stelle mein Dank an Joachim für die Hinweise und den Kommentar im Blog. Und ich habe nun das Vorhaben umgesetzt und das Thema mal hier im Blog erwähnt. Vielleicht liest es ein Administrator, der vielleicht betroffen ist, aber die Ursache noch nicht herausgefunden hat.
Ähnliche Artikel:
Windows Server 2022: Februar 2023-Patchday und das ESXi VM-Secure Boot-Problem
Windows Server 2022 Feb. 2023 Patchday: Secure Boot-Problem auch auf Bare-Metal-Systemen!
Windows Server 2022: VMware ESXi 7.0 U3k-Patch für Secure Boot-Problem (Update KB5022842, Feb. 2023)
Hyper-V: VMs und Host hängen sich auf; kein Netzwerkping außerhalb der eigenen VM
Windows Server 2019/2022: Dezember 2022-Sicherheitsupdates verursachen Hyper-V-Probleme
Windows Server 2019/2022: Out-of-Band Updates fixen Hyper-V-Probleme (20. Dez. 2022)
Nachlese: Fix für Hyper-V-Host Start-Problem in Windows (Januar 2022)
Windows 10: Outlook 2013 streikt bei Virtualisierungssoftware
Virtualisierung: Neue Office-Versionen als Performance-Killer
Anzeige
Wieso KVM-Bug, wenn es auch auf ESXi passiert? Ist VMware mal wieder beim Klauen erwischt worden oder liegt der Fehler bei Windows?
Artikel gelesen? Steht doch drin, dass es unterschiedliche Ursachen sind und es im Falle von KVM nichts mit einem Windows Update zu tun hat, bei ESX hingegen schon.
<- Ich würde meinen Beitrag vom 4. April 2023 um 13:23 Uhr gerne löschen. Hatte Thema falsch verstanden.
für mich habe ich jetzt nicht herauslesen können, was erforderlich ist, damit der Fehler nicht auftritt.
Eine VM ohne Windows *duckundwech*
Was den Proxmox betrifft, ist so ein Problem schon länger bekannt. Soll aber seit der PVE Version 7.3.6 endgültig der Vergangenheit angehören.
Im Falle von Proxmox ist die Lösung also tatsächlich Updates des Proxmox Systems.
Es gab auch mal einige Kernel Versionen im Proxmox, bei denen VMs einfach aus gegangen sind (pve QEMU: KVM: entry failed, hardware error 0x80000021). Ohne Vorwarnung. Vornehmlich Windows Server 2022.
Meistens merkt man das als Admin erst, wenn Windows Updates laufen. Eben weil dann erst neu gestartet wird.
Wenn ich ein tägliches Backup der VM habe und diese dann auf von dem wiederherstelle, müsste das Booten doch auch scheitern, wenn die Maschine länger als 11 Tage lief (Snapshot des laufenden Systems).
Spätestens dann müsste auch klar werden, dann es nicht an dem Windows Update liegt.
Warum würde jemand einen Restore eines Servers machen, nur weil dieser einmal beim Booten hängenbleibt?
Davon abgesehen setzt ein Restore ja voraus, dass die VM kalt gestartet wird. Damit tritt das Problem nicht auf. Nur bei Reboots bei VMs die länger als 11 Tage gelaufen sind.
Erinnert mich an den "weisen" Admin der die Server jede Nacht Durchbootete.
Da wäre der Fehler ja entweder sofort aufgefallen oder nie.
Zu dem warem die User schon so konditioniert , das, wenn die App hing einfach erst am nächsten Tag weitermachten ihn aber gar nicht erst behelligen.
Das 11 Tage uptime eine absolute Seltenheit ist ist ein April-Scherz, oder unglücklich formuliert?
Nö, ESXi war als Beispiel aufgeführt, welches dafür gesorgt hat, dass einige Admins virtualisierter Server nach jedem Patchday zittern. Das ESXi-Thema ist ja mit Lösung in den verlinkten Beiträgen aufgeführt.
Es geht hier um einen KVM-Bug – und dessen Verwendung in Drittanbieter-Virtualisierungslösungen – der sich manchen Admins aber "wie ein von Windows Updates verursachtes Problem" erscheint.
Entschuldigung, hatte ich falsch verstanden.
Danke für Klärung.
Herzlichen Dank.
Vielen Dank für den Hinweis, die Aufarbeitung der Informationen.
Auch wir setzen KVM basierte Hypervisor ein (inkl. Sea Software als Firmware der VMs) und hatten nach u.a. Upgrades der Umgebung (Hypervisor) ein Problem (bisher aber nicht auf VMware sondern bei der Konkurrenz), BIOS basierte VMs (also keine UEFI basierten VMs ~ diese waren / sind bis heute nicht betroffen / nutzen aber noch kein Secure Boot) neu zu installieren über SCCM PXE Boot.
SCCM PXE Boot nutzen wir aber nur für VDIs (virtualisierte Clients).
Die benötigen Treiber (Netzwerk, SCSI etc.) sind mit in dem Boot Image.
Diese wurden nicht angepasst oder das Boot Image verändert (wir hatten das Boot Image auch schon wiederhergestellt – da wir das zwischenzeitlich schon angepasst hatten für eine Erweiterung – aber durch den restore war klar, dass das nicht die eigentliche Ursache mehr sein konnte).
Interssant dabei ist nur, dass solange die virtuelle SCSI Disk nicht neu erstellt wird oder eine neue VM erstellt wird, der Fehler nicht auftritt.
Sprich: bei neuen VMs oder bei neu erstellter Disk, ist kein TFTP Boot per SCCM PXE mehr möglich gewesen (bis heute).
Die Fehlermeldung ähnelte dem des Melder (entry failed, hardware error…) nur bei dem Fehlercode bin ich mir aktuell unsicher (schon Monate her und aktuell alles aus dem Siebhirn gefischt).
Seitdem finde ich mich damit ab, jede BIOS VM gegen UEFI auszutauschen (die booten ja eh u.a. dadurch schneller).
Würde mich auch interessieren, ob andere ähnliche Erfahrungen dazu gemacht haben.
Wer setzt überhaupt Proxmox im Unternehmensumfeld ein? Bisher noch nie ein Cluster gesehen… Gut es gibt ja auch so IT-Landschaften in Unternehmen die ein SAMBA-AD einsetzen um Geld zu sparen. Aber beim Hypervisor? Wenn dann habe meine Kunden, die ich übernommen habe ESXi oder HyperV eingesetzt. Ganz vereinzelt XenServer, aber das ist dann auch eher die Ausnahme gewesen.
Im Proxmox-Forum wurde nur der KVM-Fehler gefunden. Sonst handelt der Artikel nicht vom Proxmox, sondern von einem KVM Bug. Und KVM wird von einigen HyperConverged-Hypervisor eingesetzt. Für die ist dieser Artikel.