By restricting ESXi Shell access for the vpxuser, you prevent attackers, which can also be insiders who have access to vCenter Server the ability to just change the ESXi root password without knowing the original password.

Après l’énorme succès de notre billet Administrators = root qui vous permet de reset le mot de passe root de vos ESX sans le connaître (si vous êtes admin du vCenter) grâce à Get-EsxCli, voici une nouvelle méthode utilisable depuis vSphere 6.7 U2 qui nécessite encore moins de droits :

Updates a local user account using the parameters defined in the HostLocalAccountManagerAccountSpecification data object type.

Required Privileges Host.Local.ManageUserGroups

(Get-View (Get-VMHost|Get-View).ConfigManager.AccountManager).UpdateUser($(New-Object VMware.Vim.HostAccountSpec -Property @{id="root";password="VMw4re!"}))

Attention, contrairement à la méthode Get-EsxCli, cette fois un petit event va vous trahir instantanément :

Pour résumer, nous avions besoin d’exécuter un script situé sur un share depuis un ensemble de VM et nous avons bien évidement tenté de profiter du fait que VIX supporte le SSO, comme des gros fainéants. Et là, c’est le drame:

When using Integrated Security, anonymous access is disabled, and impersonation is turned on, a security measure kicks in and doesn’t allow your site to access resources on any network servers.  This includes access to a UNC path directly from IIS or SQL Server using Windows authentication.

Il nous a suffit de passer les credentials à l’Invoke-VMScript pour que l’UNC devienne accessible:

Nous avons ajouté la taille de la VM pour vous motiver à faire un VeeamZIP et à en finir définitivement avec ces VM qui risque d’être redémarrées après un crash d’ESX…

get-view -viewtype virtualmachine -property name,runtime,layoutex|?{$_.Runtime.PowerState -eq "poweredOff" -and $_.Runtime.ConnectionState -eq "connected" -and !$_.config.template}|?{$_.LayoutEx.File|?{$_.type -match "nvram"}}|%{$_|select Name, @{n="Modification";e={((get-view (get-view -viewtype datastore –filter @{"Name"=($_.LayoutEx.File|?{$_.type -eq "nvram"}).name.split("[]")[1]}).browser).SearchDatastore(($_.LayoutEx.File|?{$_.type -eq "nvram"}).name.split("/")[0],(New-Object VMware.Vim.HostDatastoreBrowserSearchSpec -property @{matchPattern=("*.nvram"); details=(New-Object VMware.Vim.FileQueryFlags -property @{modification=$true})}))|%{$_.file}).Modification}}, @{n="SizeGB";e={[math]::round(($_.LayoutEx.File|measure -Property size -sum).sum/1GB,1)}}}

In Virtual SAN 6.2, we introduced an advanced host setting called SwapThickProvisionDisabled, when enabled, removes the space reservation for .vswp files.

Une preuve de plus, s’il en fallait, que la bataille du SDS/HCI est rude jusqu’à en rogner ses best practices. En effet, nous rappelons à ceux qui auraient un trou de mémoire que placer le fichier de swap d’une VM sur un stockage “thin provisioné” va à l’encontre de toutes les bonnes règles de gestion et d’overcommit.

Do not store swap files on thin-provisioned LUNs. Running a virtual machine with a swap file that is stored on a thin-provisioned LUN can cause swap file growth failure, which can lead to termination of the virtual machine.

Regardless of the storage type or location used for the regular swap file, for the best performance, and to avoid the possibility of running out of space, swap files should not be placed on thin-provisioned storage.

Qu’importe, ca nous arrange bien aussi et pour l’occasion nous avons fait peter un petit oneliner pour fixer la bonne valeur :

Get-VMHost|%{(Get-EsxCli -VMHost $_).system.settings.advanced.set($null,"1","/VSAN/SwapThickProvisionDisabled",$null)}

Et un autre pour vérifier que c’est bien appliqué :

Get-VMHost|%{(Get-EsxCli -VMHost $_).system.settings.advanced.list($null,"/VSAN/SwapThickProvisionDisabled",$null)}

Avec un petit coup de SexiGraf pour monitorer le tout, on est bon :

$i=0
$pre = '{"fields" : ["message"],"from":'
$post = ',"size": 2000,"query":{"filtered":{"query":{"bool":{"should":[{"query_string":{"query":"hostname.raw:esx.vmware.com"}}]}},"filter":{"bool":{"must":[{"range":{"@timestamp":{"from":1450738800000,"to":1450997999999}}}]}}}}}'
$msgs=1

while ($msgs) {
$msgs=$false
$body = $pre + $i + $post
$msgs=(Invoke-RestMethod -URI "http://demo.sexilog.fr:9200/_search?pretty=1" -Method 'POST' -ContentType 'application/json' -Body $body -TimeoutSec 5).hits.hits.fields.message
$msgs|%{$_.Trim()}|Out-File -FilePath c:\temp\esx.vmware.com.log -Append
$i=$i+2000
}

