Translate in Your language

Saturday, 19 May 2018

vNUMA: VMware vSphere 6.5

In vSphere 6.5, changing the cores per socket value no longer influences vNUMA or the configuration of the vNUMA topology. The configuration of vSockets and cores per socket only affects the presentation of the virtual processors to the guest OS, done generally for guest OS licensing purpose. 

vNUMA will automatically determine the proper vNUMA topology to present to the guest OS based on the underlying ESXi host. 

For example, lets assume that we create a 4-vSocket virtual machine with 4 cores per socket (i.e. total of 16 vCPU) on a ESXi host that has dual-socket-16-core per socket. Prior to vSphere 6.5, vNUMA would have created 4 vNUMA nodes based on the cores per socket setting. 

As of vSphere 6.5, the guest OS will still see 4 sockets and 4 cores per socket, but vNUMA will now only create 1 vNUMA node for the entire virtual machine since it can be placed in a single physical NUMA node. 

This new disconnection of the cores per socket setting with vNUMA allows vSphere to determine the best vNUMA topology automatically in all circumstances.

In case you still want to revert to the earlier behavior in vSphere 6.0, use the advanced setting:

numa.FollowCoresPerSocket = 1

For more Information concerning vNUMA can be found in the following articles:


  1. Hi,

    Please correct me in case my understanding is wrong

    As per my understanding, the numa comes into picture only when we make out of bound VMs

    i.e if we need 20vCPU say for running a VM in above server, Creating 2 Socket 10 vCPU is advisable so that 2 Numa Nodes are used and proper scheduling can be done.
    4 Socket 5 CPUs will still make two NUMA,

    you get advantage of 2x10 design over 4x5 design , in applications where you have similar kind of workload for each thread, in case your workload is not similar say you have some threads which will finish earlier than others 4x5 design is suitable so as to reduce costop

    1. That is correct in case of 20 CPU scenario. Talking about NUMA, if your VM has upto 8 vCPU, it is considered as wide NUMA SMP VM, once you go beyond 8 i.e. 9 or more, vNUMA comes into play. For multi-threading, even if any pCPU is getting ahead or lagging which creates SKEW, CPU schedular takes care of it by running de-Skew.

  2. As per Article of the Frank, only think added is concern for RAM too..

    For example you have say 128 GB ram per Pnuma node on a two socket server, and you need to create a 16vCPU 192GB VM, then you should create 2 psocket 8 core VM so that two numa nodes can be created and scheduling can be done on two pnuma

  3. In vSphere 6.5, NUMA balancing is significantly improved compared to 6.0.
    Therefore, it is sufficient to avoid explicitly incorrect configurations that create an odd number of NUMA (3 nodes).



Popular Posts This Week