[pve-devel] [PATCH qemu] api: qemu: create: default cpu to x86-64-v2-AES
Fiona Ebner
f.ebner at proxmox.com
Wed Oct 23 11:56:48 CEST 2024
Am 22.10.24 um 15:35 schrieb Thomas Lamprecht:
> Am 22/10/2024 um 14:15 schrieb Maximiliano Sandoval:
>> Thomas Lamprecht <t.lamprecht at proxmox.com> writes:
>>
>>> And even then, would this still break restoring backups made before that
>>> change?
>>> If, this would fall under the changes that need versioning the guest
>>> configs. Which naturally is possible but is IMO also not something I'd
>>> do lightly, as that's something that might have wide-reaching consequences.
>>
>> Would it make more sense to do this only for the CLI tool, and only when creating new VMs?
>>
>
> Hmm, it would feel a bit odd to me to single that specific "mismatch" between
> UI default and CLI/schema out but ignore the others, like e.g., the memory
> default of 2048, or some dynamic defaults like the OS-type dependent ones.
>
> And while it would have reduced impact, it would be still a breaking change
> that might affect peoples automation/scripts.
> But if more than just the CPU type would be looked at, and adapted such that
> UI and CLI behave more the same, it might be indeed a feasible way to improve
> UX slightly on the next major release next year.
> Conveying the reason for different defaults and how one can look into which
> one will be applied would warrant a short paragraph in the docs then too.
> And taking the chance and looking at the CT story on this would be great too,
> e.g., like is 512 MB really still a good default for UI/CLI, or unprivileged
> vs. privileged.
Maybe we could have (datacenter-wide?) default profiles (one for
containers, one for VMs) whose values are used for new guest creation?
Users could modify them if desired and they could also be used to
pre-fill values in the UI. Could then be shipped for PVE 9 with sensible
values.
More information about the pve-devel
mailing list