Il convient de remplacer les FQDN esx.vmware.com et demo.sexilog.fr par les vôtres et d’ajuster les valeurs from/to en epoch.

Le script extrait tous les messages pour le serveur donné, sur la période donné vers un fichier de log par batch de 2000 :

Et une fois l’export terminé, le script se termine par une erreur “attendue” :

A titre indicatif, il a fallut 1h pour extraire 1Go de log. Egalement dispo sur GitHub si besoin.

En effet, à la lecture du titre de cette news “Using PowerShell Direct and other new features in Hyper-V on Windows 10” on s’attend clairement à un truc révolutionnaire. Vous ne pouvez pas dire le contraire, “Powershell Direct” ça claque !

Alors, naïfs, on se précipite sur TechNet pour en savoir plus ! Mais là, comme pour le coup du Smart Paging, c’est le drame :

It is a new way of running PowerShell commands inside a virtual machine from the host operating system easily and reliably
[...]
Note: This only works from Windows 10/Windows Server Technical Preview Hosts to Windows 10/Windows Server Technical Preview guests.

Bon là on ne va pas y aller par 4 chemins, on est sur du réchauffé++ car je rappel pour ceux qui n’étaient pas encore nés que cette feature existe chez VMware depuis 2009 :

Invoke-VMScript: Runs the specified PowerShell script in the guest OS of each of the specified virtual machines.

Et depuis 2011, elle supporte le SSO :

All VIX cmdlets support using SSPI for Windows guest machines if the underlying vCenter Server is 5.0 version. This might not be valid for users who are local, and not domain users. VIX cmdlets are Invoke-VMScript, Copy-VMGuestFile, *-VMGuestNetworkInterface, *-VMGUestRoute, and Set-HardDisk when used for guest disk resizing.

Et pour ceux qui l’ignorait, ce n’est évidement pas limité à Windows comme c’est le cas d’Hyper-V :

ScriptType: Specify the type of the script. The valid values are PowerShell, Bat, and Bash. If the virtual machine OS is Windows, the default value is PowerShell. If the virtual machine OS is Linux, the default value is Bash.

Nous étions parti pour utiliser le script disponible sur VSANTeam.info mais il est malheureusement faux car il n’inclus pas l’objet VsanHostDecommissionModeObjectAction et donc le mode “ensureObjectAccessibility” est utilisé par défaut. Donc pour pouvoir utiliser le mode “evacuateAllData” ou “noAction” c’est comme ça qu’on fait :

Get-View -ViewType HostSystem -Filter @{"Name" = "esx.vmware.com" }|?{!$_.Runtime.InMaintenanceMode}|%{$_.EnterMaintenanceMode(0, $false, (new-object VMware.Vim.HostMaintenanceSpec -Property @{vsanMode=(new-object VMware.Vim.VsanHostDecommissionMode -Property @{objectAction=[VMware.Vim.VsanHostDecommissionModeObjectAction]::NoAction})}))}

Sinon vous pouvez aussi le faire avec Get-EsxCli en vous inspirant du post de William.

Historiquement, il était un peu complexe de générer ce genre d’interruption comme le détail William mais avec cette nouvelle API cela devient un jeu d’enfant en PowerCLI :

(Get-VM toto|Get-View).SendNMI()

Malheureusement, connecté au vCenter, on se mange une jolie erreur :

Exception calling “SendNMI” with “0″ argument(s): “The requested operation is not implemented by the server.”

Connecté en direct sur un ESX ça se passe nettement mieux :

En prime, on droit au nouvel événement VmGuestOSCrashedEvent :

<166>NoneZ visor04.lab.schitz.org Hostd: 2015-06-04T22:21:45.933Z info hostd[6DE83B70] [Originator@6876 sub=Vimsvc.ha-eventmgr] Event 894 : Win10 on visor04.lab.schitz.org: Guest operating system has crashed.

Que ce soit pour créer de nouvelles alarmes dans le vCenter ou parce que certains messages d’alerte ne sont visible que dans les logs d’ESXi, nous avions autrefois recours à la page vCenter Events de Veeam pour trouver l’inspiration. Cette page n’étant plus mise à jour depuis fin 2011, nous avons chercher à produire un page similaire pour nos propres besoins et l’avons, depuis quelques temps, mise à dispo dans la rubrique “Links”. Voici la commande PowerCLI qui vous permettra de générer la votre depuis votre vCenter (et plugins) :

(Get-View EventManager).Description.EventInfo|select @{n="event";e={if ($_.key -match "^EventEx$|^ExtendedEvent$") {$_.FullFormat.split("|")[0]} else {$_.key}}},category,description,FullFormat|Out-GridView

