On 1/17/25 16:27, Thomas Lamprecht wrote:
Am 17.01.25 um 16:10 schrieb Daniel Kral:
What do you think about fixing the problem from the other side: I could
do a follow up where it's not possible to actively assign a VM more
resources than currently available, since it would not boot anyway? I
think there's a negligible amount of users who'd want to configure more
resources and only later upgrade to the required primary memory or a
heavier CPU (wrt to their core count).
Such a VM might not boot on it's current node, but it could boot on
another node with more CPU cores. Often not a big issue, but we avoid
such restrictions as they often create more friction without providing
that much help – a UI only hint in case of setting more cores than the
current node supports might be better here.
Thanks for the insight, that makes sense and I haven't thought about it
in the cluster context, I'll keep that in mind for future changes!
Maybe best to just ignore the glitch in the output for now, or indeed
duplicate the calculation, or look into why vmstatus does it that way
and see if it could be unclamped there (or a new property is warranted).
btw. you use the "api" prefix for this patch, but it should be "cli",
as this is not changing the (REST) API in any way.
Thanks for pointing that out, I'll change that for a v2! I'll also take
a second closer look why it has been clamped there and if it can be
unclamped in a separate patch for v2.
_______________________________________________
pve-devel mailing list
[email protected]
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
