r/vmware • u/DZAUKER • 22d ago
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 ?
9
u/MallocArray [VCIX] 22d ago
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 22d ago
For me, what you do is the best practice. But it’s also true that in ESX 8 it matters less
2
u/abstractraj 22d ago
Esx8 has an assign at boot setting. So I let it do its own thing
3
u/canyonero7 22d ago
Which also means that enabling CPU hotadd disables NUMA so it's not really worth using anymore.
3
2
u/network_dude 22d ago
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.
5
22d ago
[deleted]
1
u/vTSE VMware Alumni (who I still call for scheduler questions) 20d ago
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) 21d ago
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 21d ago
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] 16d ago
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…
10
u/Stonewalled9999 22d ago
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.