Nous nous sommes très largement inspiré d’un post de Luc pour ce oneliner

Récemment, William à posté une liste similaire issue d’un fichier disponible en clair dans les librairies d’ESXi mais nous avons remarqué qu’il ne contenait pas les événements vob.* que nous pouvions trouver dans les logs. Après quelques recherches, nous avons fini par faire un coup de strings sur le binaire /usr/lib/vmware/vob/bin/vobd (issue d’un ESXi 5.5 1331820) pour en extraire les précieux messages. Nous avons ensuite “dédoublonné” la liste obtenue (vob.vmfs.heartbeat.timedout == esx.problem.vmfs.heartbeat.timedout par exemple) pour ne garder que le différentiel :

vob.net.fence.port.fail
vob.net.pg.uplink.transition.down
vob.net.pg.uplink.transition.up
vob.net.dvport.uplink.transition.down
vob.net.dvport.uplink.transition.up
vob.net.uplink.watchdog.timeout
vob.net.migrate.bindtovmk.failed
vob.net.portset.port.connect.fail
vob.net.lacp.uplink.peer.noresponse
vob.scsi.scsipath.add
vob.scsi.scsipath.remove
vob.scsi.scsipath.por
vob.scsi.scsipath.badpath.unsafepe
vob.scsi.scsipath.badpath.unreachpe
vob.scsi.scsipath.pathstate.dead
vob.scsi.scsipath.pathstate.off
vob.scsi.scsipath.pathstate.on
vob.scsi.scsipath.pathstate.standby
vob.iscsi.connection.started
vob.iscsi.connection.stopped
vob.iscsi.connection.error
vob.iscsi.target.async.event
vob.iscsi.session.recovery.timeout
vob.iscsi.target.permanently.removed
vob.iscsi.isns.discovery.error
vob.vmfs.lock.corruptondisk.v2
vob.user.dcui.factory.network.restored
vob.user.dcui.restarting.hostagents
vob.user.dcui.restore.factory.defaults
vob.user.dhclient.lease.offered.noexpiry
vob.user.coredump.unconfigured2
vob.user.coredump.capacity.insufficient
vob.user.scratch.partition.size.small
vob.user.scratch.partition.unconfigured
vob.user.dcui.reboot.host
vob.user.dcui.shutdown.host
vob.user.esxcli.host.reboot
vob.user.coredump.configured2
vob.cpu.mce.log
vob.cpu.nmi.ipi.vmkcs
vob.cpu.nmi.ipi.unknowncs
vob.cpu.nmi.ipi.halt
vob.cpu.nmi.ipi.savebt
vob.uw.core.dumped
vob.external.warning
vob.external.error
vob.external.info
vob.user.external.warning
vob.user.external.error
vob.user.external.info
vob.visorfs.tardisk.readonlyfile
vob.vsan.pdl.offline
vob.vsan.pdl.online
vob.vsan.net.gotip
vob.vsan.net.noip
vob.vsan.rdt.noip
vob.vsan.net.no.connectivity
vob.vsan.net.created
vob.vsan.net.reconfigured
vob.vsan.cmmds.disabled
vob.vsan.cmmds.unloaded
vob.vsan.cmmds.enabled
vob.vsan.lsom.diskerror

Pour les curieux, voici la liste originale.

La seule référence que nous ayons pu trouver à ce sujet est une kb d’un path pour ESXi 5.0, dommage.

En passant, nous vous rappelons qu’il est possible de rediriger le log d’une VM vers le syslog d’ESXi pour vous éviter de fouiller dans le fichier vmware.log et c’est bien sûr faisable à chaud en PowerCLI (comme d’hab, vmotion pour appliquer le setting) :

Get-VM toto|Get-View|?{-not $_.Config.Template -and $_.Runtime.ConnectionState -eq "connected"}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=@((New-Object VMware.Vim.optionvalue -Property @{Key="vmx.log.destination"; Value="syslog-and-disk"}))}))}

Après on peut faire des belles requêtes dans son Graylog2 :

Un grand merci à William pour cette pépite.

Premier constat, le temps de compute des valeurs moyennes de cpu et ram est très important et c’est évidement proportionnel au nombre de nœuds. Pour optimiser ce script, nous nous somme rabattu sur les quickstats du resource pool “racine” du cluster (aka “resources”). Ces valeurs étant basé sur les 5 dernières minutes d’activité (et non sur les 24 dernières heures comme le script original), il faut l’exécuter au moment de la journée où l’activité du cluster est la plus importante pour avoir des valeurs vraiment représentatives du workload. Le gros avantage de ces valeurs est qu’il n’est pas nécessaire de faire une requête dans les statistiques, elles sont pré-computées et disponibles sous forme de propriétés, on passe donc d’une exécution pouvant aller jusqu’à plusieurs minutes à 2 secondes par cluster. Comme dirait Mozinor, “tu peux pas test”.

