From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 60C13C13BC for ; Mon, 15 Jan 2024 12:46:51 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 302EF1A5DE for ; Mon, 15 Jan 2024 12:46:21 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Mon, 15 Jan 2024 12:46:20 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id E4B05490CC; Mon, 15 Jan 2024 12:46:19 +0100 (CET) Message-ID: <9c1ce32e-e54d-460d-81e4-8e4829853b24@proxmox.com> Date: Mon, 15 Jan 2024 12:46:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta To: Proxmox VE development discussion , Alexandre Derumier References: <20240112200806.309336-1-aderumier@odiso.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: <20240112200806.309336-1-aderumier@odiso.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.020 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 SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH pve-manager] qemu: bump max cores to 256 by socket X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2024 11:46:51 -0000 On 1/12/24 21:08, Alexandre Derumier wrote: > New epyc cpu already support 168 threads > > qemu 8.1 support 1024 cores with q35 > --- > 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 b845ff66..b3538727 100644 > --- a/www/manager6/qemu/ProcessorEdit.js > +++ b/www/manager6/qemu/ProcessorEdit.js > @@ -125,7 +125,7 @@ Ext.define('PVE.qemu.ProcessorInputPanel', { > xtype: 'proxmoxintegerfield', > name: 'cores', > minValue: 1, > - maxValue: 128, > + maxValue: 256, > value: '1', > fieldLabel: gettext('Cores'), > allowBlank: false, mhmm.. in the backend we don't actually have a limit, maybe it's time to remove the limit in the ui altogether? it does not help anyway: for numbers that are not too big (too many for qemu, too many for the host) it's not the right limit (qemu) or we don't know at that point in the gui (host cores) but in case next year there is e.g. a 512 core machine, the limit is too low again... so i'd be either for * removing the limit at all * limit to the qemu limits (but maybe also in the backend?) * use the number of cores of the current host as limit in the gui (should be possible, but an additional api call) what do you think?