Nous avons alors utiliser vmkfstools pour créer un vmdk eagerzeroedthick et constater l’offload de création de zero mais il semble que ce ne soit pas fonctionnel (ZERO_F) :

Par contre, le UNMAP (vmkfstools -y 99) semble bien fonctionner :

Nous profiterons du VMworld 2013 pour demander à Cormac Hogan si cela signifie qu’ESXi supporte le TRIM, entre autres…

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.

MAJ 19/04/2012 : Modification du script pour afficher nom du server et le status dans l’objet du mail

Le coup du PCPU Used vs PCPU Util c’est un classique de Krishna Raj (grand maître d’esxtop) aux VMworld pendant la session “esxtop for advanced users”. Il s’agit d’une situation où la consommation cpu “théorique” (basé sur la fréquence de base du cpu) est différente de la consommation ”réelle” (basée sur la fréquence courante du cpu). Les exemples de troubleshooting des sessions de Krishna sont lié à l’Hyperthreading et aux mécanismes qui permettent aux cpu de baisser leur fréquence pour économiser de l’énergie.

En fervents adeptes d’esxtop, nous avons tout de suite remarqué l’anomalie décrite par Krishna lors d’une séance de troubleshooting :

Le problème c’est que nous n’étions pas dans esxtop pour ça et, pire, aucune alarme ne nous était parvenue. Et pour cause, c’est le compteur “usage” qui est utilisé par vCenter et non pas “coreUtilization” :

Après investigation, il s’agissait d’une mauvaise configuration ACPI/C-State dans le BIOS et comme nous ne sommes pas infaillibles, nous nous avons pondu un petit oneliner PowerCLI pour créer une alarme qui se base sur le compteur coreUtilization :

(Get-View AlarmManager).CreateAlarm((Get-Folder -NoRecursion |Get-View).MoRef,(New-Object VMware.Vim.AlarmSpec -Property @{Name = "Host core usage";Description = "Custom alarm to monitor core Utilization";Enabled = $true;expression = (New-Object VMware.Vim.OrAlarmExpression -Property @{expression = @((New-Object VMware.Vim.MetricAlarmExpression -Property @{Metric = (New-Object VMware.Vim.PerfMetricId -Property @{CounterId = ((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "cpu"}|?{$_.nameinfo.key -match "coreUtilization"}|?{$_.RollupType -match "average"}).key;Instance = ""});Operator = "isAbove";Yellow = "7500";YellowInterval = "300";Red = "9000";RedInterval = "180";Type = "HostSystem"}))});Action=(New-Object VMware.Vim.GroupAlarmAction -Property @{Action= (New-Object VMware.Vim.AlarmTriggeringAction -Property @{Action = (New-Object VMware.Vim.SendEmailAction -Property @{ToList = "admin@vmware.local";Subject = "[vAlarm] {targetName} core usage is {newStatus}";CcList = "";Body = ""});TransitionSpecs = @((New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "green";FinalState = "yellow";Repeats = $false});(New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "yellow";FinalState = "red";Repeats = $true}))})});ActionFrequency = "1800"}))

Les seuils sont les mêmes que pour l’alarme “Host CPU Usage”, à savoir 75/90, mais nous avons réduit le temps pour l’alerte (red) à 3min au lieu de 5.

Pour une raison obscure mais bien réelle, l’alarme “Virtual machine total disk latency” n’est pas fonctionnelle :

The default Virtual Center Alarm for Virtual Machine Total Disk Latency is currently not functioning on VMware vCenter Server 4.0 and VMware vCenter Server 4.1.

There is no workaround at this time.

Grâce au PowerCLI (et aux nombreux posts de Luc), il existe une alternative : le compteur disk.maxTotalLatency.latest

Highest latency value across all disks used by the host. Latency measures the time taken to process a SCSI command issued by the guest OS to the virtual machine. The kernel latency is the time VMkernel takes to process an IO request. The device latency is the time it takes the hardware to handle the request.

Nous avons créé un petit script pour l’occasion qui créer une alarme “custom” afin de détecter une latence trop élevé sur l’un des datastore (en mode block uniquement, par pour le NFS donc) d’un ESX :

Ce script s’utilise comme suit :

.\Set-MaxTotalLatencyAlarm.ps1 -YellowTresh 20 -RedTresh 40

YellowTresh et RedTresh représentent les seuils Warning/Alert de l’alarme (30/50 par défaut si non renseignés à la création de l’alarme).

Il sera nécessaire de supprimer/recréer l’alarme pour changer ces valeurs

Après c’est à vous de jouer pour trouver le datastore qui pose problème…

download

En faisant un monkey test sur esxtop , nous avons découvert des fonctionnalités “cachées” qui vont changer vos talents de troubleshooter (ESX/ESXi 4.0+ uniquement) :

Les touches “2” et “8” permettent de sélectionner et mettre en surbrillance une “ligne” :

La touche “6” permet de déveloper (l’équivalent de “e”) une “ligne” selectionée à l’aide des touches précédemment citées :

La touche “4” permet de “locker” l’affichage et de supprimer la “ligne” sélectionnée de l’affichage en cours (non, ca ne kill pas le process !) :

La touche “i“, affichent les interruptions  :

Indispensable pour un troubleshooting efficace