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 405DD1FF13F for ; Thu, 29 Jan 2026 10:41:44 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id BA7E924355; Thu, 29 Jan 2026 10:42:09 +0100 (CET) Message-ID: <996532ce-e7b6-4221-addc-ccddeb71374f@proxmox.com> Date: Thu, 29 Jan 2026 10:41:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [pve-devel] [PATCH manager 06/10] ui: qemu: make os type selector architecture aware To: Proxmox VE development discussion , Dominik Csapak References: <20260128123035.2576774-1-d.csapak@proxmox.com> <20260128123035.2576774-7-d.csapak@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <20260128123035.2576774-7-d.csapak@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1769679615268 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 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: ITFAFXB52UUVMRFKSBZROGFMZ5JL5GMK X-Message-ID-Hash: ITFAFXB52UUVMRFKSBZROGFMZ5JL5GMK 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 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__') {