From: Manuel Federanko <m.federanko@proxmox.com>
To: Dominik Csapak <d.csapak@proxmox.com>, pve-devel@lists.proxmox.com
Subject: Re: [PATCH qemu-server v3] fix #5578: smbios: set serial number
Date: Tue, 7 Apr 2026 17:37:52 +0200 [thread overview]
Message-ID: <8136f97d-f372-46c3-98a9-f789cba7890c@proxmox.com> (raw)
In-Reply-To: <4bd31261-0287-49ab-9af5-e05334454075@proxmox.com>
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.
next prev parent reply other threads:[~2026-04-07 15:37 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 [this message]
2026-04-08 7:28 ` Dominik Csapak
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=8136f97d-f372-46c3-98a9-f789cba7890c@proxmox.com \
--to=m.federanko@proxmox.com \
--cc=d.csapak@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.