From: Dominik Csapak <d.csapak@proxmox.com>
To: Manuel Federanko <m.federanko@proxmox.com>, pve-devel@lists.proxmox.com
Subject: Re: [PATCH qemu-server v3] fix #5578: smbios: set serial number
Date: Wed, 8 Apr 2026 09:28:57 +0200 [thread overview]
Message-ID: <13daa754-92c2-4320-80dd-5347135dad26@proxmox.com> (raw)
In-Reply-To: <8136f97d-f372-46c3-98a9-f789cba7890c@proxmox.com>
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.
next prev parent reply other threads:[~2026-04-08 7:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-03 10:49 Manuel Federanko
2026-04-07 13:27 ` Dominik Csapak
2026-04-07 15:37 ` Manuel Federanko
2026-04-08 7:28 ` Dominik Csapak [this message]
2026-04-08 8:23 ` Manuel Federanko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=13daa754-92c2-4320-80dd-5347135dad26@proxmox.com \
--to=d.csapak@proxmox.com \
--cc=m.federanko@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox