Search results

I agree. Let us continue our way to testing. The first with Qemu 6.0.0-3, the second with Qemu 6.2 and SMM = OFF. Let's see in the coming weeks what the tests will reveal ...

@fiona ... I state that the tests I started (with a fully updated host but with QEMU downgraded to version 6.0.0-3 and with another node with a dozen Windows VMs running with the "args: -machine smm = off "are in progress and will not be interrupted until you understand if we are on the right...

@fiona On another cluster (7.2-7) completely updated and without alteration of the package versions, which naturally presents the same problems, I tried to setup on a dozen Windows server VMs .... args: -machine smm=off Let's see what happens ...

@fiona OK, node running the very last 7.2-7 with kernel Linux 5.15.39-1 BUT Qemu 6.0.0-3 is ready. Run the original Windows 10 VM (before the change in hung circles spinning) and a VM clone. And now... wait and testing........ This is the VM configuration;

i am totally sure that the windows 10 VM that is now running was in hung (circle spinning). So I am totally certain that this server a Lenovo sr650 like all the other servers I use (unfortunately) has this problem. And this is a certain starting point. I downgraded to Qemu 6.0.0-3 release and...

@fiona, very good news !!! I found a cluster in Proxmox enterprise 7.2-7 with a completely unloaded node, which, attention, was running a Windows 10 VM in HUNG post automatic reboot (spinning circle problem). So we are sure that this host falls within the issue here. Than I downgrade *only*...

... I would try downgrading (especially QEMU and kernel). Unfortunately I use clusters in production and I don't have a real test system, so I can't do such a thing. Does anyone have hardware that definitely has this problem and can downgrade pve-qemu-kvm = 6.0.0-3 ??? Thanks

OK, I also checked on an (old) cluster that has been running for more than two years of uptime with Proxmox 6.4 and kernel 5.4 (I use kernelcare). And he has never and I mean never had the slightest problem. Question, let's start with a certainty, kernel 5.4 is not the culprit so ... is it...

@fiona please refer #274

... strange. In October 2021 I was using pve-qemu 6.0.0-4 and we don't remember ever having any problems. The problems came later, in moving to Proxmox 7.1 in December 2021

Unfortunately I can't because all the clusters we manage are in production. I had raised some time ago that in my first installations of Proxmox 7.0 the problem did not occur, please refer to # 274-5 That's why I was asking to try one of the early 5.11 kernels (September 2021) and / or QEMU 6.0

Sorry but I don't understand. What is the point of doing kernel rollback tests on Proxmox 6.4 which is in EOL? Doesn't it make more sense to do some rollback tests on Proxmox 7.2-7, for example trying a 5.11 kernel from September 2021, or maybe doing a rollback of QEMU to 6.0? The aim is to...

At this point ... if any of you have the opportunity to do so, you should try to do a rollback on a fully upgraded Proxmox 7.2-7 server of a 5.11 kernel from September-October (maximum) 2021. ... and try it for at least a month ...

is the qemu version identical on both?

... so you are proposing to use the version that was in use at Proxmox 6.x in Proxmox 7, as a major release downgrade to check if really the problem is in QEMU, correct? The test is really interesting, not aimed at using QEMU 5 in Proxmox 7, well understood, but to understand if the problem is...

At this point, in my opinion, after all I'm messed up there is only one thing to do, as debugging is extremely difficult to do. Change one of the milestones that characterize the system, passing for example to QEMU 7.

... the thing is more and more interesting, if we continue like this by the end of the year we could bind all the posts in a book. What you say would justify the different behavior between Debian and Ubuntu. Now one reason is clear. I just have a doubt ... it's a different problem than the one...

@t.lamprecht The fact that this problem also occurs on Ubuntu (although I don't know in the least how it can be, since it is practically the same as Debian and Debian does not have the slightest problem on clusters with Windows VMs that present it in an obvious way). It might help to facilitate...

Interestingly, I have more than 50 Debian 11 VMs on multiple Proxmox 7.2 clusters (all of which have this problem with Windows 2012r2 and up), but never a Debian VM with 5.10 amd64 kernel has had this problem, ever. How does Ubuntu 20.04 differ from Debian 11? Ok from the kernel version ...

Yes, this would justify why Windows 2008r2 never gave any problems. Either there is something different in Windows 2008r2 or its patch level (commercial until 31-12-2022) does not include what introduced the problem. Everyone who writes here has problems. I don't have clusters where I can...