Ich war schon zuversichtlich, fast 4 Tage lief alles perfekt. Soeben schmierte der RDP (Terminal) Server im laufenden Betrieb ab. Ich habe die aktuellen Patches für Server 2022 installiert. Das Verhalten ist aber jetzt anders. Vorher schmierten die Systeme immer Nachts ab, jetzt (viel schlimmer) während der Arbeitszeit. Die anderen beiden 2022 hat es derweil noch nicht getroffen. Die sind auch beide am aktuellen Stand mit Updates. Ich habe Kernel 5.15.30-2-pve am laufen
Windows Server 2022 - Das System wurde unerwartet heruntergefahren
- Thread starter anjo
- Start date
-
- Tags
- windows server 2022
Hallo zusammen, ich kann das Problem bei mir auch bestätigen. Es laufen 2x WinSRV 2022 und 6x Win11, alle mit aktuellen Updates von MS. Meine Kernel Version von PVE ist ( Linux 5.15.35-1-pve #1 SMP PVE 5.15.35-3 (Wed, 11 May 2022 07:57:51 +0200 ). An Überlast des Hosts kann es nicht liegen 
.
Host HW ( alle VM´s in Betrieb ):
Vielleicht ist es wirklich ein Problem eines MS Updates: siehe hier -> Win 11 Update generiert unspezifische Fehler
Ansonsten kann ich bestätigen, das es nicht immer die selbe Maschine betrifft. Bis jetzt kam es nur 1x bei einem WinSRV 2022 vor. Häufiger und immer wieder eine andere Win 11 Maschine, das ist Fakt.
VM WinSRV 2022 Konfig:
VM Win 11 Konfig:
Auch bei meinen Maschine ist pre-enrolled-keys = on. Wenn das das Problem sein sollte, wie und was sollte dann angepasst werden ?
LOG´s habe ich geleert und lasse aktuell neu füllen bis zum CRASH, dann reiche ich nach.
.Host HW ( alle VM´s in Betrieb ):
Vielleicht ist es wirklich ein Problem eines MS Updates: siehe hier -> Win 11 Update generiert unspezifische Fehler
Ansonsten kann ich bestätigen, das es nicht immer die selbe Maschine betrifft. Bis jetzt kam es nur 1x bei einem WinSRV 2022 vor. Häufiger und immer wieder eine andere Win 11 Maschine, das ist Fakt.
VM WinSRV 2022 Konfig:
VM Win 11 Konfig:
Auch bei meinen Maschine ist pre-enrolled-keys = on. Wenn das das Problem sein sollte, wie und was sollte dann angepasst werden ?
LOG´s habe ich geleert und lasse aktuell neu füllen bis zum CRASH, dann reiche ich nach.
Hier hat es dann vor 10 Minuten einen Exchange-Server "hingelegt". Wir deinstallieren jetzt einfach mal das 05/22 CU (KB5013944). Vielleicht macht das einen Unterschied....
Ergänzend.... die Kiste wird mit VEEAM inGuest gesichert und hat sich grad noch mal hingelegt, direkt als der VSS-Snapshot für VEEAM erstellt werden sollte....
Bei uns verdichten sich grad die Hinweise das Server 2022 ohne virtuelles TPM das Problem nicht hat. Unabhängig vom Patch-Stand des Gastes...
Das könnte auch dem Erscheinungsbild bei mir entsprechen. Da erst nach diesem MS Update bestimmte Apps nicht mehr starteten bzw. sporadisch crashten. Nach der Deinstallation liefen die Apps wieder 
Ob das aber daran liegt, das VM´s sich einfach ausschalten, sei dahingestellt
Ob das aber daran liegt, das VM´s sich einfach ausschalten, sei dahingestellt
TPM 2.0 mit dem aktuellen PVE Kernel 5.15.35-1 ?
Frage nur, weil das auch erst mit diesem Kernel auftritt.
Und hier auch das Problem... wobei wir aktuell den Gast auf CU 04/22 zurückgesetzt haben....
das betrifft auch den Kernel 5.15.30.2 -> diesen habe ich am laufen und da sind 3 Windows SRV 2022 betroffen
Kannst du schon was sagen? Problem noch da mit altem Kernel und/oder ohne Updates?
Ich habe vor 2 Tagen auf den alten Kernel gewechselt, die VM läuft seither stabil.
Windows Server 2022 Updates installiert incl. TPM
Windows Server 2022 Updates installiert incl. TPM
So, ich hab bis jetzt immer nur mitgelesen uns selbst herumprobiert. Leider ohne Erfolg.
Soeben ein neues Windows Update (KB5014021) installiert. Während der installation schmierte Win2022 DE einfach ab.
Hier die Log:
Vielleicht kann damit jemand was anfangen...
Kernelversion: Linux 5.15.35-1-pve #1 SMP PVE 5.15.35-3 (Wed, 11 May 2022 07:57:51 +0200)
Soeben ein neues Windows Update (KB5014021) installiert. Während der installation schmierte Win2022 DE einfach ab.
Hier die Log:
Code:
May 25 05:47:58 proxmox QEMU[1359224]: KVM: entry failed, hardware error 0x80000021
May 25 05:47:58 proxmox QEMU[1359224]: If you're running a guest on an Intel machine without unrestricted mode
May 25 05:47:58 proxmox QEMU[1359224]: support, the failure can be most likely due to the guest entering an invalid
May 25 05:47:58 proxmox QEMU[1359224]: state for Intel VT. For example, the guest maybe running in big real mode
May 25 05:47:58 proxmox QEMU[1359224]: which is not supported on less recent Intel processors.
May 25 05:47:58 proxmox QEMU[1359224]: EAX=00000578 EBX=003553e8 ECX=00000000 EDX=ccaae000
May 25 05:47:58 proxmox QEMU[1359224]: ESI=cc8e90a0 EDI=002fc188 EBP=89572b60 ESP=b82abfb0
May 25 05:47:58 proxmox QEMU[1359224]: EIP=00008000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=1 HLT=0
May 25 05:47:58 proxmox QEMU[1359224]: ES =0000 00000000 ffffffff 00809300
May 25 05:47:58 proxmox QEMU[1359224]: CS =bc00 7ffbc000 ffffffff 00809300
May 25 05:47:58 proxmox QEMU[1359224]: SS =0000 00000000 ffffffff 00809300
May 25 05:47:58 proxmox QEMU[1359224]: DS =0000 00000000 ffffffff 00809300
May 25 05:47:58 proxmox QEMU[1359224]: FS =0000 00000000 ffffffff 00809300
May 25 05:47:58 proxmox QEMU[1359224]: GS =0000 00000000 ffffffff 00809300
May 25 05:47:58 proxmox QEMU[1359224]: LDT=0000 00000000 000fffff 00000000
May 25 05:47:58 proxmox QEMU[1359224]: TR =0040 b82a0000 00000067 00008b00
May 25 05:47:58 proxmox QEMU[1359224]: GDT= b82a1fb0 00000057
May 25 05:47:58 proxmox QEMU[1359224]: IDT= 00000000 00000000
May 25 05:47:58 proxmox QEMU[1359224]: CR0=00050032 CR2=37863b70 CR3=4a942000 CR4=00000000
May 25 05:47:58 proxmox QEMU[1359224]: DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
May 25 05:47:58 proxmox QEMU[1359224]: DR6=00000000ffff0ff0 DR7=0000000000000400
May 25 05:47:58 proxmox QEMU[1359224]: EFER=0000000000000000
May 25 05:47:58 proxmox QEMU[1359224]: Code=kvm: ../hw/core/cpu-sysemu.c:77: cpu_asidx_from_attrs: Assertion `ret < cpu->num_ases && ret >= 0' failed.
May 25 05:47:58 proxmox kernel: set kvm_intel.dump_invalid_vmcs=1 to dump internal KVM state.
May 25 05:47:59 proxmox kernel: fwbr100i0: port 2(tap100i0) entered disabled state
May 25 05:47:59 proxmox kernel: fwbr100i0: port 2(tap100i0) entered disabled state
May 25 05:47:59 proxmox pveproxy[1388320]: worker exit
May 25 05:47:59 proxmox systemd[1]: 100.scope: Succeeded.
May 25 05:47:59 proxmox systemd[1]: 100.scope: Consumed 20min 37.340s CPU time.
May 25 05:47:59 proxmox qmeventd[1432843]: Starting cleanup for 100
May 25 05:47:59 proxmox kernel: fwbr100i0: port 1(fwln100i0) entered disabled state
May 25 05:47:59 proxmox kernel: vmbr0: port 2(fwpr100p0) entered disabled state
May 25 05:47:59 proxmox kernel: device fwln100i0 left promiscuous mode
May 25 05:47:59 proxmox kernel: fwbr100i0: port 1(fwln100i0) entered disabled state
May 25 05:47:59 proxmox kernel: device fwpr100p0 left promiscuous mode
May 25 05:47:59 proxmox kernel: vmbr0: port 2(fwpr100p0) entered disabled state
May 25 05:47:59 proxmox qmeventd[1432843]: Finished cleanup for 100Vielleicht kann damit jemand was anfangen...
Kernelversion: Linux 5.15.35-1-pve #1 SMP PVE 5.15.35-3 (Wed, 11 May 2022 07:57:51 +0200)
Pin den Kernel Linux 5.13.19-6-pve danach ist das Problem weg. Es wird sicher irgendwann eine Lösung geben mit aktuellem Kernel. Da es mit einem "älteren" Kernel wieder stabil ist, vermute ich nicht das es "wirklich" an Windows Server 2022 liegt sondern an einer Unverträglichkeit die im neuen Kernel Einzug gehalten hat.
Hallo zusammen, ich kann das Problem bei mir auch bestätigen. Es laufen 2x WinSRV 2022 und 6x Win11, alle mit aktuellen Updates von MS. Meine Kernel Version von PVE ist ( Linux 5.15.35-1-pve #1 SMP PVE 5.15.35-3 (Wed, 11 May 2022 07:57:51 +0200 ). An Überlast des Hosts kann es nicht liegen
Host HW ( alle VM´s in Betrieb ):
View attachment 37209
Vielleicht ist es wirklich ein Problem eines MS Updates: siehe hier -> Win 11 Update generiert unspezifische Fehler
Ansonsten kann ich bestätigen, das es nicht immer die selbe Maschine betrifft. Bis jetzt kam es nur 1x bei einem WinSRV 2022 vor. Häufiger und immer wieder eine andere Win 11 Maschine, das ist Fakt.
VM WinSRV 2022 Konfig:
View attachment 37210
VM Win 11 Konfig:
View attachment 37211
Auch bei meinen Maschine ist pre-enrolled-keys = on. Wenn das das Problem sein sollte, wie und was sollte dann angepasst werden ?
LOG´s habe ich geleert und lasse aktuell neu füllen bis zum CRASH, dann reiche ich nach.
Kurze Wasserstandsmeldung:
Seit den letzten 3 Tagen laufen alle Maschinen ohne abgeschmiert zu sein und das mit Kernel 5.15.35-1. Sobald sich was ändert poste ich.
Meine Vermutung ist, das die KVM Treiber in Kombi mit Win22 / Win11 und dem neuen Kernel nicht harmonieren. Zumindest kommt bei allen der Hardware Error 0x80000021 ( kvm Fehler ).
PS: Alle Win Updates inkl. des auffälligen KB5013943 sind auf den Maschinen am Laufen.
Last edited:
Installiert sind die virtio 0.1.215-2 Treiber. Die Versionen 0.1.215; 0.1.2.15-1; 0.1.217 liefen bei der Installation der Win22 / Win11 Maschinen nicht mit pc-q35 6.1.
Deshalb auch die Vermutung das dort Inkompatibilitäten bestehen, zumindest mit der deutschen Version von den Win Maschinen ISO´s.
Deshalb auch die Vermutung das dort Inkompatibilitäten bestehen, zumindest mit der deutschen Version von den Win Maschinen ISO´s.
Laut Recherche sollte man (als Workaround) auf den Kernel 5.13 zurück gehen.
Der 5.15 scheint allgemein etwas "buggy" zu sein
Der 5.15 scheint allgemein etwas "buggy" zu sein