Windows Server 2022 and Suspect Edge Instability
-
What’s the hypervisor?
-
-
@VoIP_n00b said in Windows Server 2022 and Suspect Edge Instability:
What’s the hypervisor?
ProxMox / KVM
-
@VoIP_n00b said in Windows Server 2022 and Suspect Edge Instability:
https://forum.proxmox.com/threads/windows-server-2022-crashing-randomly.109823/
Hmmm... no real answers there. And someone reported it on non-ProxMox, too. Which suggests it's just Windows Server 2022 being unstable.
So far since removing Edge as the default browser, it hasn't done it. But "not doing it yet" isn't much proof of anything.
-
It's been a few days without Edge, but the power off event happened again anyway
-
@scottalanmiller said in Windows Server 2022 and Suspect Edge Instability:
@VoIP_n00b said in Windows Server 2022 and Suspect Edge Instability:
https://forum.proxmox.com/threads/windows-server-2022-crashing-randomly.109823/
Hmmm... no real answers there. And someone reported it on non-ProxMox, too. Which suggests it's just Windows Server 2022 being unstable.
So far since removing Edge as the default browser, it hasn't done it. But "not doing it yet" isn't much proof of anything.
Do you have any of the log information like they have in that thread?
-
@Dashrender said in Windows Server 2022 and Suspect Edge Instability:
@scottalanmiller said in Windows Server 2022 and Suspect Edge Instability:
@VoIP_n00b said in Windows Server 2022 and Suspect Edge Instability:
https://forum.proxmox.com/threads/windows-server-2022-crashing-randomly.109823/
Hmmm... no real answers there. And someone reported it on non-ProxMox, too. Which suggests it's just Windows Server 2022 being unstable.
So far since removing Edge as the default browser, it hasn't done it. But "not doing it yet" isn't much proof of anything.
Do you have any of the log information like they have in that thread?
Yes, it points to this...
https://bugzilla.redhat.com/show_bug.cgi?id=832986
But the CPU is Haswell.
-
Jun 16 03:04:46 vmhost1 QEMU[3874067]: KVM: entry failed, hardware error 0x80000021 Jun 16 03:04:46 vmhost1 QEMU[3874067]: If you're running a guest on an Intel machine without unrestricted mode Jun 16 03:04:46 vmhost1 QEMU[3874067]: support, the failure can be most likely due to the guest entering an invalid Jun 16 03:04:46 vmhost1 QEMU[3874067]: state for Intel VT. For example, the guest maybe running in big real mode Jun 16 03:04:46 vmhost1 QEMU[3874067]: which is not supported on less recent Intel processors. Jun 16 03:04:46 vmhost1 QEMU[3874067]: EAX=c6d3f428 EBX=042da075 ECX=ef86ad60 EDX=ef9f3000 Jun 16 03:04:46 vmhost1 QEMU[3874067]: ESI=45d01090 EDI=003e4510 EBP=eb3bfca0 ESP=44591fb0 Jun 16 03:04:46 vmhost1 QEMU[3874067]: EIP=00008000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=1 HLT=0 Jun 16 03:04:46 vmhost1 QEMU[3874067]: ES =0000 00000000 ffffffff 00809300 Jun 16 03:04:46 vmhost1 QEMU[3874067]: CS =c200 7ffc2000 ffffffff 00809300 Jun 16 03:04:46 vmhost1 QEMU[3874067]: SS =0000 00000000 ffffffff 00809300 Jun 16 03:04:46 vmhost1 QEMU[3874067]: DS =0000 00000000 ffffffff 00809300 Jun 16 03:04:46 vmhost1 QEMU[3874067]: FS =0000 00000000 ffffffff 00809300 Jun 16 03:04:46 vmhost1 QEMU[3874067]: GS =0000 00000000 ffffffff 00809300 Jun 16 03:04:46 vmhost1 QEMU[3874067]: LDT=0000 00000000 000fffff 00000000 Jun 16 03:04:46 vmhost1 QEMU[3874067]: TR =0040 44578000 00000067 00008b00 Jun 16 03:04:46 vmhost1 QEMU[3874067]: GDT= 44579fb0 00000057 Jun 16 03:04:46 vmhost1 QEMU[3874067]: IDT= 00000000 00000000 Jun 16 03:04:46 vmhost1 kernel: [820087.940851] set kvm_intel.dump_invalid_vmcs=1 to dump internal KVM state. Jun 16 03:04:46 vmhost1 QEMU[3874067]: CR0=00050032 CR2=7fdbd008 CR3=43132000 CR4=00000000 Jun 16 03:04:46 vmhost1 QEMU[3874067]: DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 Jun 16 03:04:46 vmhost1 QEMU[3874067]: DR6=00000000ffff0ff0 DR7=0000000000000400 Jun 16 03:04:46 vmhost1 QEMU[3874067]: EFER=0000000000000000 Jun 16 03:04:46 vmhost1 QEMU[3874067]: Code=kvm: ../hw/core/cpu-sysemu.c:77: cpu_asidx_from_attrs: Assertion `ret < cpu->num_ases && ret >= 0' failed. Jun 16 03:04:46 vmhost1 kernel: [820087.965962] fwbr103i0: port 2(tap103i0) entered disabled state Jun 16 03:04:46 vmhost1 kernel: [820087.966340] fwbr103i0: port 2(tap103i0) entered disabled state Jun 16 03:04:47 vmhost1 systemd[1]: 103.scope: Succeeded. Jun 16 03:04:47 vmhost1 systemd[1]: 103.scope: Consumed 1d 16h 5min 37.551s CPU time. Jun 16 03:04:48 vmhost1 qmeventd[1217519]: Starting cleanup for 103 Jun 16 03:04:48 vmhost1 kernel: [820089.088391] fwbr103i0: port 1(fwln103i0) entered disabled state Jun 16 03:04:48 vmhost1 kernel: [820089.088483] vmbr0: port 5(fwpr103p0) entered disabled state Jun 16 03:04:48 vmhost1 kernel: [820089.088937] device fwln103i0 left promiscuous mode Jun 16 03:04:48 vmhost1 kernel: [820089.088943] fwbr103i0: port 1(fwln103i0) entered disabled state Jun 16 03:04:48 vmhost1 kernel: [820089.120903] device fwpr103p0 left promiscuous mode Jun 16 03:04:48 vmhost1 kernel: [820089.120909] vmbr0: port 5(fwpr103p0) entered disabled state Jun 16 03:04:48 vmhost1 qmeventd[1217519]: Finished cleanup for 103
-
@scottalanmiller said in Windows Server 2022 and Suspect Edge Instability:
KVM: entry failed, hardware error 0x80000021
Assume that you've read this thread.
-
@Danp said in Windows Server 2022 and Suspect Edge Instability:
@scottalanmiller said in Windows Server 2022 and Suspect Edge Instability:
KVM: entry failed, hardware error 0x80000021
Assume that you've read this thread.
Yeah. Lots of "try this" in there. Nothing definitive. We are testing disabling nesting right now. But it requires a reboot and we are in production.
-
Tested the fix of changing nesting to disable. So far, so good. But it'll take time to know.
-
@scottalanmiller said in Windows Server 2022 and Suspect Edge Instability:
Tested the fix of changing nesting to disable. So far, so good. But it'll take time to know.
Another day, no crashes. So far this fix is working and is really easy.