From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 1A0A21FF0AA for ; Tue, 22 Sep 2026 14:33:35 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id A085F214BF; Tue, 22 Sep 2026 14:33:30 +0200 (CEST) From: Nicolas Frey To: pve-devel@lists.proxmox.com Subject: [PATCH manager/storage 0/2] fix #6202: warn if sockets exceed target node Date: Tue, 22 Sep 2026 14:33:23 +0200 Message-ID: <20260922123325.498271-1-n.frey@proxmox.com> X-Mailer: git-send-email 2.47.3 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 1 AWL -0.952 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) KAM_LAZY_DOMAIN_SECURITY 1 Sending domain does not have any anti-forgery methods RDNS_NONE 1.274 Delivered to internal network by a host with no rDNS SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_NONE 0.001 SPF: sender does not publish an SPF Record Message-ID-Hash: Y6GGKDFGU3PQX2LGJMSBQERYCL4WCCMK X-Message-ID-Hash: Y6GGKDFGU3PQX2LGJMSBQERYCL4WCCMK X-MailFrom: nfrey@miso.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: and guard against division by zero in the import. The latter came up in enterprise support, which is only tangentially related to the original issue (but got me into fixing this issue in the first place). Tested using an ESXi VM with the entry 'cpuid.coresPerSocket' manually set to '0', which can normally only happen when it is set to "Assigned at power on" [0], i.e. the number of cores per socket is "optimally selected" by ESXi. Feedback on what to use as the nodeSocket heuristic would be great, the initial bug report suggests the # of sockets on the node, but if e.g. NUMA is enabled, then the # of CPU cores is the actual max for VM sockets. Or do we want to generally warn about the differences between how PVE and ESXi model CPU topology, regardless of the node's sockets? [0] https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/9-0/vsphere-resource-management/using-numa-systems-with-esxi/virtual-numa-controls.html pve-manager: Nicolas Frey (1): fix #6202: ui: guest import: warn if sockets exceed target node www/manager6/window/GuestImport.js | 33 ++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) pve-storage: Nicolas Frey (1): esxi: guard against zero 'cpuid.coresPerSocket' src/PVE/Storage/ESXiPlugin.pm | 8 ++++++++ 1 file changed, 8 insertions(+) Summary over all repositories: 2 files changed, 41 insertions(+), 0 deletions(-) -- Generated by murpp 0.12.1