all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Fiona Ebner <f.ebner@proxmox.com>
To: Dominik Csapak <d.csapak@proxmox.com>,
	Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH manager 07/10] ui: qemu: make machine panels/fields architecture aware
Date: Thu, 29 Jan 2026 13:25:10 +0100	[thread overview]
Message-ID: <27583a1f-154e-41c1-86b3-11a20a156345@proxmox.com> (raw)
In-Reply-To: <3f6ae5e9-7871-4220-b759-15b71720a4b6@proxmox.com>

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).




  reply	other threads:[~2026-01-29 12:25 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-28 12:18 [pve-devel] [PATCH manager 00/10] enable qemu vm architecture selection Dominik Csapak
2026-01-28 12:18 ` [pve-devel] [PATCH manager 01/10] api/pvestatd: broadcast and expose non-x86 host architecture Dominik Csapak
2026-01-28 16:05   ` Fiona Ebner
2026-01-29  9:20     ` Dominik Csapak
2026-01-28 12:18 ` [pve-devel] [PATCH manager 02/10] ui: resource store: add architecture field Dominik Csapak
2026-01-28 12:18 ` [pve-devel] [PATCH manager 03/10] ui: qemu: add architecture field in wizard and hardware view Dominik Csapak
2026-01-28 16:32   ` Fiona Ebner
2026-01-28 12:18 ` [pve-devel] [PATCH manager 04/10] ui: qemu: make scsi hw selector architecture aware Dominik Csapak
2026-01-28 12:18 ` [pve-devel] [PATCH manager 05/10] ui: qemu: make osdefaults " Dominik Csapak
2026-01-29  9:25   ` Fiona Ebner
2026-01-28 12:18 ` [pve-devel] [PATCH manager 06/10] ui: qemu: make os type selector " Dominik Csapak
2026-01-29  9:41   ` Fiona Ebner
2026-01-29  9:47     ` Dominik Csapak
2026-01-29 12:09       ` Fiona Ebner
2026-01-29 10:18     ` Dominik Csapak
2026-01-29 12:10       ` Fiona Ebner
2026-01-28 12:18 ` [pve-devel] [PATCH manager 07/10] ui: qemu: make machine panels/fields " Dominik Csapak
2026-01-29 11:12   ` Fiona Ebner
2026-01-29 12:16     ` Dominik Csapak
2026-01-29 12:25       ` Fiona Ebner [this message]
2026-01-28 12:18 ` [pve-devel] [PATCH manager 08/10] ui: qemu: make bios selector " Dominik Csapak
2026-01-28 12:18 ` [pve-devel] [PATCH manager 09/10] ui: qemu: make sortByPreviousUsage " Dominik Csapak
2026-01-28 12:18 ` [pve-devel] [PATCH manager 10/10] ui: qemu: wizard: use defaults to populate machine and bios Dominik Csapak
2026-01-29 13:13 ` [pve-devel] [PATCH manager 00/10] enable qemu vm architecture selection Fiona Ebner
2026-01-29 13:15   ` Fiona Ebner
2026-02-03 10:45 ` superseded: " Dominik Csapak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=27583a1f-154e-41c1-86b3-11a20a156345@proxmox.com \
    --to=f.ebner@proxmox.com \
    --cc=d.csapak@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal