Re: [PATCH manager/qemu-server 0/8] Add API and UI for custom CPU models

[Fiona Ebner <f.ebner@proxmox.com>]

Am 27.03.26 um 2:06 PM schrieb Arthur Bied-Charreton:
> On Thu, Mar 26, 2026 at 03:54:53PM +0100, Fiona Ebner wrote:
>> Am 12.03.26 um 9:40 AM schrieb Arthur Bied-Charreton:
>>> This is picked up from an old series [0] by Stefan Reiter.
>>>
>>> As of before this series, the only way to create custom CPU models is by
>>> editing `/etc/pve/virtual-guest/cpu-models.conf` manually.
>>>
>>> This can be cumbersome for a few reasons, e.g., due to the fact that flags
>>> misconfigurations are only caught when starting the VM.
>>>
>>> `cpu-flags` endpoint:
>>> The `cpu-flags` endpoint previously returned a list of hardcoded flags,
>>> which is both non-exhaustive (some flags I should be able to set are missing),
>>> and partly incorrect (some flags my host(s) do not support set are returned).
>>> This is limiting and can lead to misconfigurations. The updated endpoint
>>> intersects all flags QEMU accepts as `-cpu` arguments with all flags the host
>>> hardware/emulation actually supports. This way, if I am able to set a flag in
>>> the UI, I can be confident that the VM will actually be able to start.
>>>
>>> Custom CPU model CRUD functionality:
>>> Expose CRUD endpoints and UI flow to interact with `cpu-models.conf`. For each
>>> flag, show a list of the cluster nodes supporting it, and only expose flags that
>>> at least one node supports to avoid misconfigurations. Filter flags by
>>> acceleration type (KVM/TCG).
>>>
>>> [0] https://lore.proxmox.com/pve-devel/20211028114150.3245864-1-s.reiter@proxmox.com/
>>
>> With a pre-existing, manually added model:
>>
>> [I] root@pve9a1 ~# cat /etc/pve/virtual-guest/cpu-models.conf
>> cpu-model: nested-for-wsl
>> 	flags +svm
>> 	hidden 1
>> 	hv-vendor-id AuthenticAMD
>> 	reported-model EPYC
>>
>> When opening it up in the UI, the editor seems to immediately detect a
>> change, i.e. the OK button is clickable and when I click it, I get the
>> following error:
>>
>> Parameter verification failed. (400)
>> flags: value does not match the regex pattern
>>
> Thanks a lot for catching that!
> 
>> It seems to be because of the 'svm' flag not being in the flags grid.
> Yes, just confirmed that.
>> Since users might've already added such models manually, it would be
>> nice if it would work. Maybe list the unknown flags in the grid without
>> description?
> Yes, I will display unknown flags in the grid with empty supported-on
> fields. 
> 
> On this topic: I currently manually filter out occurrences of svm/vmx to 
> replace them with nested-virt. Would it make sense to still display them
> in the flags selector, even if they overlap with our abstraction? 

I think we can still show them and don't need to filter them out. In
particular, not having the 'supported-on' for those flags can also lead
to confusion, as can (artificially) hiding them from users. I don't see
why we should force people to use the abstract 'nested-virt'. It can be
convenient for mixed-CPU-vendor clusters, and having the flag be part of
the VM-specific ones was the main motivation to add it.