From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id E766C1FF13F for ; Thu, 29 Jan 2026 11:18:59 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 56AE725403; Thu, 29 Jan 2026 11:19:24 +0100 (CET) Message-ID: <7dffe159-3582-4406-850b-3318757658d0@proxmox.com> Date: Thu, 29 Jan 2026 11:18:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [pve-devel] [PATCH manager 06/10] ui: qemu: make os type selector architecture aware To: Fiona Ebner , Proxmox VE development discussion References: <20260128123035.2576774-1-d.csapak@proxmox.com> <20260128123035.2576774-7-d.csapak@proxmox.com> <996532ce-e7b6-4221-addc-ccddeb71374f@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: <996532ce-e7b6-4221-addc-ccddeb71374f@proxmox.com> 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: 1769681851730 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.032 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: 7SY7ODYO3E3U3DLYLXT2FCBAY7TLUSRE X-Message-ID-Hash: 7SY7ODYO3E3U3DLYLXT2FCBAY7TLUSRE 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 X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: btw. i found some bugs with the current ostype implementation (there is some bad behavior with different host arch + wizard vs non-wizard) i'm currently contemplating rewriting this + the iso edit component into pure 'non-wizard' components and make a separate 'iso+ostype' panel that's specific for the wizard. that would clean up a fair bit of code and make the different flows a bit cleaner also, i'd like to change the way we generate the architecture in the wizard. imho it's better to let the wizard calculate the 'correct' arch (including considering the hostarch) than each component itself On 1/29/26 10:40 AM, Fiona Ebner wrote: > Am 28.01.26 um 1:30 PM schrieb Dominik Csapak: >> diff --git a/www/manager6/Utils.js b/www/manager6/Utils.js >> index d8b212bc..de1ee0ba 100644 >> --- a/www/manager6/Utils.js >> +++ b/www/manager6/Utils.js >> @@ -63,6 +63,17 @@ Ext.define('PVE.Utils', { >> Other: [{ desc: '-', val: 'other' }], >> }, >> >> + kvmOSTypesPerArchitecture: { >> + x86_64: { >> + bases: undefined, // include all >> + ostypes: undefined, // include all >> + }, >> + aarch64: { >> + bases: ['Linux', 'Other'], >> + ostypes: ['l26', 'other'], > > What about Windows? Do we really want to hide that compeletely in the > UI? Unfortunately [;P], I expect that to be a non-negligible use case > and many requests to come in (which will miss that it's available on the > CLI). Or is it not properly supported in the backend? If yes, that > should be fixed, note that I have sent a patch at least for the > unavailable hyperv flags [0]. I mean, we can also wait and see if I'm > right. Maybe people don't care about it as much on ARM, I'd be glad ;) > > [0]: > https://lore.proxmox.com/pve-devel/20260127134626.127432-3-f.ebner@proxmox.com/ > >> + }, >> + }, >> + >> is_windows: function (ostype) { >> for (let entry of PVE.Utils.kvm_ostypes['Microsoft Windows']) { >> if (entry.val === ostype) { >> @@ -2068,6 +2079,18 @@ Ext.define('PVE.Utils', { >> return Ext.htmlEncode(description); >> }, >> >> + // returns the resulting architecture from a given arch and >> + // the nodename, in case the architecture is set to default >> + getArchitecture: function (architecture, nodename) { > > getNodeArchitecture would be a bit more telling > >> + if (architecture === '__default__') { >> + architecture = undefined; >> + } >> + >> + let hostArchitecture = PVE.data.ResourceStore.getNodeById(nodename)?.data.architecture; >> + >> + return architecture ?? hostArchitecture ?? 'x86_64'; >> + }, >> + >> // returns if the given architecture is the native host architecture of the given nodename >> isHostArchitecture: function (architecture, nodename) { >> if (architecture === '__default__') {