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 07C0D1FF0E7 for ; Fri, 10 Jul 2026 10:19:51 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 50239214DE; Fri, 10 Jul 2026 10:19:50 +0200 (CEST) Message-ID: <58aa3941-3f63-460a-99a8-c46e61b4a43d@proxmox.com> Date: Fri, 10 Jul 2026 10:19:15 +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 References: <20260706114719.340123-1-m.sandoval@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: 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: 1783671544744 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.062 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: U3CUJAD2F37RAGJ2Z6HBEBCJ7B5MZYOY X-Message-ID-Hash: U3CUJAD2F37RAGJ2Z6HBEBCJ7B5MZYOY 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 CC: pve-devel@lists.proxmox.com 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 7/10/26 10:06 AM, Maximiliano Sandoval wrote: > Dominik Csapak writes: > >> On 7/10/26 9:42 AM, Maximiliano Sandoval wrote: >>> Dominik Csapak writes: >>> >>>> if the backend does not have an upper limit, shouldn't we use the same >>>> behavior in the frontend? >>> We have a hardcoded limit of $MAX_NUMA = 8 in qemu-server's Memory.pm as >>> mentioned by Alexandre in a reply to v1. I opted to be on the safer side >>> without redoing the entire numa handling. >>> At the moment there are systems with 8 sockets and at least one customer >>> asked for this in enterprise support. >>> >> >> but this is only tangentially related to the socket amount? >> >> i can boot a vm with e.g. 16 sockets + numa 1 boot perfectly fine? > > In this case it is not possible to define numa policies via --numa0, > ..., --numa15 (they stop at --numa7). yes i get that, but this is an option that is 1. not exposed on the ui at all 2. has nothing to do with the number of sockets (inherently) for example: i can configure: sockets: 16 cores: 1 numa: 1 memory: 1024 numa0: cpus=0-7,memory=512 numa1: cpus=8-15,memory=512 and have 16 sockets but only 2 numa nodes... > > When discussing this off-list with Fiona we decided to be on the safer > side, the number can be bumped again once 16 socket CPUs are more > common. this "breaks" the UI when a user sets higher values manually, as in, one cannot set any other option as long as the sockets are higher so im very much in favor of removing the maxValue at all... > >>>> 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. >>> >