From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 0C5B01FF13B for ; Wed, 08 Apr 2026 10:23:27 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id D569D38A2; Wed, 8 Apr 2026 10:24:01 +0200 (CEST) Message-ID: Date: Wed, 8 Apr 2026 10:23:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Manuel Federanko Subject: Re: [PATCH qemu-server v3] fix #5578: smbios: set serial number To: Dominik Csapak , pve-devel@lists.proxmox.com References: <20260303104919.33634-1-m.federanko@proxmox.com> <4bd31261-0287-49ab-9af5-e05334454075@proxmox.com> <8136f97d-f372-46c3-98a9-f789cba7890c@proxmox.com> <13daa754-92c2-4320-80dd-5347135dad26@proxmox.com> Content-Language: en-US In-Reply-To: <13daa754-92c2-4320-80dd-5347135dad26@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1775636568776 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.873 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: 4DKV5JI6TNBBLQVHVMFY2DDWXUZGHPXL X-Message-ID-Hash: 4DKV5JI6TNBBLQVHVMFY2DDWXUZGHPXL X-MailFrom: m.federanko@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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. >