Search results

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

Ok many thanks. You mean the Debian intel-microcode package, correct?

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

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

Yes, I can confirm exactly every step!

... for this reason I am reasonably convinced that the problem is Qemu 6.x. @Moayad, is it possible to create a pure testing package with Qemu 7.0, or with a 5.x version? Try tapping one variable at a time to identify the problem (if it fails to identify through debugging). IMHO

@Moayad for any need to investigate the issue, please let us know. We are going crazy managing dozens and dozens of Windows VMs that go into stuck after each update.

No, 99% that can't be the problem. The reasons for this sentence are in the posts I wrote previously. I don't value Windows (and I never did) just as I don't value Microsoft's policies. But in this case a correlation of low-level events is evident. With Proxmox 6.4 latest version, Windows 2012...

No, I strongly believe that the problem is different from the one highlighted in Azure. First of all, the hung screen is different, in my opinion the point where the system stops is different. This is a 2016 post upgrade screen ... the balls are spinning ... Again, I just updated several...

In my opinion we should investigate further for several reasons ... The first ... I do not think that the vm in hung displays the word "getting Windows ready" but only presents the spinning balls. It might have a different meaning. The second reason is that with qemu 5.x the problem does not...

Sorry, but after several months I still don't understand one thing. Has the Proxmox support team (also the official one via ticket, since we also tried that route) NEVER replicated the problem? Every time we asked (via ticket) the response was "we know someone is complaining but we have never...

Okay, personally this has never happened to me. Always the same problem ... Reboot and balls that spin endlessly. Only on vm Windows, never on vm Debian or vm FreeBSD and always after a certain period (several days) that the vm is running. On different storage systems, on different Qemu settings...

At that stage no request is made, no input is required. At least it's not visible.

Typically when the vm goes into stuck a black screen is not displayed but the Windows loading with the balls spinning and goes on indefinitely. The balls move, the vm is NOT in freeze, it just stays in that state indefinitely.

The problem occurs with any version of qemu 6.x I do not use versions 5.x and the problem occurs anyway. On different clusters and with different storage systems, in the same way. Strangely I have never and again never had any problems with Windows 2008r2.

Yes it is a big problem. Some time ago we opened some official tickets to Proxmox, but it all faded into a ... "we can't replicate the problem" "try using the 5.15 kernel" "try using qemu 6.2". No deterministic answer.

... and now with the release of Proxmox 7.2 the problem that has lasted more than 5 months will be solved? I really hope so...

mmm it seems like a different problem ....

I wish it were so, but it has been too little time since the release of qemu 6.2 in Proxmox. If the problem does not show up at the next Windows update in May, then yes it can be said to be solved. However ... Until qemu 6.2 is released in the enterprise branch many clusters will not use it. It...

it wouldn't even be useful as a workaround ... imagine a 9 node cluster with 300 Windows 2012 or higher VMs stuck ... One thing I am wondering that has been little covered in this thread and that COULD be useful to understand better. Why does the problem NOT occur with 2008r2?