Deuxième constat, le mode “slot size” d’admition control ne tiens pas compte de l’overcommit. Duncan et Frank l’explique en détail dans leur bouquin mais voici un exemple encore plus parlant :

3 hosts sur 12 (25%) en mode “slot size” contre 67% en mode “resources”. Dans ce dernier mode, HA tiens compte de la consommation réelle du cluster pour déterminer ce qu’il reste.

With the resources failover policy in place, vSphere HA uses the following calculations to control virtual machine migration in the cluster
1. Calculate the total resource requirements for all powered-on virtual machines in the cluster.
[...]

Il est donc clair que sur des gros cluster avec de l’overcommit, le mode “slot size” est totalement inutilisable.

En attendant de déguster la dinde farcie aux marrons de tante Yolande, voici le oneliner powershell à deguster en amuse-bouche :

foreach ($cluster in (Get-View -ViewType ClusterComputeResource|?{$_.ConfigurationEx.DasConfig.Enabled})) {,($cluster|?{$_.host}|select @{n="mem";e={(($_|%{(Get-View $cluster.ResourcePool|?{$_.Parent -eq $cluster.Moref}).Summary.QuickStats.HostMemoryUsage/(Get-View -ViewType virtualmachine -SearchRoot $cluster.moref -Property Runtime.PowerState|?{$_.Runtime.PowerState -eq "poweredOn"}).count}))}}, @{n="cpu";e={(($_|%{((Get-View $cluster.ResourcePool|?{$_.Parent -eq $cluster.Moref}).Summary.QuickStats.OverallCpuUsage)/(Get-View -ViewType virtualmachine -SearchRoot $cluster.moref -Property Runtime.PowerState|?{$_.Runtime.PowerState -eq "poweredOn"}).count}))}}, @{n="vcpu";e={(Get-View -ViewType virtualmachine -SearchRoot $cluster.moref -Property Runtime.PowerState,Config.Hardware.NumCpu|?{$_.Runtime.PowerState -eq "poweredOn"}|Select @{n="vcpu";e={$_.Config.Hardware.NumCPU}}|Measure-Object -Average -Property vcpu).average}}|measure -average -property mem,cpu,vcpu|%{[math]::round($_.average,0)})|%{if (($_|measure -Sum).sum -ne ($cluster.ConfigurationEx.DasConfig.Option|?{$_.key -match "das.slotCpuInMhz|das.slotMemInMB"}|measure -Sum -Property value).sum -and ($_|measure -Sum).sum -gt "64") {$cluster.ReconfigureComputeResource((New-Object VMware.Vim.ClusterConfigSpecEx -property @{dasConfig=(New-Object VMware.Vim.ClusterDasConfigInfo -property @{option=@((New-Object VMware.Vim.OptionValue -property @{key="das.vmMemoryMinMB";value=$_[0].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.vmCpuMinMHz";value=$_[1].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.slotMemInMB";value=$_[0].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.slotCpuInMhz";value=$_[1].tostring()}))})}),$true)}}}

Joyeux Noël à tous !

Indicates that you want to stop the specified virtual machines by terminating their processes running on the ESX. You can use this parameter to stop a virtual machine that is not responding and cannot be stopped or restarted in other ways.

Cela ressemble fortement à un kill des process vmx dans un shell, via esxtop ou esxcli mais nécessiterai d’être connecté à l’ESXi plutôt qu’au vcenter :

To use the Kill parameter, you need to have a direct connection to ESX 4.1 or later.

Mais une fois de plus le monkey test à payé, nous testons la commande en étant connecté au vcenter et ça marche. la vm est littéralement killée sans aucune tache apparente dans le vcenter ni sur l’ESX et HA la restart :

Nous avons également vérifié avec Wireshark qu’aucune communication n’avait lieu entre le client PowerCLI et l’ESXi.

MAJ 10/10/2013 : mise à jour du script (version 1.1) correction de bug.

Après avoir fait des tests de drivers Emulex sur un cluster, nous avons voulu savoir quelle version de la vib lpfc820 était installée sur chaque host. Pas évident même avec VUM, nous avons donc fait un petit coup de get-esxcli sur tous les ESX pour comparer la list mais bon voila, c’était pas pratique non plus. Au passage, nous nous sommes aperçu que certaines vib du constructeur n’étaient pas à la même version sur tous les serveurs. On a dû faire chauffer le notepad++ !

Voici donc un script de reporting de vib qui renvoi la liste des serveurs dont certaines vib sont différentes de la majorité du cluster :

Vous avez la possibilité d’utiliser les paramètres suivants :

• cluname : nom du cluster dont sera tirée la liste des ESX connectés au vcenter
• fullviblist : 1 renvoi une liste non filtrée dans un out-gridview
• compactviblist : 1 renvoi une liste filtrée (ESX et vib)
• compactviblistout : “csv” ou “view” pour avoir la liste en csv ou dans un out-gridview plutot quand dans la console

Vous pouvez l’exécuter sur plusieurs cluster grâce à une simple boucle :

En mode compacte, seules les vib qui comportent une différence sont remontées et la colonne “majority” représente le serveur de référence (un de ceux qui ont exactement les mêmes vib et à la même version). Le symbole == indique que la version de la vib est identique à la vib de la majorité.

get-vibdiff

In order to support virtual machines with strict latency requirements, vSphere 5.5 introduces a new per-VM feature called Latency Sensitivity.

Cela nous a fait curieusement penser à une autre feature disponible dans la version 5.1 : VM Latency Sensitivity.

vSphere 5.1 simplifies the process of configuring a virtual machine to support low-latency applications. It now offers a latency sensitivity advanced setting that automatically makes low-level changes in the vSphere kernel to reduce latency for the virtual machine.

Ah tiens c’est bizarre, elles ont le même nom…

Vous constaterez qu’il n’en est nullement fait référence dans le whitepaper de la 5.5 donc impossible de savoir si c’est “vraiment” une nouvelle fonctionnalité, la même fonctionnalité améliorée ou un gros pipeau.

En attendant d’en savoir plus, on vous a préparé un petit oneliner pour activer la fonctionnalité et même fixer le nombre de µs secondes que vous souhaiter (2000 dans notre exemple) :

Get-VM "Flash_Gordon"|Get-View|?{-not $_.Config.Template}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{latencySensitivity=(New-Object VMware.Vim.LatencySensitivity -Property @{level="custom";sensitivity="2000"})}))}

Et pour savoir ce qui a été configurer :

(Get-VM "Flash_Gordon"|Get-View).Config.LatencySensitivity

Get-VM nobackup|Get-View|?{-not $_.Config.Template -and $_.Runtime.ConnectionState -eq "connected"}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=@((New-Object VMware.Vim.optionvalue -Property @{Key="snapshot.maxSnapshots"; Value="0"}))}))}

Ça pique mais ça marche :

A general system error occurred: Exceeded the maximum number of permitted snapshots

En effet, après avoir activé l’autoExpand, le nombre de ports utilisables d’un DVPortgroup (en Static binding aka earlyBinding) se verra incrémenté automatiquement de 10 lorsqu’aucun port n’est disponible pour une nouvelle VM. Il y a également une fonction d’autoShrink décrite dans l’API Reference mais c’est une peu vague :

When this property is set to true, the portgroup becomes a potential candidate for auto-shrink. Once the portgroup has auto-expanded then its disconnected ports are likely to be deleted automatically, as a part of auto-shrink step, if there are more than certain number of free ports. If the portgroup never auto-expanded, then it will never lose any free ports.

Sachant que cette fonction est activé par défaut sur les DVSwitch 5.1, nous avons voulu vérifier si c’était également le cas lors d’une migration :

On constate donc que même après avoir upgradé le DVSwitch 5.0.0 en 5.1.0, l’autoExpand est toujours désactivé. Mais pas pour longtemps

Après analyse du script PowerCLI d’Arne et de l’API Reference, nous avons constaté que les DVUplinks “disposaient” de cette fonctionnalité (désactivée dans tous les cas et à ne probablement pas activer) car comme nous le confirme Steve Jin, ce ne sont que des DVPortgroup avec un tag spécifique (SYSTEM/DVS.UPLINKPG). De plus, lors de la reconfiguration du DVPortgroup, la propriété configVersion devrait être incrémentée. Et pour finir, en onliner c’est plus sexy :

Get-View -ViewType DistributedVirtualPortgroup|?{!($_.Tag|?{$_.Key -eq "SYSTEM/DVS.UPLINKPG"}) -and !$_.Config.autoExpand}|%{$_.ReconfigureDVPortgroup_Task((New-Object VMware.Vim.DVPortgroupConfigSpec -Property @{autoExpand="True";ConfigVersion=[int32]$_.Config.ConfigVersion+1}))}

Le script n’active la fonctionnalité que sur les DVPortgroup ne l’ayant pas déjà (hors DVUplinks) et incrémente la propriété ConfigVersion de 1 :

Et pour ceux qui voudraient savoir quand de nouveaux ports ont été ajoutés ou supprimés, il y a une alarme pour ça (Monitor : vSphere Distributed Swiches) :

]]> http://www.hypervisor.fr/?feed=rss2&p=4633 3 http://www.hypervisor.fr/?p=4540 http://www.hypervisor.fr/?p=4540#comments Thu, 10 Jan 2013 18:12:40 +0000 NiTRo http://www.hypervisor.fr/?p=4540 Dans l’optique de rattraper un peu le coût CPU de nos petits excès d’overcommit, nous nous sommes penché sur les gains potentiel du vNUMA “forcé” sur des petites VM (2 ou 4 vCPU).

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.

Une seule réponse possible : Go PowerCLI !

get-vm|get-vmquestion|set-vmquestion -option "i moved it" -confirm:$false

]]> http://www.hypervisor.fr/?feed=rss2&p=4533 1 http://www.hypervisor.fr/?p=4389 http://www.hypervisor.fr/?p=4389#comments Mon, 12 Nov 2012 22:27:37 +0000 NiTRo http://www.hypervisor.fr/?p=4389 Au détour de l’excellent Storage Implementation in vSphere 5.0 de Mostafa “VCDX #2″ Khalil,  nous avons découvert le Path Ranking. Détaillé dans une kb vmware (et dans un post de Cormac Hogan), le path raking permet de pondérer un ou plusieurs chemins lorsque le plugin VMW_PSP_MRU est utilisé.

