From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id E45321FF133 for ; Mon, 11 May 2026 16:21:50 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 975AB1C7D2; Mon, 11 May 2026 16:21:48 +0200 (CEST) Date: Mon, 11 May 2026 16:21:43 +0200 From: Arthur Bied-Charreton To: Fiona Ebner Subject: Re: [PATCH docs/manager/qemu-server v4 00/17] Add API and UI for custom CPU models Message-ID: References: <20260430160109.565536-1-a.bied-charreton@proxmox.com> <7c07d82a-d646-4f9e-bad6-ffdde7fe95f7@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c07d82a-d646-4f9e-bad6-ffdde7fe95f7@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1778509193126 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.616 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 POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes 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: 6PHPSFTAPVX7NR4MEALSO7HT3KC5AYRM X-Message-ID-Hash: 6PHPSFTAPVX7NR4MEALSO7HT3KC5AYRM X-MailFrom: a.bied-charreton@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 Mon, May 11, 2026 at 04:08:32PM +0200, Fiona Ebner wrote: > Am 30.04.26 um 5:59 PM schrieb Arthur Bied-Charreton: > > This picks up and extends an old series [0] by Stefan Reiter. > > > > This series adds a full CRUD API and a UI editor for custom CPU models > > which allows users to manage them in the Datacenter interface rather > > than editing /etc/pve/virtual-guest/cpu-models.conf manually. > > > > It also improves on the existing VM CPU flags selector by providing a > > list of nodes supporting each flag to help gauge cluster compatibility. > > > > qemu-server gets a new CPUFlags module grouping cpu-flags-related > > helpers. A new helper (query_available_cpu_flags) is introduced, which > > derives the set of flags accepted by QEMU as -cpu arguments and > > annotates each with the cluster nodes that report supporting it. The > > existing node-level endpoint is extended with an accel parameter to > > filter flags by acceleration type. Its default behavior is preserved > > modulo the added 'supported-on' field per flag in the return value. > > > > pve-manager gets two new cluster-level endpoints: > > > > 1. /cluster/qemu/cpu-flags queries flags available across the cluster > > and reports which node supports each of them. It differs from the > > node-level endpoint in qemu-server in that it returns *all* flags, > > as opposed to the VM-specific ones. > > > > 2. /cluster/qemu/custom-cpu-models provides full CRUD for custom CPU > > model definitions. > > > > The UI gets a "Custom CPU models" view in the Datacenter panel (at the > > bottom under "Guest Resources/Hardware") with an editor for model > > properties. The flags can now be filtered by acceleration type when > > creating a new VM or custom CPU model, and it is pre-selected based on > > the VM's KVM config key when editing a pre-existing VM's CPU. The CPU > > flags selector is also improved with the option to filter out flags > > that are not supported anywhere in the cluster. > > Very good work! I know I made a lot of comments and suggestions, but > there are relatively few that I would consider blockers. The feature is > shaping up nicely and most changes should be rather straight-forward. > Except maybe the 'kvm' qm.conf checkbox might be a bit more work. If > it's too much, we can also consider doing that later on. > Thanks a lot for the thorough testing and review! I already adressed your qemu-server and pve-manager backend comments, will get to the UI parts now and should have a v5 ready in the next few days! > > Dependencies: > > pve-manager requires bumped pve-docs > > Just for completeness/as a reminder: it build-depends on > pve-doc-generator and depends on pve-docs. > > > pve-manager requires bumped qemu-server > > build+normal depends here. Thanks for the feedback, I overlooked that distinction