Windows VMs stuck on boot after Proxmox Upgrade to 7.0
- Thread starter lolomat
- Start date
... Interesting. I use VM Debian 11 heavily and never, ever did the problem arise with those. Instead with Windows VM it is a bloodbath (from 2012 upwards, with 2008 never no problem).
Any guess already what the issue is caused by? Or maybe already an idea of fix? Please keep us updated a little bit. Some customers already start to cry. Explanation is getting harder. However we still tell them that this might take some more time....
Totally agree. If PVE maintainers managed to reproduce the issue they at least should get some more details on it and could provide them to pve community. It's not the rare issue. Lots of PVE users are facing it and it has already become a nightmare for dozen of them
Last edited:
I would like to be extremely transparent, it is in everyone's interest that this problem be solved and we all stop for at least a workaround. In a few days the Microsoft updates will be released and we are ready for a new death of VMs that do not restart at the reboot.
A lot has been written, 13 pages, and the last thing I want is to hear what has already been said.
Update server firmware, update Intel or AMD microcode. Turn off workarounds for spectre and the like.
All things already done, already tried. Nothing.
In my opinion we need to focus on the reliable data we have. Why does win 2008r2 have no problems and why do they appear from 2012 on? Proxmox 6.4 is OK, never stuck on reboot, never ... Why?
I got same problem on my pve 7 hosts. I read the complete thread. So i think the only way is to build a stop/start script if the system stucks?!
Yes, correct.
Hy
looks like we had the same idea, so last day's I wrote one of my first phython-scripts. Please don't take a closer look to my code *lol*
* The script starts from cron how often you want.
* A "qemu ping" checks if vm is responding or not.
If not, the script tries to ping via network. Name of vm is used as hostname. If also the second ping failes, am qm stop and start will restart the vm
* To skip a vm set "cbxSkipHeartbeatCheck" in notice
!!! Please test the script before productive use !!!
looks like we had the same idea, so last day's I wrote one of my first phython-scripts. Please don't take a closer look to my code *lol*
* The script starts from cron how often you want.
* A "qemu ping" checks if vm is responding or not.
If not, the script tries to ping via network. Name of vm is used as hostname. If also the second ping failes, am qm stop and start will restart the vm
* To skip a vm set "cbxSkipHeartbeatCheck" in notice
!!! Please test the script before productive use !!!
Hi,
EDIT 2: unfortunately, this doesn't seem to be a valid workaround after all. Post #267 mentions that
how many of you tried setting
I'm asking because there's post #82 suggesting this. And now there's a new report where changing the guest OS type to
EDIT 2: unfortunately, this doesn't seem to be a valid workaround after all. Post #267 mentions that
localtime: 0 didn't work for them and the user reporting that OS type other helped, also ran into the issue again (probably was just lucky in the beginning).how many of you tried setting
localtime: 0 as a potential workaround? (EDIT: Of course you need to stop/start the VM for the setting to actually takes effect. Note that the change will affect the time seen by the guest, so be careful when applying this to production VMs).I'm asking because there's post #82 suggesting this. And now there's a new report where changing the guest OS type to
other helped. One of the few things changing the OS type after VM creation affects is the default value of the localtime setting (Use local time for RTC in the UI). It's only enabled by default when the OS type is Windows.
Last edited:
.. I don't think this setting modification has ever been tried .... however I have to shut down the VM I cannot move between the cluster nodes and get the new "localtime: 0" configuration, thanks @fabian
Last edited:
Yes, enterprise repo has the same problem. if you don't want to have this problem you have to use Proxmox 6.4
i just apply modification to all my 160 VM (Windows 2019 datacenter) that have same behaviour, live migrate to and from to another cluster member (it took some hour), but we have to wait some day to have feedback
cluster, 3 supermicro Intel(R) Xeon(R) Gold 6226R CPU @ 2.90GHz, kernel 5.13.19-2-pve, pve-qemu-kvm 6.1.0-3
see you later
Interestingly, if I make a non-applicable hot change, like this one, and I perform a motion of the vm on another node, does the change remain in the "not applied" state because it waits for the vm to stop start, instead is it applied the same during the motion? So is it just an "aesthetic" bug? The thing is interesting, if I have to apply this workaround to a consistent number of VMs there is a lot of difference. Regardless, what matters is solving the age-old problem. So let's try this workaround.