I get this question regularly, and after having just typed up another long answer to the question, I’m going to share the answer here for future reference 🙂
The question usually goes something like this: “What is the performance impact of allocating 1 socket and 4 cores when I build a VM versus allocating 4 sockets with 1 core each?” This person is using the old vSphere Client, and has seen this option which was added for a great reason, but assuming something false about its purposes.
First and foremost: on a small (less than 8 vCPU) VM, there is no performance impact of setting it one way or another. Because the hypervisor schedules the resources on the back end, it really doesn’t matter what configuration they’re presented to the guest OS in, at least not from a performance perspective. So stop worrying about it 🙂 With that being said, why does this option exist?
The reason you used to have the option to select sockets vs. cores was to get around a limitation in the guest OS. For example, Server 2008 will only use up to 4 physical CPUs. By increasing the number of cores per socket, you can raise the number of CPUs the guest OS will allow you to use (since it seems them as cores). The one consideration to keep in mind is that if there isn’t a reason to trick the guest OS using cores, scale VMs using the socket setting. The number of virtual sockets can/will affect vNUMA calculations.
Update: one clarification in light of Jim’s comment below. Be aware that while using cores per socket to fool the guest OS for licensing purposes, you DO run the risk of swaying the vNUMA calculations in a way that can negatively impact performance. In a small VM, it will be contained within a single NUMA node and you’re probably safe. But when a larger VM spans multiple NUMA nodes, you are at risk of adversely swaying the calculations by increasing the core count. Please read the comment for more depth!
Also, major trolling on Twitter after this was posted 🙂
— Christopher Kusek (@cxi) January 26, 2015