How To Create Custom CPUs For Proxmox VE

Nov 10, 2025 · 4 mins read
How To Create Custom CPUs For Proxmox VE

In the video below, we show how to create custom CPUs in Proxmox VE


Although Proxmox VE ships with a lot of CPU types, you can still run into issues

For instance, I have servers with older Intel CPUs that support AVX but not AVX2

In addition I have a mixed CPU cluster

As a result I’ve been using the default x86-64-v2-AES CPU model, so I can do live migrations

The only problem for instance is if you want to use MongoDB 5.0 or above, the CPU needs to support AVX and this one doesn’t

Fortunately, you can create custom CPU types to resolve this

But, how do you create your own custom CPU type in Proxmox VE?

Useful links:
https://pve.proxmox.com/wiki/Manual:_cpu-models.conf

Is It Supported?:
The first thing to do is to make sure the host CPU does support what you want

In this example, I need to confirm support for AVX or Advanced Vector Extensions

Either SSH into a node or open a Shell session, then run this command

grep avx /proc/cpuinfo

In other words I’m filtering the output to look for a flag of avx

Now this will result in a lot of duplicated information, but the key point is if there is no output then I know AVX in this case isn’t supported by the host CPU

TIP: If you want to look for all supported features you could run this command instead

grep flags /proc/cpuinfo

Whatever filtering you use, repeat this on all necessary nodes in the cluster

I say necessary nodes, because you may have redundancy setup so only two nodes would ever run a VM for instance

If that’s the case, then you only need to check those two for support for whatever flag you need

And it’s very important because if the host CPU doesn’t support that flag, you’ll find it can’t run the VM

Create Custom CPU:
To create your own custom CPU models we need to add the details to a file

nano /etc/pve/virtual-guest/cpu-models.conf
cpu-model: x86-64-v2-AES-AVX
    flags +aes;+popcnt;+ssse3;+sse4_1;+sse4_2;+avx;+xsave
    reported-model kvm64
    hv-vendor-id proxmox

Now save and exit

TIP: This file should automatically be replicated to other nodes in the cluster, so you only need to create it once

I haven’t created any on this cluster yet, and we don’t get a file with examples, so initially the file is empty

Now I’ve called this CPU x86-64-v2-AES-AVX because my goal is to have a similar CPU type to the default one, but with the added support for AVX as well

But the name is cosmetic, so use what seems relevant to you

The next lines have to be indented, and you can use one TAB or multiple spaces to do that

As well as adding the extra flags presented by x86-64-v2-AES, I’ve added two others to allow the use of AVX +avx;+xsave

The reported-model is optional, but may help PVE itself when doing live migrations, but also the VM’s guest OS for software and feature selection

Bear in mind, this has to be from a list of known types, which you can find here https://pve.proxmox.com/wiki/Manual:_cpu-models.conf

Now I’ve opted for the default value of kvm64, but I’ve put the line there in case I want to experiment

In addition, I’ve also added hv-vendor-id as again, the guest OS may benefit from knowing this information

I haven’t set the hidden option, as I don’t mind if this presents itself as a virtual machine to the guest OS

Nor have I set the phys-bits option, as I’ve found that if I leave it out, it will report the same address space as x86-64-v2-AES anyway

The choices for that option by the way are setting it to host, or a specific value but I don’t want to risk breaking live migrations

I’ve no intentions of changing this one either, so I’ve left it out

If you want you can edit a VM’s config from the CLI

Otherwise, back in the GUI, you can choose your custom CPU type which will show up at the end of the list

But as with most hardware, the processor isn’t hot pluggable, so you have to shut down the VM then start it back up for the changes to take effect

After that I can check that AVX in this case is now supported

grep avx /proc/cpuinfo

Summary:
Ideally you would be better off setting the CPU type to host

This lets a VM take full advantage of all CPU capabilities and this can boost performance

But in a mixed CPU environment like I have, that would break live migrations

In my case, my oldest servers can’t take advantage of x86-64-v3 or x86-64-v4

But now that I know about custom CPUs I can take advantage of AVX

Sharing is caring!