Turbo Tip: CPU Sizing – Cores vs. Sockets

Document created by will.searle on Aug 16, 2016Last modified by will.searle on Aug 16, 2016
Version 2Show Document
  • View in full screen mode

I recently got a question around how Turbonomic resizes vCPUs within VMs on VMWare.  The customer received a decision inside of Turbonomic to bring a VM from 4vCPUs to 5vCPUS.  This VM in particular was running 4 cores per socket (…not the typical flat configuration of 1 core per socket).  After Turbonomic executed the resize action the VM was configured at 2 sockets with four cores each, so 8vCPUs in total.  This sparked curiosity why Turbonomic recommended to bring a VM to five cores yet end up allocating eight.  So how exactly does Turbonomic resize vCPU?


First, let’s take a deep dive into VMWare configuration settings for core allocation.   The default ratio for cores per socket is 1:1; however, vSphere allows you to reconfigure this value*. This is useful for licensing restrictions (windows, NUMA, etc.) where you can limit a VM to a single socket but give it more processing power.  In VMWare, VMs behave just like physical servers where logical chips are always configured in powers of two.  In other words, each socket can have 1, 2, 4, 8, … ,or even 32 :D. Mixing sockets with different numbers of cores, while possible in principle, doesn’t appear to be allowed in practice.


As far as guests are concerned, they see the exact number of cores and sockets the machine they are running on has.  By default, the values reflected to the guests match the actual hardware given to the machine, but it doesn’t have to.  For example, you can assign the VM four one-core sockets, but tell the guest that it is on a machine with one socket and four cores.  In addition to the benefits this provides around licensing restrictions, there are many blog posts and documents that explain optimization improvements around multicore configurations.  Overall, altering how resources are presented to the guests can offer performance improvements but is rarely done.


With all that said, the number of cores per socket ultimately imposes constraints on how Turbonomic resizes VMs.  Consider a VM that has four cores and there is one core per socket.  You can grow or shrink this VM to any integer value you want. If the cores per socket ratio on this VM was 2 cores per socket, it could not grow to 5 cores.  Why? Because then the VM will have an unequal number of cores per socket – which we stated earlier is possible but not allowed in practice.

__2__   __2__    __1__


This VM would have to grow to 6 cores instead.  Likewise, if this VM had a ratio of 4:1 then it would need to grow to eight cores.  If you violate these rules then the resize action will fail inside of vSphere. These laws are standards that Turbonomic tests for when resizing machines.

In the initial scenario in the customer’s environment, the market requested an additional core but because of the cores-per-socket ratio we had to add another socket with four cores (otherwise the action would fail and the VM would remain powered off until manual intervention).  This is a much better outcome then changing the ratio on the VM to one core per socket and adding an additional socket.  I am sure if you changed the default cores-per-socket configuration inside of vSphere it was for a good reason; thus, Turbonomic will respect these configuration changes.  As a result, VMTurbo allocated another socket to the VM bringing it to 8 cores and two sockets and maintaining the compliance instrumented on the VM by the operator. 



*It is important to note than when you change the default parameters it disables the hot-add functionality

1 person found this helpful