Rappelons que (dans ce contexte) le vNUMA est la capacité de présenter à la VM une topologie NUMA identique à celle de sa VMM. Cette technique permet au guestOS d’optimiser lui même la répartition process/node pour éviter au maximum les accès à des pages qui ne seraient pas dans le noeud où se trouve le vCPU qui y accède (aka remote access).

L’idéal serait un des schémas percutant dont Frank Denneman à le secret mais il va falloir vous contenter de cela : le vNUMA est le WYSIWYG transposé au NUMA donc la topologie NUMA que la VM “voit” est véritablement celle de sa VMM.

Présente depuis ESX 5.0, cette fonctionnalité n’est active par défaut que pour les VM avec *strictement* plus de 8 vCPU (=>9 et non 8+) mais VMware indique comment l’activer pour les VM plus petites :

By default, vNUMA is enabled only for virtual machines with more than eight vCPUs. This feature can be enabled for smaller virtual machines, however, by adding to the .vmx file the line: numa.vcpu.maxPerVirtualNode = X (where X is the number of vCPUs per vNUMA node).

Ce qui est à moitié vrai car avec ce paramètre vous ne forcez que la répartition des vCPU par vNode (topologie présentée à la VM) et non celle des vCPU par pNode (topologie réelle). Heureusement VMware documente plutôt généreusement (en général) et nous avons trouvé l’autre moitié de la réponse dans le Documentation Center :

numa.vcpu.maxPerMachineNode Maximum number of virtual CPUs that belong to the same virtual machine that can be scheduled on a NUMA node at the same time. Use this attribute to ensure maximum bandwidth, by forcing different NUMA clients on different NUMA nodes.

Résultat, même avec 2 vCPU on peut faire du beau vNUMA (avec un beau oneliner) :

Get-VM|?{$_.NumCpu -eq 2}|Get-View|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=@((New-Object VMware.Vim.optionvalue -Property @{Key="numa.vcpu.maxPerVirtualNode";Value="1"});(New-Object VMware.Vim.optionvalue -Property @{Key="numa.vcpu.maxPerMachineNode";Value="1"});(New-Object VMware.Vim.optionvalue -Property @{Key="cpuid.coresPerSocket";Value="1"}))}))}

Et on a même fait des bench (sur un Intel E7520) avec Sandra 2013 pour voir s’il pouvait y avoir un gain (vNUMA en bleu, vUMA en rouge) !

Le gain est mince (contrairement aux grosses VM pour faire du HPC) mais sur un host bien overcommité cela peut avoir un véritable intérêt (avant/après) :

Nous avons eu la chance d’avoir l’avis de Seongbeom Kim (Senior Member of Technical Staff chez VMware) sur l’intérêt d’une telle manipulation et sur la raison pour laquelle, contrairement à Hyper-V, vNUMA n’est pas actif par défaut sur les petites VM :

Based on your two charts, enabling vNUMA looks good by not migrating memory across NUMA nodes, resulting in 100% local memory.

One consideration should be whether your workload benefits from cache sharing or not. By forcing vcpus scheduled on two or more NUMA nodes, workload with heavy cache sharing may suffer performance loss even with better memory latency.

For a new VM*, it may pay off to try vNUMA for your VM if #vcpus is greater than the number of cores per NUMA node. The benefit heavily depends on the workload behavior.

[...] modern processors have enough number of cores to place 2 – 4 vcpu VM on a NUMA node where vNUMA has no benefit. Even 8 cores per NUMA node is not rare.

Par “nouvelle VM”, Seongbeom sous entend qu’il y a un risque que le changement de topologie NUMA ait un impact sur le GuestOS et/ou l’application hébergée dans la VM.