[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

DERUMIER, Alexandre alexandre.derumier at groupe-cyllene.com
Sun Jun 4 08:29:42 CEST 2023


Le samedi 03 juin 2023 à 16:14 +0200, Thomas Lamprecht a écrit :
> Am 01/06/2023 um 11:06 schrieb DERUMIER, Alexandre:
> > > Maybe the easiest would be to extract the aes flag out of the
> > > grid
> > > into
> > > the non-advanced part?
> > > 
> > Couldn't be easier to keep aes enable by default in a single model
> > (even if it's doesn't match the x86-64 spec). and allow user to
> > optin
> > disable it.
> > The only server where you need to disable aes if for nahelem, and I
> > don't think that a lot of users still have this cpu in production.
> > (so keeping the aes flag in advanced section make sense).
> > Also, user with really old servers, could keep to use kvm64 model,
> > where aes is not enabled.
> 
> 
> I also think that we should not bend to much for Nehalem, and fwiw if
> we go for a v2+aes CPU model (which IMO is one of the easies
> solutions)
> we would only need that for v2, as v3 could always have that enabled
> by
> default FWIWCT?
> 
> So:
> 
> x86-64-v2
> x86-64-v2-aes   (UI default)
> x86-64-v3
> 
> (and that as real models, not just UI fakery) would work,
> 
That's exactly what I have done for the v4 patch series ;)



> But tbh., I'd not be completely against just enabling it for v2 and
> warning,
> or even erroring, if the VM gets created on a host that doesn't
> supports it
> (which might be a good idea for any vX level); as Alexandre is right,
> a lot of
> users needlessly get slower VMs that they could be and production
> setups with
> a 14 year old CPU are just very unlikely, and they simply can disable
> AES again...
> 
I have see that with a lot of my customers, (and also with some
benchmark on the net), where admins don't even known what AES is ^_^



More information about the pve-devel mailing list