[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