[pve-devel] [PATCH v2 pve-manager 2/2] ui: qemu : memoryedit: add new max && virtio fields

[Fiona Ebner]

Am 06.09.23 um 00:35 schrieb DERUMIER, Alexandre:
> Le mardi 05 septembre 2023 à 17:16 +0200, Thomas Lamprecht a écrit :
>> Am 05/09/2023 um 17:10 schrieb DERUMIER, Alexandre:
>>>>
>>>> The advantage with 'max' is that it can be used for both, hotplug
>>>> with
>>>> dimms and virtio-mem. Otherwise, we'd need two different sub-
>>>> options
>>>> depending on hotplug method.
>>>>
>>> yes, that's what I thinked too, it could be great to have same api
>>> call
>>> with same options, with or without virtio-mem.
>>>
>>> (virtio-mem will be the default for new linux distro, but for
>>> windows
>>> or older linux distro, we still need to use old dimm method)
>>>
>>>
>>>
>>> My first idea for the gui, for the max value, was a combobox
>>> displaying
>>> an hint with mem topology, something like:
>>>
>>> max = 64GB : 64 x 1GB dimm
>>> max = 128GB: 64 x 2GB dimm
>>> ...
>>>
>>> (or maybe it could be a hint outside a simple integer field)
>>>
>>
>> We could still allow setting the DIMM size in the UI with a simple
>> integer
>> field and a step size of 1 (GB) and then calculate the max from that?
>>
>>
> yes, it could work too. Maybe a dimm size field, changing the max value
> , and at the same time, changing the max value is changing the dimm
> size field ?
> 
> 
> and for virtio-mem, dimmsize can be replace by chunk size
Sorry about the very late response!

When calculating from the DIMM size with 1 GiB step size, we can only
get to max values N * 64 GiB. We could still a have a separate max field
with smaller step size, e.g. a max value of 100 GiB would be using DIMM
size of 2 GiB and reject any API request trying to plug more memory (so
a total of 50 DIMMs can be plugged). I'm just a bit worried the
auto-update might get a bit confusing, e.g. user might just want to
change DIMM size without expecting that this will override the max
value. Should DIMM size maybe be a separate setting?

Maybe it's easier to just start with max and wait for use cases/requests
where changing DIMM size is actually required?

@Alexandre: I came back to this since
https://bugzilla.proxmox.com/show_bug.cgi?id=5585 came in and wanted to
ask if you'd still like to send out a new version with the improved max
granularity or if this should be picked up by a developer at Proxmox
instead?