UUID lost after changing machine type

[JensF]

Yesterday I updated our server to the latest software versions (Kernel 6.5 included) and changed the machine type of our Windows servers from q35-8.0 to q35-8.1.
After that it seemed everything is working as always. But our Veeam backup failed at night with "Processing <Server> Error: Machine doesn't have identifiers".
Checked on every server in a Powershell window with: get-wmiobject win32_computersystemproduct | Select-Object -expandProperty UUID and yes, every server without an EFI start have now an empty UUID. No problems with Windows with EFI start btw.
It helps to change the machine type back to 8.0. So there is a problem in q35-8.1!

proxmox-ve: 8.0.2 (running kernel: 6.5.11-3-pve)
pve-manager: 8.0.9 (running version: 8.0.9/fd1a0ae1b385cdcd)
pve-kernel-6.2: 8.0.5
proxmox-kernel-helper: 8.0.5
proxmox-kernel-6.5: 6.5.11-3
proxmox-kernel-6.5.11-3-pve: 6.5.11-3
proxmox-kernel-6.2.16-19-pve: 6.2.16-19
proxmox-kernel-6.2: 6.2.16-19
proxmox-kernel-6.2.16-18-pve: 6.2.16-18
pve-kernel-6.2.16-3-pve: 6.2.16-3
ceph-fuse: 17.2.6-pve1+3
corosync: 3.1.7-pve3
criu: 3.17.1-2
glusterfs-client: 10.3-5
ifupdown2: 3.2.0-1+pmx7
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-4
libknet1: 1.28-pve1
libproxmox-acme-perl: 1.5.0
libproxmox-backup-qemu0: 1.4.0
libproxmox-rs-perl: 0.3.1
libpve-access-control: 8.0.7
libpve-apiclient-perl: 3.3.1
libpve-common-perl: 8.0.10
libpve-guest-common-perl: 5.0.5
libpve-http-server-perl: 5.0.5
libpve-rs-perl: 0.8.7
libpve-storage-perl: 8.0.4
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 5.0.2-4
lxcfs: 5.0.3-pve3
novnc-pve: 1.4.0-3
proxmox-backup-client: 3.0.4-1
proxmox-backup-file-restore: 3.0.4-1
proxmox-kernel-helper: 8.0.5
proxmox-mail-forward: 0.2.1
proxmox-mini-journalreader: 1.4.0
proxmox-widget-toolkit: 4.1.1
pve-cluster: 8.0.5
pve-container: 5.0.6
pve-docs: 8.0.5
pve-edk2-firmware: 4.2023.08-1
pve-firewall: 5.0.3
pve-firmware: 3.9-1
pve-ha-manager: 4.0.3
pve-i18n: 3.0.7
pve-qemu-kvm: 8.1.2-3
pve-xtermjs: 5.3.0-2
qemu-server: 8.0.8
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.2.0-pve3

 

[leesteken]

It's known that Windows does not like changing the machine type or version. That's why it is fixated upon creation by recent versions of Proxmox, when OS Type is set to Windows. Looks like your VM was (still or accidentally) set to automatically use the latest machine version, but you fixed this now.

 

[JensF]

This is not a Windows problem! I just installed a Windows 10 test machine with q35-8.1 in BIOS mode and the UUID is also empty.
Config of the test machine:

agent: 1
boot: order=sata0
cores: 2
cpu: host
machine: pc-q35-8.1
memory: 4092
meta: creation-qemu=8.1.2,ctime=1700735316
name: W10-Test-8.1
numa: 0
ostype: win10
sata0: PM1735:vm-109-disk-0,discard=on,size=320G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=a56560ec-822f-400d-adc1-53f631158b0e
sockets: 1
vmgenid: b252ab56-1010-4515-9353-02c90cfff4d3

 

[JensF]

After all updates from today the problem still persists.

