Clearing the Confusion – vSphere Virtual Cores, Virtual Sockets, and Virtual CPU (vCPU)
This is a topic that I have been confused on more than once. I would read the help documentation and the VMware KB article, thought I understood it and later say “wait, what?”
First, let’s look at a host…
Analyzing Maximum vSphere vCPUs on a Host
In vSphere 5.1 (I’ll update this for future versions), you can have up to 64 vCPUs configured on a virtual machine, if you have vSphere Enterprise Plus (the number goes down as the edition of vSphere is reduced). BUT, you are also limited to assigning a maximum number of vCPUS that your physical server has available in logical CPUs.
If we take a look at one server in my lab, it’s a Dell T610 with a single physical CPU socket that has 4 cores (quad-core) and hyperthreading is enabled, which doubles the number of cores presented, for a total of 8 cores:
vCPU Confusion
What this means is that the maximum number of vCPUs that I could configure for a VM on this host would be 8. Let’s verify.
If we edit the settings of a VM on that host, we see that we can either configure it with 8 virtual sockets and 1 virtual core per socket, 4 sockets and 2 cores per socket, 2 sockets and 4 cores per socket, or 8 sockets and 1 core per socket (all of which, if you multiple, totals 8):
vCPU Properties
On another host, a Dell M610, I have 2 physical sockets, 4 cores per socket, with hyperthreading enabled, which gives me a total of 16 logical processors:
2 Physical Sockets, 4 Cores per Socket = 16 Logical Processors
If I look at a VM on that host (note that these VMs need to be hardware version 8 or above), I can configured any combination of virtual cores that total no more than 16 (could be 16 x 1, 1 x 16, 2 x 8, 8 x 2, 4 x 4, etc):
16 Maximum Cores
Now that you know the the limitations of the physical hosts and hypervisor, let’s look at why this differentiation of virtual sockets vs virtual cores is available and what you should choose.
The Guest OS Knows the Sockets and Cores
Warning! A very important part of understanding this is that when you configure a vCPU on a VM, that vCPU is actually a Virtual Core, not a virtual socket. Also, a vCPU has been traditionally presented to the guest OS in a VM as a single core, single socket processor.
What you might not have thought about is that the guest operating systems know not only the number of “CPUs” but also the number of sockets and cores that the CPU has available. As Kendrick Coleman shows in his post on vCPU for License Trickery, you can use the CPU-Z utility to find out how many sockets and cores your virtual machine has.
Does it make any difference for the performance of the applications inside if the OS thinks it has 4 sockets and 2 cores per socket or 1 socket with 8 cores? As far as I can tell, NO (but I welcome your comments). The guest OS is just scheduling the threads from each process onto a CPU core and, using the hypervisor, those virtualized threads are scheduled, by the VMkernel scheduler, on a logical CPU core of the operating system.
Task Manager Breakdown
If it doesn’t have any effect on performance, why would VMware even offered this option to specify the number of sockets per core for each VM? The answer is that it’s all related to software licensing for the OS and applications.
OS and Application Licensing Per Socket
Many (too many) operating systems and applications are licensed “per socket”. You might pay $5000 per socket for a particular application. Let’s say that Windows Server 2003 is limited to running on “up to 4 CPUs” (or sockets). Say that you had a physical server with 4 quad core CPUs, for a total of 16 cores and then enabled hyperthreading for a total of 32 logical cores. If you configured your VM to have up to 4 “CPUs”, as the license specified, those 4 vCPUs would only run on 4 physical cores. However, if you had of installed that same Windows OS on the same phsyical server, it would have run on up to 4 sockets but, with each socket having 4 cores, it would have offered up to 16 logical cores for Windows (which still not breaking your end user license agreement). In other words, you would get to use more cores and likely receive more throughput.
In the end, what you are doing here is gaining granular control over how many virtual sockets and how many virtual cores per socket are presented to each virtual machine. This way, you can ensure you get the performance you need without having to buy extra licenses and without violating your EULA.
Related Posts
Whoa! Data Center Madness Series Launches March 21st – Register Now!... March 13, 2017 | David Davis, vExpert, VCP/VCAP, CCIE
Weekly Virtualization Link Round Up: 9/13/2013... September 13, 2013 | Scott D. Lowe, vExpert, MVP Virtual Machine, MCSE
-
Hi David,
There are a few subtle performance items to watch out for when using corespersocket. Originally a license feature as stated above, it can now affect vNUMA sizing (which is automatically enabled by default for VMs over 8 vCPUs). You typically want to adhere to two basic practices:
1) Unless required by licensing limitations, you should configure the VM to use the maximum number of sockets x 1 core.
2) If you need to change from #1, the configuration should match your physical servers NUMA topology.
If you’re headed to VMworld, check out this session where one of our scheduler guru’s explains this in more detail:
-
Hey David,
as said on Twitter, nice post. I might link to it the next time someone comes up to me with questions about the socket and cores confusion 😉Just a little thing. You wrote:
“Does it make any difference for the performance of the applications inside if the OS thinks it has 4 sockets and 1 core per socket or 1 socket with 8 cores? As far as I can tell, NO”I guess it’s just a slip, since 4×1 or 1×8 will make a difference in performance?! 🙂
Tim
-
Hello,
the free VSphere 5.5 Edition has a limitation of 8 vCPU per VM.Is it possible to bypass this limitation by defining 2 virtual sockets with 6 vCPU each (6core-processor with hyper-threading) to use effective 12 vCPU in one VM?
-
In our in-house CFD application relying on MPI for parallelization. I had a dual Xeon W5580 w/o HT enabled. Thus, 2 physical sockets, each with 4 physical cores.
When I create a VM with 1 virtual socket and 8 virtual cores, I get about 60% the performance of 2 virtual sockets each with 4 virtual cores. Not sure if there are extenuating circumstances here, but that was my experience.
-
Hi,
Thank you for your valuable post, @OMAR do you mean performance is better when you use single socket within it cores ?
Basem
-
Hi, great post for sure!
A VM with 1 socket/1 core on a server with xeon 6 cores with HT (so 12 vcpus) will it run in low performance? Under hypervisor (esxi 5.5) I can see 12 cores used but when I benchmark cpu under the VM it’s really under average results! (vm is alone)
You talk about difference between 1socket-8cores and 8sockets-1core but nothing about 1socket/1core and others. I thought (perhaps I think too much:) that esxi kernel was using cores if needed unless vcpus were indicated…
Thanks again for this post about vcpus.
Mopios.
-
Hi!
I would like to speed up my CPU
If I use wmware and create cpu and virtual cores, would my processor speed up?
Sorry I’m ignorant of this field but help me understand what it is for.
My processor is INTEL core I5 4210U 1.7ghz 2 cores there is a chance to speed it up and create more cores to process heavy software ?.
Thank you for answering. -
Hi. How does NUMA figure in to this? If the workload is limited to in this case, 1 socket x 8 , then doesn’t it limit it from having to use remote memory allocated between 2 sockets x 4. By this I mean all tasks are localized on one socket with the memory mapped to that NUMA node, making it perform better in theory? Or does it not work that way.
Thanks in advance.
-
Always spend a few minutes to understand your physical servers NUMA topology and leverage that when rightsizing your virtual machines.
Recommended Practices
#1 When creating a virtual machine, by default, vSphere will create as many virtual sockets as you’ve requested vCPUs and the cores per socket is equal to one. I think of this configuration as “wide” and “flat.” This will enable vNUMA to select and present the best virtual NUMA topology to the guest operating system, which will be optimal on the underlying physical topology.#2 When you must change the cores per socket though, commonly due to licensing constraints, ensure you mirror physical server’s NUMA topology. This is because when a virtual machine is no longer configured by default as “wide” and “flat,” vNUMA will not automatically pick the best NUMA configuration based on the physical server, but will instead honor your configuration – right or wrong – potentially leading to a topology mismatch that does affect performance.
Submit a Comment
Top Tool Downloads
-
Getting Chippy: Intel vs. AMD in 2019
January 3, 2019
February 28, 2018
Comments