Am 19/06/2023 um 09:28 schrieb Alexandre Derumier:
> Signed-off-by: Alexandre Derumier <aderum...@odiso.com>
> ---
>  www/manager6/qemu/MemoryEdit.js | 52 +++++++++++++++++++++++++++------
>  1 file changed, 43 insertions(+), 9 deletions(-)
> 
> diff --git a/www/manager6/qemu/MemoryEdit.js b/www/manager6/qemu/MemoryEdit.js
> index 5e91dc9b..be7903a2 100644
> --- a/www/manager6/qemu/MemoryEdit.js
> +++ b/www/manager6/qemu/MemoryEdit.js

> @@ -63,7 +73,7 @@ Ext.define('PVE.qemu.MemoryInputPanel', {
>               xtype: 'pveMemoryField',
>               labelWidth: labelWidth,
>               fieldLabel: gettext('Memory') + ' (MiB)',
> -             name: 'memory',
> +             name: 'current',
>               value: '512', // better defaults get set via the view 
> controllers afterrender
>               minValue: 1,
>               step: 32,
> @@ -96,12 +106,25 @@ Ext.define('PVE.qemu.MemoryInputPanel', {
>               allowBlank: false,
>               listeners: {
>                   change: function(f, value) {
> -                     var memory = me.down('field[name=memory]').getValue();
> +                     var memory = me.down('field[name=current]').getValue();
>                       var shares = me.down('field[name=shares]');
>                       shares.setDisabled(value === memory);
>                   },
>               },
>           },
> +         {
> +             xtype: 'pveMemoryField',
> +             name: 'max',
> +             minValue: 65536,
> +             maxValue: 4194304,
> +             value: '',
> +             step: 65536,
> +             fieldLabel: gettext('Maximum memory') + ' (MiB)',

This huge step size will be confusing to users, there should be a way to have
smaller steps (e.g., 1 GiB or even 128 MiB).

As even nowadays, with a huge amount of installed memory on a lot of servers,
deciding that a (potentially bad actor) VM can use up 64G or 128G is still
quite the difference on a lot of setups. Fiona is checking the backend here
to see if it might be done with a finer granularity, or what other options
we have here.

> +             labelWidth: labelWidth,
> +             allowBlank: true,
> +             emptyText: gettext('Disabled'),
> +             submitEmptyText: false,

I'd maybe show a warning if the guest has Memory hotplug disabled completely

Also would be great if we could check validity with other fields, i.e., if 

> +         },
>           {
>               xtype: 'proxmoxintegerfield',
>               name: 'shares',
> @@ -132,6 +155,13 @@ Ext.define('PVE.qemu.MemoryInputPanel', {
>                   },
>               },
>           },
> +         {
> +             xtype: 'proxmoxcheckbox',
> +             labelWidth: labelWidth,
> +             name: 'virtio',
> +             defaultValue: 0,
> +             fieldLabel: gettext('Virtiomem'),
> +         },

Can we change this to a radio field group with label "Hotplug Type" and options
"VirtIO-Mem" and "Static DIMMs" (or some wording like that) and show a warning 
if
the OS type isn't Linux (i.e., "l26").

As while there are some experimental patches for Windows [0], they are not
included in the VirtIO drivers and development seems to have stalled a bit.

[0]: https://github.com/virtio-win/kvm-guest-drivers-windows/pull/794


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Reply via email to