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

[Dominik Csapak <d.csapak@proxmox.com>]

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.
>>
> 
> 
> 
> 
>