[PATCH qemu-server v3] fix #5578: smbios: set serial number

[PATCH qemu-server v3] fix #5578: smbios: set serial number

[Manuel Federanko]

If no smbios options are given on creation, default to generate a serial
number. This is required for Windows Autopilot to identify a user
device.
Use the already generated smbios uuid as serial number, it should be
unique enough for our purposes.

The base64 here is needed since all configuration options are stored as
a base64 encoded string, which is ensured by the format. This ensures
that the values are properly decoded in the gui, for example.

Since all fields are forced to be stored in base64 format it might make
sense for a future patch to a) remove the flag or b) allow values
different than base64 encoded data in the other fields.

Tested by creating a new vm via the gui and command line.

Signed-off-by: Manuel Federanko <m.federanko@proxmox.com>
---
Changes since v2:
* add "PVE-" prefix to serial
* move logic back into a helper subroutine
Changes since v1:
* switch serial to be the same uuid
* use print_smbios1 over manually constructing strings
* remove the dedicated generate_smbios1_uuid subroutine

 src/PVE/API2/Qemu.pm  |  2 +-
 src/PVE/CLI/qm.pm     |  2 +-
 src/PVE/QemuServer.pm | 10 ++++++++--
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/src/PVE/API2/Qemu.pm b/src/PVE/API2/Qemu.pm
index c2e185a6..a68b1906 100644
--- a/src/PVE/API2/Qemu.pm
+++ b/src/PVE/API2/Qemu.pm
@@ -1471,7 +1471,7 @@ __PACKAGE__->register_method({
 
                     # auto generate uuid if user did not specify smbios1 option
                     if (!$conf->{smbios1}) {
-                        $conf->{smbios1} = PVE::QemuServer::generate_smbios1_uuid();
+                        $conf->{smbios1} = PVE::QemuServer::generate_smbios1();
                     }
 
                     if (
diff --git a/src/PVE/CLI/qm.pm b/src/PVE/CLI/qm.pm
index bdae9641..975ec3f5 100755
--- a/src/PVE/CLI/qm.pm
+++ b/src/PVE/CLI/qm.pm
@@ -912,7 +912,7 @@ __PACKAGE__->register_method({
         eval {
             # order matters, as do_import() will load_config() internally
             $conf->{vmgenid} = PVE::QemuServer::generate_uuid();
-            $conf->{smbios1} = PVE::QemuServer::generate_smbios1_uuid();
+            $conf->{smbios1} = PVE::QemuServer::generate_smbios1();
             PVE::QemuConfig->write_config($vmid, $conf);
 
             foreach my $disk (@{ $parsed->{disks} }) {
diff --git a/src/PVE/QemuServer.pm b/src/PVE/QemuServer.pm
index 545758dc..77dd7cca 100644
--- a/src/PVE/QemuServer.pm
+++ b/src/PVE/QemuServer.pm
@@ -8082,8 +8082,14 @@ sub generate_uuid {
     return $uuid_str;
 }
 
-sub generate_smbios1_uuid {
-    return "uuid=" . generate_uuid();
+sub generate_smbios1 {
+    my $smbios1_uuid = PVE::QemuServer::generate_uuid();
+    my $smbios1 = {
+        uuid => $smbios1_uuid,
+        serial => encode_base64("PVE-" . $smbios1_uuid, ""),
+        base64 => 1,
+    };
+    return PVE::QemuServer::print_smbios1($smbios1);
 }
 
 sub create_reboot_request {
-- 
2.47.3

Re: [PATCH qemu-server v3] fix #5578: smbios: set serial number

[Dominik Csapak]

not sure if it was discussed off-list, but you didn't really
address fionas comment about just adding this conditionally,
e.g. via ostype or machine version

this will increase the config size by a bit and i guess
most guest operating systems don't gain much from this?

i'm guilty of adding such flags unconditionally myself in the past
(see vmgenid) but i think we should avoid that when possible

e.g. an empty config (qm create ID)
looks like this currently:

```
boot:
meta: creation-qemu=10.2.1,ctime=1775568119
smbios1: uuid=a0f6c957-1c8b-439f-b25a-1e45dc151263
vmgenid: 0ed5ca0d-0e72-4c1a-b62f-ad2f7aaa8819
```

with your patch it looks like this:

```
boot:
meta: creation-qemu=10.2.1,ctime=1775568283
smbios1: 
base64=1,serial=UFZFLWM5OTY3ZDQwLTVlZTUtNDQ1My1hZDI0LTljZWUzODJmZTg1ZA==,uuid=c9967d40-5ee5-4453-ad24-9cee382fe85d
vmgenid: 1c7fe857-3520-4a20-8e09-611a7fb1be3b
```

which is quite a bit of noise.

If you think it's worthwhile to have a serial number for every guest,
we could e.g. still give it to qemus commandline if it's
missing in the config (especially if it's the same as the
normal uuid, but prefixed with PVE-)
IMHO it makes no sense having the same uuid twice in the config.

if someone sets a serial manually, we should use that of course.

sorry if any of these were discussed already, i checked the m-l
but didn't find any discussion regarding this.


On 3/3/26 11:49 AM, Manuel Federanko wrote:
> If no smbios options are given on creation, default to generate a serial
> number. This is required for Windows Autopilot to identify a user
> device.
> Use the already generated smbios uuid as serial number, it should be
> unique enough for our purposes.
> 
> The base64 here is needed since all configuration options are stored as
> a base64 encoded string, which is ensured by the format. This ensures
> that the values are properly decoded in the gui, for example.
> 
> Since all fields are forced to be stored in base64 format it might make
> sense for a future patch to a) remove the flag or b) allow values
> different than base64 encoded data in the other fields.
> 
> Tested by creating a new vm via the gui and command line.
> 
> Signed-off-by: Manuel Federanko <m.federanko@proxmox.com>
> ---
> Changes since v2:
> * add "PVE-" prefix to serial
> * move logic back into a helper subroutine
> Changes since v1:
> * switch serial to be the same uuid
> * use print_smbios1 over manually constructing strings
> * remove the dedicated generate_smbios1_uuid subroutine
> 
>   src/PVE/API2/Qemu.pm  |  2 +-
>   src/PVE/CLI/qm.pm     |  2 +-
>   src/PVE/QemuServer.pm | 10 ++++++++--
>   3 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/src/PVE/API2/Qemu.pm b/src/PVE/API2/Qemu.pm
> index c2e185a6..a68b1906 100644
> --- a/src/PVE/API2/Qemu.pm
> +++ b/src/PVE/API2/Qemu.pm
> @@ -1471,7 +1471,7 @@ __PACKAGE__->register_method({
>   
>                       # auto generate uuid if user did not specify smbios1 option
>                       if (!$conf->{smbios1}) {
> -                        $conf->{smbios1} = PVE::QemuServer::generate_smbios1_uuid();
> +                        $conf->{smbios1} = PVE::QemuServer::generate_smbios1();
>                       }
>   
>                       if (
> diff --git a/src/PVE/CLI/qm.pm b/src/PVE/CLI/qm.pm
> index bdae9641..975ec3f5 100755
> --- a/src/PVE/CLI/qm.pm
> +++ b/src/PVE/CLI/qm.pm
> @@ -912,7 +912,7 @@ __PACKAGE__->register_method({
>           eval {
>               # order matters, as do_import() will load_config() internally
>               $conf->{vmgenid} = PVE::QemuServer::generate_uuid();
> -            $conf->{smbios1} = PVE::QemuServer::generate_smbios1_uuid();
> +            $conf->{smbios1} = PVE::QemuServer::generate_smbios1();
>               PVE::QemuConfig->write_config($vmid, $conf);
>   
>               foreach my $disk (@{ $parsed->{disks} }) {
> diff --git a/src/PVE/QemuServer.pm b/src/PVE/QemuServer.pm
> index 545758dc..77dd7cca 100644
> --- a/src/PVE/QemuServer.pm
> +++ b/src/PVE/QemuServer.pm
> @@ -8082,8 +8082,14 @@ sub generate_uuid {
>       return $uuid_str;
>   }
>   
> -sub generate_smbios1_uuid {
> -    return "uuid=" . generate_uuid();
> +sub generate_smbios1 {
> +    my $smbios1_uuid = PVE::QemuServer::generate_uuid();
> +    my $smbios1 = {
> +        uuid => $smbios1_uuid,
> +        serial => encode_base64("PVE-" . $smbios1_uuid, ""),
> +        base64 => 1,
> +    };
> +    return PVE::QemuServer::print_smbios1($smbios1);
>   }
>   
>   sub create_reboot_request {

Re: [PATCH qemu-server v3] fix #5578: smbios: set serial number

[Manuel Federanko]

On 2026-04-07 3:26 PM, Dominik Csapak wrote:
> not sure if it was discussed off-list, but you didn't really
> address fionas comment about just adding this conditionally,
> e.g. via ostype or machine version
> 
> this will increase the config size by a bit and i guess
> most guest operating systems don't gain much from this?
> 
> i'm guilty of adding such flags unconditionally myself in the past
> (see vmgenid) but i think we should avoid that when possible
> 
> e.g. an empty config (qm create ID)
> looks like this currently:
> 
> ```
> boot:
> meta: creation-qemu=10.2.1,ctime=1775568119
> smbios1: uuid=a0f6c957-1c8b-439f-b25a-1e45dc151263
> vmgenid: 0ed5ca0d-0e72-4c1a-b62f-ad2f7aaa8819
> ```
> 
> with your patch it looks like this:
> 
> ```
> boot:
> meta: creation-qemu=10.2.1,ctime=1775568283
> smbios1: 
> base64=1,serial=UFZFLWM5OTY3ZDQwLTVlZTUtNDQ1My1hZDI0LTljZWUzODJmZTg1ZA==,uuid=c9967d40-5ee5-4453-ad24-9cee382fe85d
> vmgenid: 1c7fe857-3520-4a20-8e09-611a7fb1be3b
> ```
> 
> which is quite a bit of noise.

Agreed, I'm against magically setting this if we detect a specific OS,
since in theory any program on any OS can depend on the serial. Some
specific Microsoft software is the reason for this patch, but I would
be surprised if it is the only one.

> 
> If you think it's worthwhile to have a serial number for every guest,
> we could e.g. still give it to qemus commandline if it's
> missing in the config (especially if it's the same as the
> normal uuid, but prefixed with PVE-)
> IMHO it makes no sense having the same uuid twice in the config.
> 
> if someone sets a serial manually, we should use that of course.

That's a good idea - could there be a use-case of wanting the serial
to not be set? If that is not the case then I'd prefer this approach.

> sorry if any of these were discussed already, i checked the m-l
> but didn't find any discussion regarding this.
>
I'm not sure anymore tbh. I talked about this with Stoiko off-list,
but it might've only concerned the format/prefix of the serial.

Anyways thanks for the feedback.

Re: [PATCH qemu-server v3] fix #5578: smbios: set serial number

[Dominik Csapak]

On 4/7/26 5:36 PM, Manuel Federanko wrote:
> On 2026-04-07 3:26 PM, Dominik Csapak wrote:
>> not sure if it was discussed off-list, but you didn't really
>> address fionas comment about just adding this conditionally,
>> e.g. via ostype or machine version
>>
>> this will increase the config size by a bit and i guess
>> most guest operating systems don't gain much from this?
>>
>> i'm guilty of adding such flags unconditionally myself in the past
>> (see vmgenid) but i think we should avoid that when possible
>>
>> e.g. an empty config (qm create ID)
>> looks like this currently:
>>
>> ```
>> boot:
>> meta: creation-qemu=10.2.1,ctime=1775568119
>> smbios1: uuid=a0f6c957-1c8b-439f-b25a-1e45dc151263
>> vmgenid: 0ed5ca0d-0e72-4c1a-b62f-ad2f7aaa8819
>> ```
>>
>> with your patch it looks like this:
>>
>> ```
>> boot:
>> meta: creation-qemu=10.2.1,ctime=1775568283
>> smbios1:
>> base64=1,serial=UFZFLWM5OTY3ZDQwLTVlZTUtNDQ1My1hZDI0LTljZWUzODJmZTg1ZA==,uuid=c9967d40-5ee5-4453-ad24-9cee382fe85d
>> vmgenid: 1c7fe857-3520-4a20-8e09-611a7fb1be3b
>> ```
>>
>> which is quite a bit of noise.
> 
> Agreed, I'm against magically setting this if we detect a specific OS,
> since in theory any program on any OS can depend on the serial. Some
> specific Microsoft software is the reason for this patch, but I would
> be surprised if it is the only one.
> 
>>
>> If you think it's worthwhile to have a serial number for every guest,
>> we could e.g. still give it to qemus commandline if it's
>> missing in the config (especially if it's the same as the
>> normal uuid, but prefixed with PVE-)
>> IMHO it makes no sense having the same uuid twice in the config.
>>
>> if someone sets a serial manually, we should use that of course.
> 
> That's a good idea - could there be a use-case of wanting the serial
> to not be set? If that is not the case then I'd prefer this approach.

we probably cannot add it unconditionally, since that might trip up
live-migration (to be tested though). we could think about
guarding with a machine version, or using a special value as serial
(something like 'pve-auto') that gets replaced by the actual
"PVE-uuid' part. that would be shorter and we wouldn't duplicate
the uuid.

> 
>> sorry if any of these were discussed already, i checked the m-l
>> but didn't find any discussion regarding this.
>>
> I'm not sure anymore tbh. I talked about this with Stoiko off-list,
> but it might've only concerned the format/prefix of the serial.
> 
> Anyways thanks for the feedback.

Re: [PATCH qemu-server v3] fix #5578: smbios: set serial number

[Manuel Federanko]

On 2026-04-08 9:27 AM, Dominik Csapak wrote:
> 
> 
> On 4/7/26 5:36 PM, Manuel Federanko wrote:
>> On 2026-04-07 3:26 PM, Dominik Csapak wrote:
>>> not sure if it was discussed off-list, but you didn't really
>>> address fionas comment about just adding this conditionally,
>>> e.g. via ostype or machine version
>>>
>>> this will increase the config size by a bit and i guess
>>> most guest operating systems don't gain much from this?
>>>
>>> i'm guilty of adding such flags unconditionally myself in the past
>>> (see vmgenid) but i think we should avoid that when possible
>>>
>>> e.g. an empty config (qm create ID)
>>> looks like this currently:
>>>
>>> ```
>>> boot:
>>> meta: creation-qemu=10.2.1,ctime=1775568119
>>> smbios1: uuid=a0f6c957-1c8b-439f-b25a-1e45dc151263
>>> vmgenid: 0ed5ca0d-0e72-4c1a-b62f-ad2f7aaa8819
>>> ```
>>>
>>> with your patch it looks like this:
>>>
>>> ```
>>> boot:
>>> meta: creation-qemu=10.2.1,ctime=1775568283
>>> smbios1:
>>> base64=1,serial=UFZFLWM5OTY3ZDQwLTVlZTUtNDQ1My1hZDI0LTljZWUzODJmZTg1ZA==,uuid=c9967d40-5ee5-4453-ad24-9cee382fe85d
>>> vmgenid: 1c7fe857-3520-4a20-8e09-611a7fb1be3b
>>> ```
>>>
>>> which is quite a bit of noise.
>> 
>> Agreed, I'm against magically setting this if we detect a specific OS,
>> since in theory any program on any OS can depend on the serial. Some
>> specific Microsoft software is the reason for this patch, but I would
>> be surprised if it is the only one.
>> 
>>>
>>> If you think it's worthwhile to have a serial number for every guest,
>>> we could e.g. still give it to qemus commandline if it's
>>> missing in the config (especially if it's the same as the
>>> normal uuid, but prefixed with PVE-)
>>> IMHO it makes no sense having the same uuid twice in the config.
>>>
>>> if someone sets a serial manually, we should use that of course.
>> 
>> That's a good idea - could there be a use-case of wanting the serial
>> to not be set? If that is not the case then I'd prefer this approach.
> 
> we probably cannot add it unconditionally, since that might trip up
> live-migration (to be tested though). we could think about
> guarding with a machine version, or using a special value as serial
> (something like 'pve-auto') that gets replaced by the actual
> "PVE-uuid' part. that would be shorter and we wouldn't duplicate
> the uuid.

We just discussed this off-list.

Some options:

1. a marker as you mentioned, possibly only introduced when a new machine
  version is released
2. a new property "autogenerate smbios serial" to indicate if this should
  be generated
3. only generate this via the GUI per default, since the serial can be
  set via the cli anyways

>> 
>>> sorry if any of these were discussed already, i checked the m-l
>>> but didn't find any discussion regarding this.
>>>
>> I'm not sure anymore tbh. I talked about this with Stoiko off-list,
>> but it might've only concerned the format/prefix of the serial.
>> 
>> Anyways thanks for the feedback.
>