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

["Max R. Carrara" <m.carrara@proxmox.com>]

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!