In ESXi 5.0, VMW_PSP_MRU has path ranking capabilities that allows you to assign ranks to individual paths. VMW_PSP_MRU goes through the path group states in the following order: Active, Active_UO and Standby, and picks a path that has the highest rank for I/O.

Evidemment, le scénario dans le quel le path ranking nous intéresse le plus est le fameux FC to iSCSI failover dans le quel nous étions particulièrement gêné par le fait que les chemins en FC n’étaient pas prioritaires sur les chemins iSCSI et pouvant mener à des situations où un chemin iSCSI serait utilisé alors qu’un chemin FC serait disponible :

On passe le PSP du datastore en MRU et un coup de PowerCLI pour monter le ranking des chemins FC :

(Get-VMHost esx.vmware.com|Get-EsxCli).storage.nmp.path.list("naa.0123456789")|sort RuntimeName|select RuntimeName, @{n="rank";e={(Get-VMHost esx.vmware.com|Get-EsxCli).storage.nmp.psp.generic.pathconfig.get($_.RuntimeName)}}|ft -AutoSize

(Get-VMHost vmvisor01.vmwa.re|Get-EsxCli).storage.nmp.psp.generic.pathconfig.set("rank=1","vmhba0:C0:T0:L0")

Le (bon) résultat est immédiat :

]]> http://www.hypervisor.fr/?feed=rss2&p=4389 4 http://www.hypervisor.fr/?p=4283 http://www.hypervisor.fr/?p=4283#comments Sun, 21 Oct 2012 22:37:14 +0000 NiTRo http://www.hypervisor.fr/?p=4283 MAJ 21.02.2013 : Ajout de filtres pour les hosts vide afin d’éviter les divisions par 0.

