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 5C01F1FF13F for ; Thu, 29 Jan 2026 13:25:25 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 76E36F71; Thu, 29 Jan 2026 13:25:49 +0100 (CET) Message-ID: <27583a1f-154e-41c1-86b3-11a20a156345@proxmox.com> Date: Thu, 29 Jan 2026 13:25:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [pve-devel] [PATCH manager 07/10] ui: qemu: make machine panels/fields architecture aware To: Dominik Csapak , Proxmox VE development discussion References: <20260128123035.2576774-1-d.csapak@proxmox.com> <20260128123035.2576774-8-d.csapak@proxmox.com> <60129254-d70c-48d5-8f3c-10d3e320da28@proxmox.com> <3f6ae5e9-7871-4220-b759-15b71720a4b6@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <3f6ae5e9-7871-4220-b759-15b71720a4b6@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1769689442978 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.015 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 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. 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: PYSOPZ22JFSWY7G3KXH4YJ7JG55AWWYL X-Message-ID-Hash: PYSOPZ22JFSWY7G3KXH4YJ7JG55AWWYL X-MailFrom: f.ebner@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: Am 29.01.26 um 1:15 PM schrieb Dominik Csapak: > On 1/29/26 12:11 PM, Fiona Ebner wrote: >> Am 28.01.26 um 1:30 PM schrieb Dominik Csapak: >>> For this, introduce a new 'QemuMachineSelector', which does the same >>> thing as the scsihw selector by filtering the kv store with a predefined >>> list for each architecture. >>> >>> Since the backend default of the machine is actually different for >>> x86_64 vs aarch64, there is some logic to handle the 'default' value >>> for the machine (iow. replace 'pc' with the default machine for each >>> architecture) >>> >> >> Setting a machine version for an existing aarch64 VM is broken, e.g. the >> result will be "pc-i440fx-10.1" instead. > > yep noticed it too now, the reason is that the arch and nodename are not > set via 'binds' yet when the 'onMachineChange' is triggering > (at least not everytime, maybe a race condition? i swear it > worked at least once on my machine ;) ) > > I'll have to change how we get/save the arch/nodename there. > When that works, it'll not show any versions currently because > the backend does not return any 'virt' models. > > i think we should fix that in the backend. I'd also add an 'arch' > parameter for the machines like you sent for the cputype Ah, I'll look into adding that! >>> diff --git a/www/manager6/qemu/HardwareView.js b/www/manager6/qemu/ >>> HardwareView.js >>> index b7cc7856..1e2cd026 100644 >>> --- a/www/manager6/qemu/HardwareView.js >>> +++ b/www/manager6/qemu/HardwareView.js >>> @@ -202,13 +202,14 @@ Ext.define('PVE.qemu.HardwareView', { >>>                   defaultValue: '', >>>                   renderer: function (value, metaData, record, >>> rowIndex, colIndex, store, pending) { >>>                       let ostype = me.getObjectValue('ostype', >>> undefined, pending); >>> +                    let arch = >>> PVE.Utils.getArchitecture(me.getObjectValue('arch'), nodename); >>>                       if ( >>>                           PVE.Utils.is_windows(ostype) && >>>                           (!value || value === 'pc' || value === 'q35') >>>                       ) { >>>                           return value === 'q35' ? 'pc-q35-5.1' : >>> 'pc-i440fx-5.1'; >> >> Unrelated to the patch, but I noticed now that this is actually wrong. >> Since QEMU 9.1+ the backend defaults to the creation version if present. > > i think this was just done as a heuristic without trying to replicate > the backend logic too tightly, but i might be misremembering I think I just wasn't aware/didn't adapt it to the backend change (that came much later).