[pve-devel] [PATCH-SERIES v3 qemu-server/manager/common] add and set x86-64-v2 as default model for new vms and detect best cpumodel

[Fiona Ebner]

Am 22.05.23 um 12:25 schrieb Alexandre Derumier:
> In addition to theses model, I have enabled aes too.
> I think it's really important, because a lot of users use default values and have
> bad performance with ssl and other crypto stuffs.
> 

So there is the answer to my aes question :) But shouldn't we rather set
it via the UI as a default than change the CPU definition itself? That
feels cleaner as we'd not diverge from how they defined the ABI.

> 
> This was discussed on the qemu mailing
> 
> "
> Crypto accelerator caveats
> ==========================
> 
> Similarly I'm not a huge fan of leaving out the "aes"
> instruction for accelerated crypto, as missing "aes" is
> also one of the key factors in making qemu64 a bad choice.
> 
> If we include 'aes' in x86-64-v2, then we loose support
> for Nehalem hosts.
> 
> If we include 'aes' in x86-64-v3 then we further loose
> support for Dhyana hosts (an EPYC derived CPU).
> "
> 
> Nahelemn is a 2008 cpu, so I think it's ok, we are in 2013 ;)
> (and user can disable aes flag in gui too)
> 
> That mean than the minimum compatible cpu for v2 is Intel Westmere (2010)
> and Amd Bulldozer (2011).


> Additionnaly, it could be great to use a real cpu model when we don't have
> mixed intel/amd cluster, to have spectre/meltdown/.... mitigations enabled.
> 
> I have added initial code for best model detection based on host cpuflags
> vs qemu models flags.
> 
> Not yet plugged, I'm not sure what is the best way, only at vm create,
> or at vm start to auto upgrade vm cpu to last version ?
> I'm not sure with cluster, if user add a new older node.
> (vmware have a feature called EVC, compute the best model when node join/leave)
> 

If we do this, then only at VM create. Changing the CPU at VM start is
just too much magic and can break things, because we don't know what the
guest is fine with. Much of the problem would already be solved by
having something like https://bugzilla.proxmox.com/show_bug.cgi?id=3500
where the admin can select a sane default for their cluster and we can
help them choose a default with some guidance in the documentation.

A way to calculate the best model in the cluster can be fine, but seems
to be quite an effort. If we deem it worth it, we can still have a
separate "calculate best model" tool/command. Changing such things
automatically just leads to unexpected surprises.