MAJ 06.02.2013 : Debug des scripts.

MAJ 22.11.2012 : Nous avons oublié de préciser que pour que le script fonctionne correctement, le “statistic level” pour l’intervale de 5 minutes doit être à 2 minimum :

MAJ 23.10.2012 : Ajout d’un filtre dans les scripts pour ne modifier le(s) cluster que si nécéssaire.

Suite au post de Frank “distributed” Denneman traitant du sujet délicat des HA slot size “HA admission control is not a capacity management tool“, nous avons dépoussiéré une vieille idée de script de configuration automatique des “slot size” (mémoire et cpu) d’un cluster HA pour en faire un bon petit oneliner. L’idée est forcer le “slot size” à une valeur reflétant une vm moyenne du cluster afin de savoir approximativement la “place” restante dans le cluster et surtout pouvoir vraiment tirer parti de l’alarme “insufficient resources to satisfy HA failover level“

Nous avons fais nos tests sur un cluster de 6 ESXi 4.1 (4×4 cores 2.3Ghz & 64Go de RAM) contenant environ 150 VM sans réservations. Par défaut, voici ce qu’HA remonte comme information dans le vCenter :

Ces informations sont totalement erronés étant donné que le cluster est presque plein (en tenant compte du N-1 pour HA) mais c’est le comportement attendu d’HA lorsque les VM n’ont pas de réservations (l’overhead est pris en compte). On notera que le nombre de vcpu correspond à la plus grosse vm.

Voici ce qu’HA remonte après avoir passé notre script :

On est nettement plus proche de la vérité. Le calcul pour le cpu est la moyenne d’utilisation journalière par vm démarrée, idem pour les vcpu mais pour la ram nous avons du faire un choix pas trop optimiste (active memory) ni trop optimiste (consumed memory). Nous avons donc choisi de prendre la valeur médiane entre active et consumed (moyene journalière). Voici le résultat sur une journée de stat sur notre cluster de test :

Idéalement, ce script est donc à lancée une fois par jour. Voici la version pour vSphere 4.x (filtré par cluster où HA est activé) :

