Search results

no, my guess doesn't work like that. I thought that following the passage in 5.13 of proxmox 7.0-> 7.1 something had been brought back towards the 5.11 kernel of proxmox 6.4 that had inserted the problem. But the dates don't prove me right.

5.11. ?? What subversion ? The 5.11.xxx on Proxmox 6.4 is newer than 5.11.22-7 on proxmox 7.0 that worked without the slightest problem? Could it have been a backport problem that also affected Proxmox 6.4?

in fact, I went to look for my colleagues' emails, the first problems arose around the week of January 17-21, 2022, coinciding with the application of Microsoft updates and the VMs, 25 days after Proxmox was updated.

I'm perfectly agree. As I said months ago in this thread, the problem is in QEMU, the kernel or both. And now ? It is too much of a gamble to roll back several clusters in production to a kernel and QEMU version from 8 months ago ... running on Proxmox 7.2-7 enterprise. :)

OK, these are my logs on that cluster in production (production activation day 1 October 2021, all nodes restarted for pre-production tests, officially in production on the afternoon of 1 October 2021). ********************************* Start-Date: 2021-10-04 21:30:06 Commandline: apt...

I was re-reading the various posts and something came to mind. I installed a cluster in production with Proxmox 7.0 on 1 October 2021 and until mid-December 2021 I have not noticed any problems. Was it just a coincidence or did some events occur in December 2021? Going back "to when" to...

very bad news.

> how long before shutdown -r on all VM to see if workaround works ? ( 1 weeks ? ) I think more than 2 weeks

The problem is not how the configuration has been changed, but how it is applied. This type of modification requires the stop-start of the VM.

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 "solution" is stop && start (for now) :)

Stop and Start the VM "resolve" the problem (this one)

Yes, enterprise repo has the same problem. if you don't want to have this problem you have to use Proxmox 6.4

.. 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

Yes, correct.

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...

... 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).

Thanks @mira, I understand that supporting multiple versions becomes a hardly sustainable job. I think this specific case is a bit different, I have been using Proxmox since version 2.0 and I have never had a blocking problem that is not solved in 8 months. I also understand for us users who pay...

@mira : seems indifferent. Answer No. 34

@mira ... I would like to raise a question absolutely without a note of controversy, just to examine the reality of the facts. I find it incorrect on the part of the Proxmox team to stop support for Proxmox VE 6.4 on July 31st when the 8 month version 7.x has problems, and I don't tell one...