Multiple-CPU motherboard - Settings for Windows VMs?

[jw8]

Hello all,

I know this is a very basic question, but I've read conflicting answers. I have the following dual CPU socket motherboard with two CPUs installed:

Motherboard: Supermicro MBD-X11DPI-N-B
CPU: (2x) Intel Xeon Silver (2nd Gen) 4214R - 12-core 2.40 GHz - 16.50 MB Cache - 24 threads
RAM: (8x) Supermicro MEM-DR-464MC-ER2 - 64 GB PC4-25600 DDR4 3200 MHz ECC Registered

Per the motherboard's documentation, I have the RAM populated in slots designated for the first CPU and the second CPU both, if that matters.

My question is this:

What processor settings should I set for the Windows VMs I have? Specifically Windows 10 Pro or Windows Server 2008. I have read that I should only put one socket and just increase core count and never enable NUMA, but elsewhere I've read on here that I should set the sockets to 2 and enable NUMA. I can't seem to find any official recommendations, so any help is appreciated, as well as if you guys have an opinion on how many cores I should set as well. Thanks!

 

[kawano-y]

You do not need to match the VM CPU topology to the physical server CPU topology.

Your host has two physical CPUs, but that does not mean each Windows VM should also be configured as 2 sockets. In Proxmox, the total vCPU count is:

sockets × cores

So for example:

1 socket × 4 cores = 4 vCPUs
2 sockets × 4 cores = 8 vCPUs

For normal Windows VMs, I would keep it simple:

- 1 socket
- 2 to 4 cores to start with
- NUMA disabled

If the workload needs more CPU, increase the core count. Do not assign a large number of vCPUs unless the VM actually needs them, because more vCPUs do not always mean better performance.

NUMA mainly becomes relevant for larger VMs, especially on a dual-socket host like yours. If you create a large VM with many vCPUs and a lot of RAM, then it can make sense to enable NUMA, and possibly use a topology that reflects multiple NUMA nodes.

But for a typical Windows 10 or small Windows Server VM, I would start with 1 socket and only increase the number of cores as needed.

Also keep Windows edition/licensing limits in mind, especially with older Windows Server versions.

 

[cwt]

There is no universal “always use 1 socket and disable NUMA” recommendation. The correct configuration depends on the VM size and on the actual NUMA resource situation on the host.

Your host has two physical NUMA nodes, one per CPU socket, each with its own local memory. Ideally, a small VM can execute its vCPUs and allocate its memory within one physical NUMA node. In that case there is little reason to expose NUMA to the guest.

However, “the VM fits into one NUMA node” must not be interpreted purely from the hardware specifications.

For example, assume three smaller VMs are already running. Their QEMU processes, vCPU threads and memory allocations may already consume resources on both physical NUMA nodes. When another VM starts, there may no longer be enough CPU and/or memory available on one node to keep that VM completely local. The Linux scheduler and NUMA memory allocator then have to distribute resources, and the VM may execute on CPUs belonging to one NUMA node while accessing memory located on the other one.

That results in remote memory accesses across the UPI link, which have higher latency and consume inter-socket bandwidth.

So the relevant question is not simply:

“Does this VM have fewer than 12 vCPUs?”

but rather:

“Can the VM’s vCPUs and its memory remain local to a physical NUMA node under the current host workload?”

This is also why NUMA becomes increasingly important when a host is heavily consolidated. Even several relatively small VMs can fragment the available CPU and memory resources across the physical NUMA nodes.

Enabling NUMA in QEMU allows a NUMA-aware guest such as Windows to see a virtual NUMA topology and make better decisions about thread scheduling and memory allocation when the VM itself spans NUMA nodes. QEMU explicitly supports assigning vCPUs and RAM to virtual NUMA nodes.

The virtual CPU socket count itself does not have to match the physical socket count. Guest CPU topology and host NUMA topology are two different things.

Therefore I would use the following general approach:

Small VMs on a lightly loaded host: 1 socket, a reasonable number of cores, NUMA usually unnecessary.

Larger VMs or heavily consolidated dual-socket hosts: NUMA should be considered based on the actual host topology and resource placement.

VMs that necessarily span physical NUMA nodes: expose NUMA to the guest.

Do not simply configure 2 virtual sockets because the host has 2 physical sockets.

Likewise, do not blindly disable NUMA just because the VM itself is “small”.

And one important distinction: enabling virtual NUMA does not magically guarantee perfect host-side NUMA locality. Hard placement of vCPUs and memory is a separate subject involving CPU affinity and NUMA memory policies/binding.

So “1 socket, NUMA disabled” is a reasonable default for a small VM, but it is not a general NUMA recommendation for a dual-socket virtualization host.

A common misconception is that NUMA only matters on dual-socket systems. That is no longer true. A single-socket AMD EPYC system configured with NPS=2 or NPS=4 already exposes multiple NUMA nodes. Likewise, some Intel platforms can present multiple NUMA domains per socket. Therefore, the relevant metric is the number of physical NUMA nodes, not the number of CPU sockets.

 

[alexskysilk]

Your host has two physical NUMA nodes, one per CPU socket,

Or more. all designs based on chiplets (eg, all modern AMD) will have more then one per socket. /pedantic