foreach ($cluster in (get-view -viewtype ClusterComputeResource -property Host,ConfigurationEx|?{$_.ConfigurationEx.DasConfig.Enabled})) {,($cluster.host|%{get-view $_ -property runtime,vm}|?{$_.Runtime.ConnectionState -match "^connected$"}|?{($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})}|select @{n="mem";e={(($_|%{((get-view (Get-View ServiceInstance).content.PerfManager).QueryPerf((New-Object VMware.Vim.PerfQuerySpec -property @{entity = $_.moref;format = "normal";IntervalId = "300";MetricId = (New-Object VMware.Vim.PerfMetricId -property @{instance = "";counterId = (((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "mem"}|?{$_.nameinfo.key -match "active$"}|?{$_.RollupType -match "average"}).key)})}))|%{$_.value}|%{$_.value}|measure -Average).average/(($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})|measure).count/1kb}) + ($_|%{((get-view (Get-View ServiceInstance).content.PerfManager).QueryPerf((New-Object VMware.Vim.PerfQuerySpec -property @{entity = $_.moref;format = "normal";IntervalId = "300";MetricId = (New-Object VMware.Vim.PerfMetricId -property @{instance = "";counterId = (((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "mem"}|?{$_.nameinfo.key -match "consumed$"}|?{$_.RollupType -match "average"}).key)})}))|%{$_.value}|%{$_.value}|measure -Average).average/(($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})|measure).count/1kb}))/2}}, @{n="cpu";e={($_|%{((get-view (Get-View ServiceInstance).content.PerfManager).QueryPerf((New-Object VMware.Vim.PerfQuerySpec -property @{entity = $_.moref;format = "normal";IntervalId = "300";MetricId = (New-Object VMware.Vim.PerfMetricId -property @{instance = "";counterId = (((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "cpu"}|?{$_.nameinfo.key -match "usagemhz"}|?{$_.RollupType -match "average"}).key)})}))|%{$_.value}|%{$_.value}|measure -Average).average/(($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})|measure).count})}}, @{n="vcpu";e={(($_.vm|%{get-view $_ -property Runtime,Config}|?{$_.Runtime.PowerState -eq "poweredon"})|%{$_.Config.Hardware.NumCpu}|measure -average).average}}|measure -average -property mem,cpu,vcpu|%{[math]::round($_.average,0)})|%{if (($_|measure -Sum).sum -ne ($cluster.ConfigurationEx.DasConfig.Option|?{$_.key -match "das.slotCpuInMhz|das.slotMemInMB"}|measure -Sum -Property value).sum) {$cluster.ReconfigureComputeResource((New-Object VMware.Vim.ClusterConfigSpecEx -property @{dasConfig=(New-Object VMware.Vim.ClusterDasConfigInfo -property @{option=@((New-Object VMware.Vim.OptionValue -property @{key="das.vmMemoryMinMB";value=$_[0].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.vmCpuMinMHz";value=$_[1].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.slotMemInMB";value=$_[0].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.slotCpuInMhz";value=$_[1].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.SlotNumVCpus";value=$_[2].tostring()}))})}),$true)}}}

Pour vSphere 5.0, le nombre de vcpu ne rentre plus en comptre pour le calcul du slot size, nous avons donc adapté le script en conséquence :