proxmox-ve: 8.1.0 (running kernel: 6.5.11-4-pve)
pve-manager: 8.1.3 (running version: 8.1.3/b46aac3b42da5d15)
proxmox-kernel-helper: 8.0.9
pve-kernel-6.2: 8.0.5
proxmox-kernel-6.5.11-4-pve-signed: 6.5.11-4
proxmox-kernel-6.5: 6.5.11-4
proxmox-kernel-6.5.11-3-pve: 6.5.11-3
proxmox-kernel-6.2.16-19-pve: 6.2.16-19
proxmox-kernel-6.2: 6.2.16-19
pve-kernel-6.2.16-3-pve: 6.2.16-3
ceph-fuse: 17.2.6-pve1+3
corosync: 3.1.7-pve3
criu: 3.17.1-2
glusterfs-client: 10.3-5
ifupdown2: 3.2.0-1+pmx7
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-4
libknet1: 1.28-pve1
libproxmox-acme-perl: 1.5.0
libproxmox-backup-qemu0: 1.4.0
libproxmox-rs-perl: 0.3.1
libpve-access-control: 8.0.7
libpve-apiclient-perl: 3.3.1
libpve-common-perl: 8.1.0
libpve-guest-common-perl: 5.0.6
libpve-http-server-perl: 5.0.5
libpve-network-perl: 0.9.4
libpve-rs-perl: 0.8.7
libpve-storage-perl: 8.0.5
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 5.0.2-4
lxcfs: 5.0.3-pve3
novnc-pve: 1.4.0-3
proxmox-backup-client: 3.0.4-1
proxmox-backup-file-restore: 3.0.4-1
proxmox-kernel-helper: 8.0.9
proxmox-mail-forward: 0.2.2
proxmox-mini-journalreader: 1.4.0
proxmox-widget-toolkit: 4.1.3
pve-cluster: 8.0.5
pve-container: 5.0.8
pve-docs: 8.1.3
pve-edk2-firmware: 4.2023.08-1
pve-firewall: 5.0.3
pve-firmware: 3.9-1
pve-ha-manager: 4.0.3
pve-i18n: 3.1.2
pve-qemu-kvm: 8.1.2-4
pve-xtermjs: 5.3.0-2
qemu-server: 8.0.10
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.2.0-pve3

 

[Martin Gibson]

Had the same issue with Veeam backup.
If you drop back to 8.0 the UUID is visible again.

 

[Jorge Teixeira]

After all updates from today the problem still persists.

proxmox-ve: 8.1.0 (running kernel: 6.5.11-4-pve)
pve-manager: 8.1.3 (running version: 8.1.3/b46aac3b42da5d15)
proxmox-kernel-helper: 8.0.9
pve-kernel-6.2: 8.0.5
proxmox-kernel-6.5.11-4-pve-signed: 6.5.11-4
proxmox-kernel-6.5: 6.5.11-4
proxmox-kernel-6.5.11-3-pve: 6.5.11-3
proxmox-kernel-6.2.16-19-pve: 6.2.16-19
proxmox-kernel-6.2: 6.2.16-19
pve-kernel-6.2.16-3-pve: 6.2.16-3
ceph-fuse: 17.2.6-pve1+3
corosync: 3.1.7-pve3
criu: 3.17.1-2
glusterfs-client: 10.3-5
ifupdown2: 3.2.0-1+pmx7
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-4
libknet1: 1.28-pve1
libproxmox-acme-perl: 1.5.0
libproxmox-backup-qemu0: 1.4.0
libproxmox-rs-perl: 0.3.1
libpve-access-control: 8.0.7
libpve-apiclient-perl: 3.3.1
libpve-common-perl: 8.1.0
libpve-guest-common-perl: 5.0.6
libpve-http-server-perl: 5.0.5
libpve-network-perl: 0.9.4
libpve-rs-perl: 0.8.7
libpve-storage-perl: 8.0.5
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 5.0.2-4
lxcfs: 5.0.3-pve3
novnc-pve: 1.4.0-3
proxmox-backup-client: 3.0.4-1
proxmox-backup-file-restore: 3.0.4-1
proxmox-kernel-helper: 8.0.9
proxmox-mail-forward: 0.2.2
proxmox-mini-journalreader: 1.4.0
proxmox-widget-toolkit: 4.1.3
pve-cluster: 8.0.5
pve-container: 5.0.8
pve-docs: 8.1.3
pve-edk2-firmware: 4.2023.08-1
pve-firewall: 5.0.3
pve-firmware: 3.9-1
pve-ha-manager: 4.0.3
pve-i18n: 3.1.2
pve-qemu-kvm: 8.1.2-4
pve-xtermjs: 5.3.0-2
qemu-server: 8.0.10
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.2.0-pve3

