Windows 11 boot stucks on PVE 9.1 with x86_64-v2-AES

[m-electronics]

Hi to the proxmox community,

I have updated my proxmox node from 8.4.14 to 9.1.2 and want to start a Windows 11 VM that I had installed before the update.

It stucks in the boot process now (after the update) and I didn´t change anything in the configuration of this VM...
With cputype=host it works. But I think there is something like a bug or something like this...

 

[Sviat]

Hi,

It can be related to QEMU version (v9 vs v10).
When Intel/AMD publish updated CPUID definitions, QEMU updates its CPU models to match real hardware and most likely you have some of the old CPU type configured.
What CPU do you have on your node and what was configured for the VM before the update?
Did you have a chance to use one of the modern CPU types like x86-64-v4?

 

[m-electronics]

Hi,

It can be related to QEMU version (v9 vs v10).
When Intel/AMD publish updated CPUID definitions, QEMU updates its CPU models to match real hardware and most likely you have some of the old CPU type configured.
What CPU do you have on your node and what was configured for the VM before the update?
Did you have a chance to use one of the modern CPU types like x86-64-v4?

Hey Sivat,

Sorry for the long reply time (silvester and new year are not good in my family for doing IT things...)

My node have an Intel i5-8279U CPU and I do not touch any configuration of the VM.

I have tested x86-64-v4, there I got failure messages for missing CPU features and then I tested x86-64-v3, there is the same boot stuck error as with x86-64-v2-AES (how I described in the first post)

 

[m-electronics]

I have played around a little bit now and I use Q35 for the machine type...
And when I use:
CPU Type: x86-64-v2-AES
Machine Type: Q35-10.0

it works.

But I want to understand what is the problem

 

[Sviat]

Hi @m-electronics,

happy NY!
The family is always in higher priority, you can't move the moment back or roll it back from backup)
The problem here that when you keep the configuration unchanged after the update you can have the old VM hardware version and CPU type that is could be not fully supported by a new qemu version.
Qemu deprecating some old options and features mostly every release, so this workflow can be expected .