CPU reported-model=<enum> benefits?

[Daniel Gamboa]

I have a question regarding CPU reported-model.

Is there any performance benefit to specifying your CPU model if it's supported? If not what would be a valid reason for specifying it?

Links:
https://pve.proxmox.com/pve-docs/cpu-models.conf.5.html
"CPU model and vendor to report to the guest. Must be a QEMU/KVM supported model. Only valid for custom CPU model definitions, default models will always report themselves to the guest OS."

https://pve.proxmox.com/pve-docs/pve-admin-guide.pdf
"CPU model and vendor to report to the guest. Must be a QEMU/KVM supported model. Only valid for custom CPU model definitions, default models will always report themselves to the guest OS"

 

[Dunuin]

All CPUs support other instruction sets and using newer CPUs with more advanced instruction sets will give you better performance. If you set your CPU model to "host" a KVM guest will be able to use all instructions your host is capable of, so you get the best performance possible. But the default is "kvm64" and that is a config with limited instruction sets but that most CPUs support. So the guest can't use all of the hosts functions and is slower, but this might still be useful if you for example run a cluster with different nodes using different CPUs. That way you can migrate VMs between different hosts with different CPU without breaking the VM because the VM don't requires instructions that the host isn't capable of. Or if you are using some cloud services where you never know what hardware your node will actually be running on.

So if you only got one host or a cluster of identical machines use "host". If you got a cluster of mixed machines use something like "kvm64".

 

[Daniel Gamboa]

Thank you for your time.

You said that:

..."That way you can migrate VMs between different hosts with different CPU without breaking the VM because the VM don't requires instructions that the host isn't capable of"

I am assuming that the guest would scan the host node at boot, therefore this migration limitation is for "live migrations" would that be correct?