I have a similar problem with an accounting software shared with RDP on a windows server 2022 vm. If i set the machine to 8.1 version, i loose the software license and cannot use it anymore even after setting it back to 8. Have to restore from backup to solve the issue. I always have updated to the latest version with no problems. The actual version is 8. With the version set to 8.1, the accounting software sends a message saying that it "cannot be used with this computer". In my case i use i440fx but changing to q35 does the same thing.

UPDATE: converting the windows VM to UEFI boot solve the problem but there is a problem with 8.1 version and legacy boot.

 

[JensF]

UPDATE: converting the windows VM to UEFI boot solve the problem but there is a problem with 8.1 version and legacy boot.

This is what I wrote in my first thread message. I'll not convert all my Windows machines to EFI boot...
Switch back to 8.0 is the workaround I used ofc.

 

[fiona]

Hi,
there's a reason why the machine version is pinned for Windows. There can always be issues when changing it, see the documentation (section Machine Version): https://pve.proxmox.com/pve-docs/chapter-qm.html#qm_system_settings
There's also a note in the UI: Machine version change may affect hardware layout and settings in the guest OS.

The reason for the change is that QEMU switched to a new SMBIOS version by default, which uses 64 bit entry. Apparently, this trips up certain guest OSes.

This is not a Windows problem! I just installed a Windows 10 test machine with q35-8.1 in BIOS mode and the UUID is also empty.
Config of the test machine:

This on the other hand is a real issue. We'll ask upstream if they are aware that Windows is not comfortable with the new default and see what can be done about it. For now, the suggested workaround is to use OVMF/UEFI or set the machine version to 8.0 after creation.

EDIT: upstream discussion: https://lists.nongnu.org/archive/html/qemu-devel/2023-11/msg05751.html

 

[null-man]

glad i found this thread ... this was messing with the licensing of a virtual-appliance i use (no windows, but "unixoid") and using machine-version 8.0 fixed it. (UEFI does not boot with that appliance-OS)

However: how would i apply the "smbios-entry-point-type=32" workaround (from the upstream-discussion linked above).
It should go into the conf-file of the vm fore sure ;-), but couldn´t figure that out and the documentation does not show anything related to this.
Is it even possible with proxmox to use that machine-parameter?

EDIT: found it .. adding
args: -machine smbios-entry-point-type=32
to the VM-conf does the trick. Even if the process then shows 2 "machine" parameters:
...-machine type=pc+pve0 -machine smbios-entry-point-type=32...

but it seems to work fine.

 

[fiona]

Hi,

glad i found this thread ... this was messing with the licensing of a virtual-appliance i use (no windows, but "unixoid") and using machine-version 8.0 fixed it. (UEFI does not boot with that appliance-OS)

could you be more specific of what that OS/appliance is? That would help other users and might be relevant for upstream too.

 

[null-man]

Hi,

could you be more specific of what that OS/appliance is? That would help other users and might be relevant for upstream too.

I would have already if i could (yet) ;-)
There are reasons for that - but I will be talking to the correct vendor people about that soon and let them investigate.
In case something can be shared later, I will do so.

 

[the-last-englishman]

Wow, just found this post, my windows servers which are cloned from template were all missing UUID, the fix args: -machine smbios-entry-point-type=32 , and my UUID for the VM's are now visible.. Thanks