Fixing Missing SMBIOS UUID in Windows VMs on KVM/QEMU 8.1+

Overview

After upgrading to QEMU 8.1 or newer, Windows virtual machines running on KVM/libvirt may no longer expose their SMBIOS UUID to the guest operating system. As a result, Windows WMI queries return no UUID.

This issue directly affects software that depends on a stable system UUID, including:

• Veeam Backup and Replication

• Veeam Service Provider Console (VSPC)

• Veeam Agents

• SQL-backed applications that bind configuration or licensing to UUID

• Certain Windows activation and hardware identification workflows

This is not a SQL corruption issue and not a Veeam defect. It is caused by a hypervisor-level SMBIOS behavior change.

Symptoms

Inside the affected Windows VM, the following commands return empty results or No Instance(s) Available.

PowerShell

(Get-CimInstance Win32_ComputerSystemProduct).UUID
Get-CimInstance Win32_ComputerSystemProduct | Select-Object UUID

Command Prompt

wmic csproduct get uuid

Typical output:

No Instance(s) Available.

In Veeam environments, this commonly appears as:

• Veeam services failing to rebind after hostname changes

• SQL-backed Veeam components failing initialization

• Duplicate or missing server identities in VSPC

• Agent registration or licensing failures

Affected Environment

• Hypervisor: KVM with libvirt

• QEMU: 8.1 and newer (8.2.x confirmed)

• Guest OS: Windows Server 2019, Windows Server 2022, Windows 10, Windows 11

• Firmware: Legacy BIOS (non-UEFI)

• Platforms: OpenStack, Proxmox, standalone libvirt

Root Cause

Starting with QEMU 8.1, the default SMBIOS entry point type changed.

QEMU Version	SMBIOS Entry Point
8.0 and earlier	32-bit (legacy)
8.1 to 8.2	64-bit
9.0 and newer	auto

Windows guests booted in legacy BIOS mode cannot read the 64-bit SMBIOS entry point, even though the SMBIOS tables are correctly populated by QEMU.

As a result:

• The UUID exists at the hypervisor level

• Windows cannot locate the SMBIOS entry point

• WMI returns no UUID

Hypervisor Verification

The UUID is present in the VM definition.

virsh dumpxml <vm-name> | grep -A15 '<sysinfo'

Example:

<sysinfo type='smbios'>
  <system>
    <entry name='manufacturer'>OpenStack Foundation</entry>
    <entry name='product'>OpenStack Nova</entry>
    <entry name='uuid'>99ebd0f3-493b-4890-b3ce-895d0f4df819</entry>
  </system>
</sysinfo>

The data exists, but Windows cannot read it due to the SMBIOS entry point format.

Supported Fix

Force QEMU to use the legacy 32-bit SMBIOS entry point.

Required QEMU Argument

-machine smbios-entry-point-type=32

This immediately restores UUID visibility inside Windows.

Fix Options

Option 1: Single VM (Manual, Temporary)

1. Stop the VM completely:

openstack server stop <server-id>

2. Export the libvirt XML:

virsh dumpxml <vm-name> > /tmp/vm.xml

3. Add the QEMU namespace to the <domain> tag:

<domain type="kvm" xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0">

4. Add the following block before </domain>:

<qemu:commandline>
  <qemu:arg value="-machine"/>
  <qemu:arg value="smbios-entry-point-type=32"/>
</qemu:commandline>

5. Redefine and start the VM:

virsh undefine <vm-name>
virsh define /tmp/vm.xml
virsh start <vm-name>

6. Verify inside Windows:

(Get-CimInstance Win32_ComputerSystemProduct).UUID

Option 2: Global Fix (Recommended)

Because platforms such as OpenStack regenerate VM XML on each start, the correct long-term solution is a libvirt QEMU hook on every compute node.

Create the file /etc/libvirt/hooks/qemu:

#!/bin/bash

GUEST_NAME=$1
OPERATION=$2

if [ "$OPERATION" = "prepare" ]; then
    cat > /tmp/libvirt-hook-$$.xml

    if ! grep -q "smbios-entry-point-type" /tmp/libvirt-hook-$$.xml; then
        if grep -q "xmlns:qemu" /tmp/libvirt-hook-$$.xml; then
            sed -i 's|</domain>|<qemu:commandline><qemu:arg value="-machine"/><qemu:arg value="smbios-entry-point-type=32"/></qemu:commandline></domain>|' /tmp/libvirt-hook-$$.xml
        else
            sed -i 's|<domain type="kvm">|<domain type="kvm" xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0">|' /tmp/libvirt-hook-$$.xml
            sed -i 's|</domain>|<qemu:commandline><qemu:arg value="-machine"/><qemu:arg value="smbios-entry-point-type=32"/></qemu:commandline></domain>|' /tmp/libvirt-hook-$$.xml
        fi
    fi

    cat /tmp/libvirt-hook-$$.xml
    rm -f /tmp/libvirt-hook-$$.xml
else
    cat
fi

Make it executable:

chmod +x /etc/libvirt/hooks/qemu

Deploy this hook on every compute node.

Verification

Hypervisor

ps aux | grep smbios-entry-point-type

Expected output:

smbios-entry-point-type=32

Windows

wmic csproduct get uuid

Expected output:

99EBD0F3-493B-4890-B3CE-895D0F4DF819

Alternatives

Use UEFI (OVMF)

UEFI-based Windows VMs properly support 64-bit SMBIOS entry points and are not affected.

Upgrade to QEMU 9.0 or Newer

QEMU 9 defaults SMBIOS entry point handling to auto, which resolves the issue in most environments.

Summary

While we think Veeam Service Provider Console is broken it ends up being the UUID not letting SQL run properly and VSCP stays in limbo. Once you can see the UUID while the Windows OS runs in OpenStack (Ubuntu + KVM + Kolla) it just works.

Item	Outcome
Root cause	QEMU 8.1 defaulted to 64-bit SMBIOS
Affected systems	Windows VMs using legacy BIOS
Veeam impact	UUID missing, SQL and service rebinding failures
Fix	Force 32-bit SMBIOS entry point
Best practice	Global libvirt QEMU hook