foreach ($cluster in (get-view -viewtype ClusterComputeResource -property Host,ConfigurationEx|?{$_.ConfigurationEx.DasConfig.Enabled})) {,($cluster.host|%{get-view $_ -property runtime,vm}|?{$_.Runtime.ConnectionState -match "^connected$"}|?{($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})}|select @{n="mem";e={(($_|%{((get-view (Get-View ServiceInstance).content.PerfManager).QueryPerf((New-Object VMware.Vim.PerfQuerySpec -property @{entity = $_.moref;format = "normal";IntervalId = "300";MetricId = (New-Object VMware.Vim.PerfMetricId -property @{instance = "";counterId = (((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "mem"}|?{$_.nameinfo.key -match "active$"}|?{$_.RollupType -match "average"}).key)})}))|%{$_.value}|%{$_.value}|measure -Average).average/(($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})|measure).count/1kb}) + ($_|%{((get-view (Get-View ServiceInstance).content.PerfManager).QueryPerf((New-Object VMware.Vim.PerfQuerySpec -property @{entity = $_.moref;format = "normal";IntervalId = "300";MetricId = (New-Object VMware.Vim.PerfMetricId -property @{instance = "";counterId = (((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "mem"}|?{$_.nameinfo.key -match "consumed$"}|?{$_.RollupType -match "average"}).key)})}))|%{$_.value}|%{$_.value}|measure -Average).average/(($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})|measure).count/1kb}))/2}}, @{n="cpu";e={($_|%{((get-view (Get-View ServiceInstance).content.PerfManager).QueryPerf((New-Object VMware.Vim.PerfQuerySpec -property @{entity = $_.moref;format = "normal";IntervalId = "300";MetricId = (New-Object VMware.Vim.PerfMetricId -property @{instance = "";counterId = (((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "cpu"}|?{$_.nameinfo.key -match "usagemhz"}|?{$_.RollupType -match "average"}).key)})}))|%{$_.value}|%{$_.value}|measure -Average).average/(($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})|measure).count})}}|measure -average -property mem,cpu|%{[math]::round($_.average,0)})|%{if (($_|measure -Sum).sum -ne ($cluster.ConfigurationEx.DasConfig.Option|?{$_.key -match "das.slotCpuInMhz|das.slotMemInMB"}|measure -Sum -Property value).sum) {$cluster.ReconfigureComputeResource((New-Object VMware.Vim.ClusterConfigSpecEx -property @{dasConfig=(New-Object VMware.Vim.ClusterDasConfigInfo -property @{option=@((New-Object VMware.Vim.OptionValue -property @{key="das.vmMemoryMinMB";value=$_[0].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.vmCpuMinMHz";value=$_[1].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.slotMemInMB";value=$_[0].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.slotCpuInMhz";value=$_[1].tostring()}))})}),$true)}}}

As of vSphere API 5.0, the number of vcpus is no longer used for slot calculations

Pour vSphere 5.1, le slot size est maintenant configurable dans via la GUI du web client (et donc de nouvelles propriétés sont disponibles) mais on va le faire en PowerCLI quand même

foreach ($cluster in (get-view -viewtype ClusterComputeResource -property Host,ConfigurationEx|?{$_.ConfigurationEx.DasConfig.Enabled})) {,($cluster.host|%{get-view $_ -property runtime,vm}|?{$_.Runtime.ConnectionState -match "^connected$"}|?{($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})}|select @{n="mem";e={(($_|%{((get-view (Get-View ServiceInstance).content.PerfManager).QueryPerf((New-Object VMware.Vim.PerfQuerySpec -property @{entity = $_.moref;format = "normal";IntervalId = "300";MetricId = (New-Object VMware.Vim.PerfMetricId -property @{instance = "";counterId = (((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "mem"}|?{$_.nameinfo.key -match "active$"}|?{$_.RollupType -match "average"}).key)})}))|%{$_.value}|%{$_.value}|measure -Average).average/(($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})|measure).count/1kb}) + ($_|%{((get-view (Get-View ServiceInstance).content.PerfManager).QueryPerf((New-Object VMware.Vim.PerfQuerySpec -property @{entity = $_.moref;format = "normal";IntervalId = "300";MetricId = (New-Object VMware.Vim.PerfMetricId -property @{instance = "";counterId = (((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "mem"}|?{$_.nameinfo.key -match "consumed$"}|?{$_.RollupType -match "average"}).key)})}))|%{$_.value}|%{$_.value}|measure -Average).average/(($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})|measure).count/1kb}))/2}}, @{n="cpu";e={($_|%{((get-view (Get-View ServiceInstance).content.PerfManager).QueryPerf((New-Object VMware.Vim.PerfQuerySpec -property @{entity = $_.moref;format = "normal";IntervalId = "300";MetricId = (New-Object VMware.Vim.PerfMetricId -property @{instance = "";counterId = (((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "cpu"}|?{$_.nameinfo.key -match "usagemhz"}|?{$_.RollupType -match "average"}).key)})}))|%{$_.value}|%{$_.value}|measure -Average).average/(($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})|measure).count})}}|measure -average -property mem,cpu|%{[math]::round($_.average,0)})|%{if (($_|measure -Sum).sum -ne (@($cluster.ConfigurationEx.DasConfig.AdmissionControlPolicy.SlotPolicy.Memory, $cluster.ConfigurationEx.DasConfig.AdmissionControlPolicy.SlotPolicy.Cpu)|measure -Sum).sum) {$cluster.ReconfigureComputeResource((New-Object VMware.Vim.ClusterConfigSpecEx -property @{dasConfig=((New-Object VMware.Vim.ClusterDasConfigInfo -property @{admissionControlPolicy=((New-Object VMware.Vim.ClusterFailoverLevelAdmissionControlPolicy -property @{slotPolicy=(New-Object VMware.Vim.ClusterFixedSizeSlotPolicy -property @{cpu = $_[1];memory = $_[0]});FailoverLevel = $cluster.ConfigurationEx.DasConfig.AdmissionControlPolicy.FailoverLevel}))}))}),$true)}}}

Ceux qui ont l’oeil auront certainement remarqué l’usage d’une “multidimensional array” (aka nested array) dans nos oneliner pour faire passer des tableaux au travers d’un pipe sans en changer le type.

Pour plus d’information sur HA, nous vous conseillons vivement la lecture de la série “Clustering Deepdive” de Duncan et Frank.