From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 55CB61FF0E0 for ; Thu, 09 Jul 2026 16:31:19 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 235C9214A4; Thu, 09 Jul 2026 16:31:19 +0200 (CEST) Message-ID: Date: Thu, 9 Jul 2026 16:30:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH manager 1/1] ui: processor edit: allow setting 8 sockets To: Maximiliano Sandoval , pve-devel@lists.proxmox.com References: <20260706114719.340123-1-m.sandoval@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: <20260706114719.340123-1-m.sandoval@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1783607434096 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.073 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) 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: 2VOPWUH6XRBSWEI5RW7HNHXV5A4UYJYE X-Message-ID-Hash: 2VOPWUH6XRBSWEI5RW7HNHXV5A4UYJYE X-MailFrom: d.csapak@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: if the backend does not have an upper limit, shouldn't we use the same behavior in the frontend? AFAICS two issues arise by having a lower value here than the backend: * we have to raise this (probably) again in the future * a config with a higher value cannot be edited in the gui (because it get's invalid) So i'd prefer just to remove the maxValue here completely. If there is any detrimental effect when having to much sockets configured, we could add a warning e.g. when the sockets is > 8. On 7/6/26 1:47 PM, Maximiliano Sandoval wrote: > As per our NUMA documentation [1]: > >> If the NUMA option is used, it is recommended to set the number of sockets to >> the number of nodes of the host system. > > Nowadays, it is common to find CPU models with 8 NUMA nodes. Two examples are > Xeon Platinum 8160 and EPYC 73F3. > > The schema at qemu-server does not limit the socket amount. However, $MAX_NUMA > is hard-coded to 8 at qemu-server's Memory.pm , so we bump it to 8 to be on the > safe side. > > [1] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_numa > > Signed-off-by: Maximiliano Sandoval > --- > > Notes: > Differences from v1: > - Set the maxValue to 8 > > www/manager6/qemu/ProcessorEdit.js | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/www/manager6/qemu/ProcessorEdit.js b/www/manager6/qemu/ProcessorEdit.js > index 719f771a7..1afc1fd78 100644 > --- a/www/manager6/qemu/ProcessorEdit.js > +++ b/www/manager6/qemu/ProcessorEdit.js > @@ -129,7 +129,7 @@ Ext.define('PVE.qemu.ProcessorInputPanel', { > xtype: 'proxmoxintegerfield', > name: 'sockets', > minValue: 1, > - maxValue: 4, > + maxValue: 8, > value: '1', > fieldLabel: gettext('Sockets'), > allowBlank: false,