Many thanks for the analysis you are doing. It is not clear to me if the problem is related to the server firmware and / or the kernel. I say this because with the same firmware version the problem occurs with both 5.13 and 5.15 kernels. However in my specific case we are talking about several server clusters (lenovo) with firmware dated October 2021. I know for a fact that there was an update in February 2022. So, should I update that server's firmware?
Windows VMs stuck on boot after Proxmox Upgrade to 7.0
- Thread starter lolomat
- Start date
May you try to set the Machine Type as Q35, instead of i440fx type, and see if the issue will happen again?
@Moayad ,
maybe you are referring to a different problem, because the one that represents the focus of this thread is unrelated to the type machine (Q35 or i440fx).
As mentioned above.
Same story on many Windows vms in our cluster (Windows Server 2012/2016/2019). NFS storage and SCSI disks techzpod download mobdro
Last edited:
And what did you try so far, after reading the hints in this thread?
I use several Lenovo server clusters (sr650), some time ago I updated the UEFI firmware of two clusters to version 3.22, this includes an Intel microcode update (Update processor microcode to MB750654_02006C0A, MBF50656_0400320A, MBF50657_0500320A).
The intel-microcode software does not bring benefits, it does not make further updates to the specific version for these processors.
The saddest thing is that ... this morning a server stuck to the automatic reboot.
Have any of you made improvements by updating the microcode?
Should I try turning off mitigations?
I don't use GRUB, I use two Nvme mirrored ZFS as boot media, where should I put that option?
The intel-microcode software does not bring benefits, it does not make further updates to the specific version for these processors.
The saddest thing is that ... this morning a server stuck to the automatic reboot.
Have any of you made improvements by updating the microcode?
Should I try turning off mitigations?
I don't use GRUB, I use two Nvme mirrored ZFS as boot media, where should I put that option?
Hi All
Just to put in more info that will be semi helpful.
I see multiple issues here that are potentially being grouped together.
There are QEMU and Windows specific issues, probably others too that are presenting as the same behaviour but are a different issue all together.
We’ve been running VMware and ProxMox for years and have seen this same behaviour for windows servers that have been rebooted by the OS.
Haven’t run into This with Unix based VM’s yet.
Same logo screen with spinning balls stuck indefinitely until the VM is powered down/ up.
It doesn’t happen every time on a reboot but often after windows updates and reboot.
The solution is the same power down/ up resolves the problem.
Some fixes for VMware refer to changing the windows VM type from 2008 > 2012 > 2016 > 2019 etc as there are some os specific VM modes.
Even after these changes the issue still presents regularly after windows updates again not every reboot but often.
If you perform a google search for stuck windows after reboot and add your favourite hypervisor to the search term you’ll see it’s a common issue for windows across every hypervisor and even on bare metal.
For those experiencing this with Debian or other OS’s this may be related to QEMU and potentially your hardware configuration for the VM etc, remove USB devices from the VM under options, change machine types etc, update kernels and make sure QEMU guest tools are installed if available as some troubleshooting steps.
We see these issues across Intel CPU’s mostly but it still presents on AMD just less frequently, could just be a coincidence that it’s presenting less on AMD.
This forum post has so many different scenarios happening that are presenting the same solution presented doesn’t mean that it will resolve for someone else’s problem.
Hopefully the info above will help some readers differentiate their issues from others and look at other options for a fix.
“”G
Just to put in more info that will be semi helpful.
I see multiple issues here that are potentially being grouped together.
There are QEMU and Windows specific issues, probably others too that are presenting as the same behaviour but are a different issue all together.
We’ve been running VMware and ProxMox for years and have seen this same behaviour for windows servers that have been rebooted by the OS.
Haven’t run into This with Unix based VM’s yet.
Same logo screen with spinning balls stuck indefinitely until the VM is powered down/ up.
It doesn’t happen every time on a reboot but often after windows updates and reboot.
The solution is the same power down/ up resolves the problem.
Some fixes for VMware refer to changing the windows VM type from 2008 > 2012 > 2016 > 2019 etc as there are some os specific VM modes.
Even after these changes the issue still presents regularly after windows updates again not every reboot but often.
If you perform a google search for stuck windows after reboot and add your favourite hypervisor to the search term you’ll see it’s a common issue for windows across every hypervisor and even on bare metal.
For those experiencing this with Debian or other OS’s this may be related to QEMU and potentially your hardware configuration for the VM etc, remove USB devices from the VM under options, change machine types etc, update kernels and make sure QEMU guest tools are installed if available as some troubleshooting steps.
We see these issues across Intel CPU’s mostly but it still presents on AMD just less frequently, could just be a coincidence that it’s presenting less on AMD.
This forum post has so many different scenarios happening that are presenting the same solution presented doesn’t mean that it will resolve for someone else’s problem.
Hopefully the info above will help some readers differentiate their issues from others and look at other options for a fix.
“”G
There's an update on the bugtracker which is interesting.
https://bugzilla.proxmox.com/show_bug.cgi?id=3933
If that holds up that would point to some additional processes outside the vm (dismounting, CEPH syncing, making sure other processes aren't accessing the vm, etc) that is performed during a proxmox triggered reboot; because presumably proxmox isn't doing any reboot prep processes inside the Windows vm; Windows is likely doing it's own builtin things identically in those 4 scenarios.
https://bugzilla.proxmox.com/show_bug.cgi?id=3933
If that holds up that would point to some additional processes outside the vm (dismounting, CEPH syncing, making sure other processes aren't accessing the vm, etc) that is performed during a proxmox triggered reboot; because presumably proxmox isn't doing any reboot prep processes inside the Windows vm; Windows is likely doing it's own builtin things identically in those 4 scenarios.
... me too. Windows receives the restart signal from the QEMU AGENT or via ACPI, then whether the reboot signal is passed from the agent or inside the VM, what changes?
For Proxmox a VM reboot does not imply closing the QEMU process and opening a new one, it always remains the same. Different speech for the stop-start.
mmmm I've never seen that error .. and I'm talking about a good number of clusters. While the problem of spinning balls when restarting VMs arises methodically.
I personally think that this problem (KVM: entry failed, hardware error 0x80000021) is related to the specific machine and its firmware. I use more than 14 Lenovo servers, UEFI firmware as of February 2022 and I've never seen this problem.
As mentioned before, however, the problem under discussion (spinning balls on reboot) happens everywhere.
As mentioned before, however, the problem under discussion (spinning balls on reboot) happens everywhere.