For starters, on the "OS Selection", choosing Windows / Linux / etc should ideally be selecting settings that are suitable for those operating systems.
That's happening... For example, we enable TPM and EFI secure boot by default for Win11, depending on the OS PVE also adapts various HW parts like hw timers or CPU flags, adapt the default bus for hard disks (windows based get IDE, as that always works, Linux get VirtIO SCSI)
The default settings so far are not meeting the listed minimum system requirements for those operating systems, or won't boot due to missing drivers.
Example?
"Machine", unless someone selects something older than Windows 7 or Linux 2.6, it should be set to Q35. There are no advantages to using i440fx in 2022.
Why? Q35 adds a bunch of extra HW and also slight overhead emulating that, most users do not need that, so those would say the exact opposite. Q35 is basically mostly relevant for PCIe HW passthrough.
"Disks". 32GB is too small for any modern Windows or Linux boot disk. This should be increased to 60GB. Discard should be enabled by default as well, I fail to see a situation where you wouldn't want your disks to get rid of unused blocks. Also, IDE boot is set by default, this should really be SATA, unless you are booting Windows XP.
SATA isn't really giving you that many benefits, if you want SCSI and for that VirtIO SCSI which is the default for modern OS, Windows would require extra drivers which confuses some new users, so we keep IDE.
Last time I checked discard requires SSD for most OS, and that would enable a few other things and lots of users still use spinners as backing storage, where it may have a negative impact, so plainly enabling both cannot happen (autodetection for default would be nice but can only cover a fraction of storage types).
And I saw a lot of productions VMs that use way less than 32 GiB of storage in the ten thousand+ support cases handled since I work at Proxmox, your use case is not everyone's use case, bumping it to 64 GiB for Windows could make sense though.
"CPU" - why is 1 core default? For starters, 99.99% of Proxmox hosts have at least 2 cores. In 2022, No-one wants a VM with 1 core, unless it's an extremely basic router or something.
Did you check all the hundred thousands PVE hosts out there? As hyperbole won't just take credibility of your "argument".
If you want more select more, if you create VMs that much that it hurts use the API and automate it.
There is also no reason to use the "default KVM64" option when a "Host" option exists, which allows me to pass through CPU features which most likely improve performance for many workloads
There is, enterprise workloads require live-migration to provided better uptime and have less maintenance burden, KVM64 allows that for most mixed CPU setups too, while providing a good base set of CPU flags for performance.
"Memory". I don't think Balooning is such an "advanced" feature to grasp and I don't think that should be hidden by default. Also, the default is 2GB, which is too small.
First, the advanced checkbox is stateful (saved to browser local storage), once you selected it anywhere it will stay checked and by default visible in that browser.
It would make a lot more sense for the default to be 4GB for Windows, and 2GB for Linux based OSes.
That requires again extra drivers in the hosts, something you allegedly stated that it's there (shouldn't be) and is bad..
"Network". VirtIO is great for Linux, but E1000 should be the default for Windows selections.
It is, just rechecked.
Whilst I love Proxmox and think its a fantastic platform, these default settings haven't really changed since I started using it in 2017 and it's about time they were reviewed. I help a lot of junior techs get started with virtualisation and I see a lot of them getting into trouble because of silly default settings, and it would be nice for this to not be an issue.
EFI with default enrolled secure boot came later, as did TPM and its default for win11. VMs had 512 MiB of memory selected as default before 6.2-2 which got released in May 2020, and there are more (check git if you want full history).
So, IMO they definitively ain't "so bad" as your loaded title suggests.
Adapting the default is IMO not a way forward to really improve this, with that you make a set of people happier while making another unhappier, and I really wouldn't bet that the first one is bigger.
Use cases are just too different, often there are even more than one in a department/PVE setup, and that's why it would require a profile mechanism. With that one could create a set of defaults for a specific use case for VM/CT creation and choose your profile at start of VM/CT creation, allowing one to adapt the defaults to ones need and use case while still having a low overhead on configuring the base properties of a virtual guest.
