[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

[Thomas Lamprecht]

Am 01/06/2023 um 10:34 schrieb Fiona Ebner:
> Am 31.05.23 um 16:34 schrieb DERUMIER, Alexandre:
>> Le mercredi 31 mai 2023 à 13:36 +0200, Fiona Ebner a écrit :
>>> 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.
>>
>> I don't have looked pve-manager code yet, but do you think it's easy
>> to auto enable/disable the aes flag in the grid when we choose theses
>> models ?
> 
> I also haven't looked at the code, but yeah, it is an issue that it's in
> the advanced part and we shouldn't hide it from the user that it's on.
> 
>> Maybe could it be better to have 2 differents models, with/without aes
>> (like some qemu models versions like -IBRS,  
>> here we could have
>>
>> x86-64-v2
>> x86-64-v2-aes   (default)
>> x86-64-v3
>> x86-64-v3-aes
> 
> That might work, but if we do that, please only in the UI. Also not
> ideal, because how would interaction with the flag in the grid work?
> E.g. don't show it, force it on if an -aes model is selected?

Please no, I would find it very odd to see a CPU model in the Web UI that
doesn't exist in the API/Backend.

> 
> Maybe the easiest would be to extract the aes flag out of the grid into
> the non-advanced part?

Yes, rather that – but possibly without the radio-group UI but simply a
combobox with "Yes" <- default, "Auto (CPU model)" or "no" options