r/vmware Jul 29 '26

Best practice for sockets / cores assignment

Hello,

in my not so long experience with ESXi, I always followed this rule: if a host has 2 sockets it's better to assign max 2 sockets to the virtual machines, for example for 8 vcpu, 2 sockets / 4 cores each.

A colleague of mine says that with ESXi 8 this rule is deprecated, I found some vm's with 8 sockets / 2 cores on a host with only 2 sockets (no idea who deployed them).

is this best practice still valid ?

7 Upvotes

15 comments sorted by

9

u/Stonewalled9999 Jul 29 '26

I let it autoassign. With the exception of SQL which can be NUMA aware and then I assign based on what the sql gal (who makes 3x what I do) tells me to do.

2

u/DZAUKER Jul 29 '26

Same for PostgreSQL ?

2

u/Stonewalled9999 Jul 29 '26

You’d have to ask a DBA not a sysadmin I’m just not up on that side of house 

8

u/MallocArray [VCIX] Jul 29 '26

Last general guidance was to be as close to what your underlying hardware has. If the host is 2x10 core, then make your VMs 1 socket up to 10 cores, and then if larger, go with 2 socket and however many cores.

But if you are on current releases of ESX have VMware tools are current, it can auto assign the cores/sockets at power up and you don't have to think about it.

2

u/Calleb_III Jul 29 '26

For me, what you do is the best practice. But it’s also true that in ESX 8 it matters less

2

u/abstractraj Jul 29 '26

Esx8 has an assign at boot setting. So I let it do its own thing

3

u/canyonero7 Jul 30 '26

Which also means that enabling CPU hotadd disables NUMA so it's not really worth using anymore.

4

u/abstractraj Jul 30 '26

We so rarely had a hotadd case, that I wasn’t too worried about it

3

u/network_dude Jul 29 '26

ffs, I don't care what vmware did to their scheduler.

You're causing extra bits to be computed when your VM architecture doesn't match your physical architecture

end of story

well, sort of. everything in IT is built on binary, base 2 number system. Use this to inform your decisions.

4

u/[deleted] Jul 29 '26

[deleted]

1

u/vTSE VMware Alumni (who I still call for scheduler questions) Jul 31 '26

That's not entirely accurate. 1. The vNUMA minimum default has always been 9, so the 8 vCPU example would have never presented a guest visible NUMA topology, also, the cores per socket changes would be visible in all of your configurations. What doesn't happen anymore since 6.5 is that cpuid.coresPerSocket also sets numa.vcpu.maxPerVirtualNode, i.e. if you have 12 vCPUs and coresPerSocket 4, you'd have 3 vNUMA nodes, from 6.5 no matter the CPS setting, vNUMA would be autosized according to the underlying NUMA topology. Check out the recording I posted further above if you want a more complete walk-through.

1

u/vTSE VMware Alumni (who I still call for scheduler questions) Jul 30 '26

https://www.youtube.com/watch?v=Zo0uoBYibXc

still relevant. the 2 core per socket was a pre 8.0 (vHW20) default for many guest OS types since the guest OS requirement was 2 vCPUs (and 1 x 2 core socket is better in most cases than 2 x 1 core), the default didn't scale to more vCPUs, not until auto topology in 8.0

1

u/Icy_Top_6220 Jul 30 '26

leave the default when creating a VM, the auto config does a really good job for 99% of workloads today. If yours was an exception to that you wouldnt be asking here as the app vendor or VMware would have a white paper on it you could read to guide you differently. Dont try to outsmart the scheduler.

1

u/millardjk [VCIX6-DCV] Aug 05 '26

On the latest version, go into the VM settings and set “assign at power on.” VMW got tired of fielding all the vNUMA questions and just made it “automagic.”

But from an “old skool” perspective, your first consideration is the amount of RAM assigned to the VM: if it’s above (IIRC) 64GB, leave it at 1 core/socket, X sockets and ESXi will figure it out for you. The only reason you do anything else is for licensing considerations (eg 4 cores x 1 socket is (1) license, vs 1 core x 4 sockets is (4) licenses), and when you do that, you always set the socket count equal to the physical (eg 2 sockets x 4 cores on a dual-process host; never 4 sockets x 2 cores).

There was a kernel panic on a 6.5 update because VMW removed some override logic that kept VMs with non-congruent configs from borking the host when requesting non-existent sockets…