[PATCH manager 1/1] ui: processor edit: allow setting 8 sockets

[PATCH manager 1/1] ui: processor edit: allow setting 8 sockets

[Maximiliano Sandoval]

As per our NUMA documentation [1]:

> If the NUMA option is used, it is recommended to set the number of sockets to
> the number of nodes of the host system.

Nowadays, it is common to find CPU models with 8 NUMA nodes. Two examples are
Xeon Platinum 8160 and EPYC 73F3.

The schema at qemu-server does not limit the socket amount. However, $MAX_NUMA
is hard-coded to 8 at qemu-server's Memory.pm , so we bump it to 8 to be on the
safe side.

[1] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_numa

Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
---

Notes:
    Differences from v1:
    - Set the maxValue to 8

 www/manager6/qemu/ProcessorEdit.js | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/www/manager6/qemu/ProcessorEdit.js b/www/manager6/qemu/ProcessorEdit.js
index 719f771a7..1afc1fd78 100644
--- a/www/manager6/qemu/ProcessorEdit.js
+++ b/www/manager6/qemu/ProcessorEdit.js
@@ -129,7 +129,7 @@ Ext.define('PVE.qemu.ProcessorInputPanel', {
             xtype: 'proxmoxintegerfield',
             name: 'sockets',
             minValue: 1,
-            maxValue: 4,
+            maxValue: 8,
             value: '1',
             fieldLabel: gettext('Sockets'),
             allowBlank: false,
-- 
2.47.3

Re: [PATCH manager 1/1] ui: processor edit: allow setting 8 sockets

[Maximiliano Sandoval]

Maximiliano Sandoval <m.sandoval@proxmox.com> writes:

> As per our NUMA documentation [1]:
>
>> If the NUMA option is used, it is recommended to set the number of sockets to
>> the number of nodes of the host system.
>
> Nowadays, it is common to find CPU models with 8 NUMA nodes. Two examples are
> Xeon Platinum 8160 and EPYC 73F3.
>
> The schema at qemu-server does not limit the socket amount. However, $MAX_NUMA
> is hard-coded to 8 at qemu-server's Memory.pm , so we bump it to 8 to be on the
> safe side.
>
> [1] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_numa
>
> Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>

This is v2 actually.

-- 
Maximiliano

Re: [PATCH manager 1/1] ui: processor edit: allow setting 8 sockets

[Dominik Csapak]

if the backend does not have an upper limit, shouldn't we use the same
behavior in the frontend?

AFAICS two issues arise by having a lower value here than the backend:
* we have to raise this (probably) again in the future
* a config with a higher value cannot be edited in the gui
   (because it get's invalid)

So i'd prefer just to remove the maxValue here completely.

If there is any detrimental effect when having to much sockets
configured, we could add a warning e.g. when the sockets
is > 8.

On 7/6/26 1:47 PM, Maximiliano Sandoval wrote:
> As per our NUMA documentation [1]:
> 
>> If the NUMA option is used, it is recommended to set the number of sockets to
>> the number of nodes of the host system.
> 
> Nowadays, it is common to find CPU models with 8 NUMA nodes. Two examples are
> Xeon Platinum 8160 and EPYC 73F3.
> 
> The schema at qemu-server does not limit the socket amount. However, $MAX_NUMA
> is hard-coded to 8 at qemu-server's Memory.pm , so we bump it to 8 to be on the
> safe side.
> 
> [1] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_numa
> 
> Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
> ---
> 
> Notes:
>      Differences from v1:
>      - Set the maxValue to 8
> 
>   www/manager6/qemu/ProcessorEdit.js | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/www/manager6/qemu/ProcessorEdit.js b/www/manager6/qemu/ProcessorEdit.js
> index 719f771a7..1afc1fd78 100644
> --- a/www/manager6/qemu/ProcessorEdit.js
> +++ b/www/manager6/qemu/ProcessorEdit.js
> @@ -129,7 +129,7 @@ Ext.define('PVE.qemu.ProcessorInputPanel', {
>               xtype: 'proxmoxintegerfield',
>               name: 'sockets',
>               minValue: 1,
> -            maxValue: 4,
> +            maxValue: 8,
>               value: '1',
>               fieldLabel: gettext('Sockets'),
>               allowBlank: false,

Re: [PATCH manager 1/1] ui: processor edit: allow setting 8 sockets

[Maximiliano Sandoval]

Dominik Csapak <d.csapak@proxmox.com> writes:

> if the backend does not have an upper limit, shouldn't we use the same
> behavior in the frontend?

We have a hardcoded limit of $MAX_NUMA = 8 in qemu-server's Memory.pm as
mentioned by Alexandre in a reply to v1. I opted to be on the safer side
without redoing the entire numa handling.

At the moment there are systems with 8 sockets and at least one customer
asked for this in enterprise support.

> AFAICS two issues arise by having a lower value here than the backend:
> * we have to raise this (probably) again in the future
> * a config with a higher value cannot be edited in the gui
>   (because it get's invalid)
>
> So i'd prefer just to remove the maxValue here completely.
>
> If there is any detrimental effect when having to much sockets
> configured, we could add a warning e.g. when the sockets
> is > 8.

-- 
Maximiliano

Re: [PATCH manager 1/1] ui: processor edit: allow setting 8 sockets

[Dominik Csapak]

On 7/10/26 9:42 AM, Maximiliano Sandoval wrote:
> Dominik Csapak <d.csapak@proxmox.com> writes:
> 
>> if the backend does not have an upper limit, shouldn't we use the same
>> behavior in the frontend?
> 
> We have a hardcoded limit of $MAX_NUMA = 8 in qemu-server's Memory.pm as
> mentioned by Alexandre in a reply to v1. I opted to be on the safer side
> without redoing the entire numa handling.
> 
> At the moment there are systems with 8 sockets and at least one customer
> asked for this in enterprise support.
> 

but this is only tangentially related to the socket amount?

i can boot a vm with e.g. 16 sockets + numa 1 boot perfectly fine?

>> AFAICS two issues arise by having a lower value here than the backend:
>> * we have to raise this (probably) again in the future
>> * a config with a higher value cannot be edited in the gui
>>    (because it get's invalid)
>>
>> So i'd prefer just to remove the maxValue here completely.
>>
>> If there is any detrimental effect when having to much sockets
>> configured, we could add a warning e.g. when the sockets
>> is > 8.
> 

Re: [PATCH manager 1/1] ui: processor edit: allow setting 8 sockets

[Dominik Csapak]

On 7/10/26 9:44 AM, Dominik Csapak wrote:
> 
> 
> On 7/10/26 9:42 AM, Maximiliano Sandoval wrote:
>> Dominik Csapak <d.csapak@proxmox.com> writes:
>>
>>> if the backend does not have an upper limit, shouldn't we use the same
>>> behavior in the frontend?
>>
>> We have a hardcoded limit of $MAX_NUMA = 8 in qemu-server's Memory.pm as
>> mentioned by Alexandre in a reply to v1. I opted to be on the safer side
>> without redoing the entire numa handling.
>>
>> At the moment there are systems with 8 sockets and at least one customer
>> asked for this in enterprise support.
>>
> 
> but this is only tangentially related to the socket amount?
to clarify what i mean here:

the MAX_NUMA is only relevant for manual numa memory placement,
but automatic placement doesn't have that limit in our code....

e.g. the below vm shows in showcmd:

  -m 1024 \
  -object 'memory-backend-ram,id=ram-node0,size=64M' \
  -numa 'node,nodeid=0,cpus=0,memdev=ram-node0' \
  -object 'memory-backend-ram,id=ram-node1,size=64M' \
  -numa 'node,nodeid=1,cpus=1,memdev=ram-node1' \
  -object 'memory-backend-ram,id=ram-node2,size=64M' \
  -numa 'node,nodeid=2,cpus=2,memdev=ram-node2' \
  -object 'memory-backend-ram,id=ram-node3,size=64M' \
  -numa 'node,nodeid=3,cpus=3,memdev=ram-node3' \
  -object 'memory-backend-ram,id=ram-node4,size=64M' \
  -numa 'node,nodeid=4,cpus=4,memdev=ram-node4' \
  -object 'memory-backend-ram,id=ram-node5,size=64M' \
  -numa 'node,nodeid=5,cpus=5,memdev=ram-node5' \
  -object 'memory-backend-ram,id=ram-node6,size=64M' \
  -numa 'node,nodeid=6,cpus=6,memdev=ram-node6' \
  -object 'memory-backend-ram,id=ram-node7,size=64M' \
  -numa 'node,nodeid=7,cpus=7,memdev=ram-node7' \
  -object 'memory-backend-ram,id=ram-node8,size=64M' \
  -numa 'node,nodeid=8,cpus=8,memdev=ram-node8' \
  -object 'memory-backend-ram,id=ram-node9,size=64M' \
  -numa 'node,nodeid=9,cpus=9,memdev=ram-node9' \
  -object 'memory-backend-ram,id=ram-node10,size=64M' \
  -numa 'node,nodeid=10,cpus=10,memdev=ram-node10' \
  -object 'memory-backend-ram,id=ram-node11,size=64M' \
  -numa 'node,nodeid=11,cpus=11,memdev=ram-node11' \
  -object 'memory-backend-ram,id=ram-node12,size=64M' \
  -numa 'node,nodeid=12,cpus=12,memdev=ram-node12' \
  -object 'memory-backend-ram,id=ram-node13,size=64M' \
  -numa 'node,nodeid=13,cpus=13,memdev=ram-node13' \
  -object 'memory-backend-ram,id=ram-node14,size=64M' \
  -numa 'node,nodeid=14,cpus=14,memdev=ram-node14' \
  -object 'memory-backend-ram,id=ram-node15,size=64M' \
  -numa 'node,nodeid=15,cpus=15,memdev=ram-node15'


so it  splits it's 1024MiB in 16 * 64MiB numa chunks...

> 
> i can boot a vm with e.g. 16 sockets + numa 1 boot perfectly fine?
> 
>>> AFAICS two issues arise by having a lower value here than the backend:
>>> * we have to raise this (probably) again in the future
>>> * a config with a higher value cannot be edited in the gui
>>>    (because it get's invalid)
>>>
>>> So i'd prefer just to remove the maxValue here completely.
>>>
>>> If there is any detrimental effect when having to much sockets
>>> configured, we could add a warning e.g. when the sockets
>>> is > 8.
>>
> 
> 
> 
> 
> 

Re: [PATCH manager 1/1] ui: processor edit: allow setting 8 sockets

[Maximiliano Sandoval]

Dominik Csapak <d.csapak@proxmox.com> writes:

> On 7/10/26 9:42 AM, Maximiliano Sandoval wrote:
>> Dominik Csapak <d.csapak@proxmox.com> writes:
>> 
>>> if the backend does not have an upper limit, shouldn't we use the same
>>> behavior in the frontend?
>> We have a hardcoded limit of $MAX_NUMA = 8 in qemu-server's Memory.pm as
>> mentioned by Alexandre in a reply to v1. I opted to be on the safer side
>> without redoing the entire numa handling.
>> At the moment there are systems with 8 sockets and at least one customer
>> asked for this in enterprise support.
>> 
>
> but this is only tangentially related to the socket amount?
>
> i can boot a vm with e.g. 16 sockets + numa 1 boot perfectly fine?

In this case it is not possible to define numa policies via --numa0,
..., --numa15 (they stop at --numa7).

When discussing this off-list with Fiona we decided to be on the safer
side, the number can be bumped again once 16 socket CPUs are more
common.

>>> AFAICS two issues arise by having a lower value here than the
>>> backend: * we have to raise this (probably) again in the future * a
>>> config with a higher value cannot be edited in the gui (because it
>>> get's invalid)
>>>
>>> So i'd prefer just to remove the maxValue here completely.
>>>
>>> If there is any detrimental effect when having to much sockets
>>> configured, we could add a warning e.g. when the sockets
>>> is > 8.
>> 

-- 
Maximiliano

Re: [PATCH manager 1/1] ui: processor edit: allow setting 8 sockets

[Dominik Csapak]

On 7/10/26 10:06 AM, Maximiliano Sandoval wrote:
> Dominik Csapak <d.csapak@proxmox.com> writes:
> 
>> On 7/10/26 9:42 AM, Maximiliano Sandoval wrote:
>>> Dominik Csapak <d.csapak@proxmox.com> writes:
>>>
>>>> if the backend does not have an upper limit, shouldn't we use the same
>>>> behavior in the frontend?
>>> We have a hardcoded limit of $MAX_NUMA = 8 in qemu-server's Memory.pm as
>>> mentioned by Alexandre in a reply to v1. I opted to be on the safer side
>>> without redoing the entire numa handling.
>>> At the moment there are systems with 8 sockets and at least one customer
>>> asked for this in enterprise support.
>>>
>>
>> but this is only tangentially related to the socket amount?
>>
>> i can boot a vm with e.g. 16 sockets + numa 1 boot perfectly fine?
> 
> In this case it is not possible to define numa policies via --numa0,
> ..., --numa15 (they stop at --numa7).

yes i get that, but this is an option that is
1. not exposed on the ui at all
2. has nothing to do with the number of sockets (inherently)

for example:
i can configure:

sockets: 16
cores: 1
numa: 1
memory: 1024
numa0: cpus=0-7,memory=512
numa1: cpus=8-15,memory=512

and have 16 sockets but only 2 numa nodes...

> 
> When discussing this off-list with Fiona we decided to be on the safer
> side, the number can be bumped again once 16 socket CPUs are more
> common.

this "breaks" the UI when a user sets higher values manually, as in, one
cannot set any other option as long as the sockets are higher

so im very much in favor of removing the maxValue at all...



> 
>>>> AFAICS two issues arise by having a lower value here than the
>>>> backend: * we have to raise this (probably) again in the future * a
>>>> config with a higher value cannot be edited in the gui (because it
>>>> get's invalid)
>>>>
>>>> So i'd prefer just to remove the maxValue here completely.
>>>>
>>>> If there is any detrimental effect when having to much sockets
>>>> configured, we could add a warning e.g. when the sockets
>>>> is > 8.
>>>
> 

superseded: [PATCH manager 1/1] ui: processor edit: allow setting 8 sockets

[Maximiliano Sandoval]

Dominik Csapak <d.csapak@proxmox.com> writes:

> On 7/10/26 10:06 AM, Maximiliano Sandoval wrote:
>> Dominik Csapak <d.csapak@proxmox.com> writes:
>> 
>>> On 7/10/26 9:42 AM, Maximiliano Sandoval wrote:
>>>> Dominik Csapak <d.csapak@proxmox.com> writes:
>>>>
>>>>> if the backend does not have an upper limit, shouldn't we use the same
>>>>> behavior in the frontend?
>>>> We have a hardcoded limit of $MAX_NUMA = 8 in qemu-server's Memory.pm as
>>>> mentioned by Alexandre in a reply to v1. I opted to be on the safer side
>>>> without redoing the entire numa handling.
>>>> At the moment there are systems with 8 sockets and at least one customer
>>>> asked for this in enterprise support.
>>>>
>>>
>>> but this is only tangentially related to the socket amount?
>>>
>>> i can boot a vm with e.g. 16 sockets + numa 1 boot perfectly fine?
>> In this case it is not possible to define numa policies via --numa0,
>> ..., --numa15 (they stop at --numa7).
>
> yes i get that, but this is an option that is
> 1. not exposed on the ui at all
> 2. has nothing to do with the number of sockets (inherently)
>
> for example:
> i can configure:
>
> sockets: 16
> cores: 1
> numa: 1
> memory: 1024
> numa0: cpus=0-7,memory=512
> numa1: cpus=8-15,memory=512
>
> and have 16 sockets but only 2 numa nodes...
>
>> When discussing this off-list with Fiona we decided to be on the safer
>> side, the number can be bumped again once 16 socket CPUs are more
>> common.
>
> this "breaks" the UI when a user sets higher values manually, as in, one
> cannot set any other option as long as the sockets are higher
>
> so im very much in favor of removing the maxValue at all...
>
>
>
>> 
>>>>> AFAICS two issues arise by having a lower value here than the
>>>>> backend: * we have to raise this (probably) again in the future * a
>>>>> config with a higher value cannot be edited in the gui (because it
>>>>> get's invalid)
>>>>>
>>>>> So i'd prefer just to remove the maxValue here completely.
>>>>>
>>>>> If there is any detrimental effect when having to much sockets
>>>>> configured, we could add a warning e.g. when the sockets
>>>>> is > 8.
>>>>
>> 

Superseded-by: https://lore.proxmox.com/all/20260710084423.164757-1-m.sandoval@proxmox.com/T/#u
-- 
Maximiliano