[SOLVED] Windows Server guest - QEMU Machine version settings (locked to version)

[hans-olav]

Hi

We are running proxmox pve clusters on version 7.2 / 7.3 on different sites.
As stated in the roadmap/changelog from version 6.4 @ https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_6.4 :

Virtual Machines (KVM/QEMU):

• Support pinning a VM to a specific QEMU machine version.
• Automatically pin VMs with Windows as OS type to the current QEMU machine on VM creation.

This improves stability and guarantees that the hardware layout can stay the same even with newer QEMU versions.

We are having a lot of windows VMs still pinned to QEMU machine version 5.1 (and some other variations of 5.2 and 6.1).

From what i understand, it is still recommended to keep the setting pinned to a machine version for Windows VMs, but I am not finding any recommendations on actually pushing for a controlled change of this setting to a newer machine version during the lifecycle of the VM.
Is this setting only controlling some compability flags kept to make the VM think the hardware is unchanged, or do we miss out on all improvements and fixes in later QEMU releases by not taking actions to keep up with newer machine versions?

(we are currently experiencing some VirtioScsi warnings in eventlog followed by an unexpected reboot 30 minutes later on a few VMs that have the setting set to machine version 6.1. I am not changing the machine version yet - will first upgrade the virtio drivers to the jan 2023 release to see if it has an effect - but i was curios about this setting, and if it will impact the virtioscsi in any way by not updating the setting to the newest compability level when updating the drivers)

 

[t.lamprecht]

Hi,

From what i understand, it is still recommended to keep the setting pinned to a machine version for Windows VMs, but I am not finding any recommendations on actually pushing for a controlled change of this setting to a newer machine version during the lifecycle of the VM.

Normally you shouldn't need changing those.

Is this setting only controlling some compability flags kept to make the VM think the hardware is unchanged, or do we miss out on all improvements and fixes in later QEMU releases by not taking actions to keep up with newer machine versions?

It's core use is for compatibility, i.e., to expose HW and the, e.g., PCI/ACPI locations of that HW, as close as possible to the VM like it was when the OS got installed. So you will always profit from all security and almost all bug and performance fixes of newer QEMU versions in general.

Proxmox VE additionally uses it to feature gate some higher level stuff in a backward compatible manner (i.e., to not break live-migration or rollback to a snapshot that includes the running memory state). But this may not warrant adapting the pinning for Windows on its own, as it can still cause confusion for Windows quite inflexible handling of change. IIRC, the issue that triggered this was a correction in QEMU for how the virtual device ACPI layout was set out, as it wrongly started to cound ad 1 instead of 0 as address, Linux didn't bother much, but Windows seemingly used that info to map the device to drivers or what not, and thus an admin would require to reinstall the drivers (or run some "repair" thingy in the device manager - it's been quite some time, so details are a bit fuzzy). So, while it was repairable, and did not even require in-depth experience to do so, it was seen as blocker to roll out an update that "kills" network for all windows default, even if it was repairable.

In any case, we recommend testing a change to the version pinning for Windows based VMs on a (network isolated) clone of your production VM to see if the OS version can cope with the newer machine artifacts without any extra change required.
If it doesn't work out 1:1, it may do so after (re)installing the newest VirtIO drivers for the virtual HW. If you evaluate the steps required for the new pinning (those with 5.2+ pinning may not even need any for 7.x) of the Windows VMs you use, you might take a slight feature profit (e.g., USB hot-plugging got added recently for newer machines IIRC) from updating the older ones in a planned maintenance window with some target device repairs.

 

[hans-olav]

Thanks for a good explanation.

We are hosting somewhere between 50-100 windows VMs, so the increase in version setting will not be a task we are rushing to get done, it was just good getting some background that supports this decision. Will just move forward with VirtIO drivers upgrade for now.