Re: [PATCH docs/manager/qemu-server v5 00/21] Add API and UI for custom CPU models

[Arthur Bied-Charreton <a.bied-charreton@proxmox.com>]

On Fri, May 15, 2026 at 07:05:26PM +0200, Max R. Carrara wrote:
> On Fri May 15, 2026 at 11:28 AM CEST, Arthur Bied-Charreton wrote:
> > This picks up and extends an old series [0] by Stefan Reiter.
> >
> > This series adds a full CRUD API and a UI editor for custom CPU models
> > which allows users to manage them in the Datacenter interface rather
> > than editing /etc/pve/virtual-guest/cpu-models.conf manually.
> >
> > [...]
> 
> Did some preliminary testing and tried to configure a custom CPU based
> on the 'x86-64-v4' model. Unfortunately it seems like that model isn't
> included in the schema:
> 
> ```
> Parameter verification failed. (400)
> 
> reported-model: value 'x86-64-v4' does not have a value in the
> enumeration '486, a64fx, athlon, Broadwell, Broadwell-IBRS,
> Broadwell-noTSX, Broadwell-noTSX-IBRS, Cascadelake-Server,
> Cascadelake-Server-noTSX, Cascadelake-Server-v2, Cascadelake-Server-v4,
> Cascadelake-Server-v5, ClearwaterForest, Conroe, Cooperlake,
> Cooperlake-v2, core2duo, coreduo, cortex-a35, cortex-a53, cortex-a55,
> cortex-a57, cortex-a710, cortex-a72, cortex-a76, EPYC, EPYC-Genoa,
> EPYC-Genoa-v2, EPYC-IBPB, EPYC-Milan, EPYC-Milan-v2, EPYC-Milan-v3,
> EPYC-Rome, EPYC-Rome-v2, EPYC-Rome-v3, EPYC-Rome-v4, EPYC-Rome-v5,
> EPYC-Turin, EPYC-v3, EPYC-v4, EPYC-v5, GraniteRapids, GraniteRapids-v2,
> GraniteRapids-v3, Haswell, Haswell-IBRS, Haswell-noTSX,
> Haswell-noTSX-IBRS, host, Icelake-Client, Icelake-Client-noTSX,
> Icelake-Server, Icelake-Server-noTSX, Icelake-Server-v3,
> Icelake-Server-v4, Icelake-Server-v5, Icelake-Server-v6,
> Icelake-Server-v7, IvyBridge, IvyBridge-IBRS, KnightsMill, kvm32, kvm64,
> max, Nehalem, Nehalem-IBRS, neoverse-n1, neoverse-n2, neoverse-v1,
> Opteron_G1, Opteron_G2, Opteron_G3, Opteron_G4, Opteron_G5, Penryn,
> pentium, pentium2, pentium3, phenom, qemu32, qemu64, SandyBridge,
> SandyBridge-IBRS, SapphireRapids, SapphireRapids-v2, SapphireRapids-v3,
> SapphireRapids-v4, SierraForest, SierraForest-v2, SierraForest-v3,
> Skylake-Client, Skylake-Client-IBRS, Skylake-Client-noTSX-IBRS,
> Skylake-Client-v4, Skylake-Server, Skylake-Server-IBRS,
> Skylake-Server-noTSX-IBRS, Skylake-Server-v4, Skylake-Server-v5,
> Westmere, Westmere-IBRS'
> ```
> 
> Choosing a different CPU type made it work.
> 
> To test whether the flags are actually passed on to the VM, I gave my
> custom model the 'nested-virt' flag and checked whether it appears after
> restarting the VM using `lscpu | grep -E '(svm|vmx)'`.
> 
> Indeed it does appear; when setting the CPU model back to
> 'x86-64-v2-AES' again, the flag disappears once rebooted.
> 
> So, the series seems to work; just that there's a schema issue.
> 
> Pretty neat overall!
Thanks for testing :)

The issue is that $cpu_fmt [0], which is used as the schema for the custom
models endpoints, defines valid reported models using
get_all_cpu_models() [1], while the /nodes/.../capabilities/qemu/cpu
endpoint uses get_cpu_models() [2]. 

The former includes only CPU types QEMU will accept as reported models
(see `qemu-system-x86_64 -cpu help`), while the latter also includes
some PVE-builtin models [3] - those cannot be used as reported models 
(QEMU does not know about them) and are rightfully excluded of 
$cpu_fmt, however then they should definitely also not be shown in the
reported model dropdown, so thanks for catching that!

[0]
https://git.proxmox.com/?p=qemu-server.git;a=blob;f=src/PVE/QemuServer/CPUConfig.pm;h=8bc5f895998a26b78dfa826e7b27b812839f6e0b;hb=refs/heads/master#l350
[1]
https://git.proxmox.com/?p=qemu-server.git;a=blob;f=src/PVE/QemuServer/CPUConfig.pm;h=8bc5f895998a26b78dfa826e7b27b812839f6e0b;hb=refs/heads/master#l259
[2]
https://git.proxmox.com/?p=qemu-server.git;a=blob;f=src/PVE/QemuServer/CPUConfig.pm;h=8bc5f895998a26b78dfa826e7b27b812839f6e0b;hb=refs/heads/master#l622
[3]
https://git.proxmox.com/?p=qemu-server.git;a=blob;f=src/PVE/QemuServer/CPUConfig.pm;h=8bc5f895998a26b78dfa826e7b27b812839f6e0b;hb=refs/heads/master#l53