Hypervisor.fr

Alors que nous scriptions le check du paramètre UNMAP des primitives VAAI avec la cmdlet Get-EsxCli, nous nous sommes aperçu par hasard que contrairement à celle de la v4 de PowerCLI cette cmdlet avait un paramètre ”VMHost” en plus du paramètre ”Server” déjà présente dans la v4. Sachant que cette cmdlet ne pouvait être exécutée que lors d’une session direct avec un (ou plusieurs) ESX lors son apparition dans le PowerCLI 4.1 U1, la présence du paramètre ”VMHost” nous a paru plus que suspect.

Et bien nous en a pris car cet indice nous a permis de découvrir (1 an plus tard…) que la cmdlet Get-EsxCli de PowerCLI 5+ ne nécessite pas de connections direct aux ESX (mais uniquement avec un vCenter 5+ comme en témoigne le changelog) :

Added vCenter Server support for Get-EsxCli. (requires vCenter Server 5.0 or later)

Vous pouvez donc facilement vérifier l’état du paramètre UNMAP…

Get-VMHost|select Name, @{n="UNMAP";e={$(($_|Get-EsxCli).system.settings.advanced.list("/VMFS3/EnableBlockDelete")).IntValue}}

… Ou afficher la liste des claimrule (pratique pour masquer un path)…

Get-VMHost|%{" ";write-host -background white -foreground red $_.Name;($_|Get-EsxCli).storage.core.claimrule.list()|ft *}

… Ou encore modifier le paramètre “IOOperationLimit” des LUN configurées en roundrobin :

ForEach ($VMHost in Get-VMHost){" ";write-host -background white -foreground red $VMHost.Name;($VMHost|Get-EsxCli).storage.nmp.device.list()|?{$_.PathSelectionPolicy -match "VMW_PSP_RR"}|%{($VMHost|Get-EsxCli).storage.nmp.psp.roundrobin.deviceconfig.get($_.device)}}

ForEach ($VMHost in Get-VMHost){" ";write-host -background white -foreground red $VMHost.Name;($VMHost|Get-EsxCli).storage.nmp.device.list()|?{$_.PathSelectionPolicy -match "VMW_PSP_RR"}|%{($VMHost|Get-EsxCli).storage.nmp.psp.roundrobin.deviceconfig.get($_.device)}|?{$_.IOOperationLimit -ne 1 -and $_.LimitType -ne "iops"}|%{($VMHost|Get-EsxCli).storage.nmp.psp.roundrobin.deviceconfig.set($null,$_.device,"1","iops",$null)}}

Moralité : RTFChangelog

Tags: esxcli, Get-EsxCli, oneliner, PowerCLI, scripting, sso

MAJ 24.03.2013 : Voici le compte rendu officiel de l’experience.

Durant l’OpenStorage Summit EMEA 2012, Andy Bennett raconte comment VMware a sollicité Nexenta pour pondre une solution de stockage comparable aux Vblocks d’EMC et FlexPods de NetApp mais à un coût radicalement inférieur (l’objectif était le meilleur prix au Téraoctet) et comment cette solution s’est retrouvée à héberger une partie des “Hands on lab” des 2 VMworld 2011 avec des disques NL-SAS 7500 rpm en face d’EMC et NetApp avec des baies remplies de SAS 15K et de SSD.

Résultat, plus de de 10 milliards d’IOPS NFS sur les 2 VMworld à 2ms en moyenne (~1,2 VM déployées par seconde !) avec une solution à 330K$ face à NetApp et EMC avec des solution à 2M$…

Il raconte également comment un module de RAM défectueux a fait planter un des nœuds de leur cluster sans conséquence sur les labs mais aussi comment, en quelques heures seulement, l’un des membres de l’équipe a designé et codé la fameuse interface Aura (basé sur DTrace) contenant les metrics les plus importants pour les équipes d’experts VMware qui monitoraient l’infrastructure sur place. Du caviar pour les plus curieux d’entre nous…

Tags: DTrace, nexenta, vmworld, ZFS

Il fallait bien que ça arrive, check_esx3 ça commençait à faire vieillot, limite vintage. Alors que nous nous étions tourné vers une solution alternative, nous revenons de nouveau vers ce plugin nagios qui commence à compter quelques sérieux contributeurs et nous nous sommes retroussé les manches (très haut car en perl on y connait rien…) pour ajouter quelques features et faire un plugin cacti qui ne nécessite plus de créer un device par cluster.

Nous avons donc fait 2 fichiers xml (check_vmware_cluster.xml et check_vmware_datastore.xml à copier dans resource/script_queries) pour la partie “data queries” et un script bash (check_esx3_helper.sh à copier dans scripts) pour faire l’intermédiaire entre cacti et le script check_vmware_api.pl (à copier dans scripts).

Selon la version de votre vCenter, il est possible que vous ayez à tuner la variable $vi_timeshift dans check_esx3_helper.sh (il nous a fallu parfois jongler entre 300 et 600) à cause d’un bug vmware.

Une fois les fichiers copiés, il faut importer les templates (cacti_data_query_vmware_vpx_-_cluster_usage.xml et cacti_data_query_vmware_vpx_-_vmfs_usage.xml) dans cacti et les associer à votre vCenter :

Nous avons utilisé les credentials snmp v3 pour éviter de mettre un login/password dans les scripts donc si vous utiliser snmp sur votre vCenter, créez un compte équivalent ou créez un device dédié.

En ce qui concerne l’autentification, le fichier de session /tmp/check_esx3_session.dat, généré automatiquement, évite les logon/logoff à répétition et soulage le proxy mob.

Il ne vous reste plus qu’à choisir les clusters et les datastores que vous voulez monitorer (la dénomination VMFS est uniquement cosmétique, les datastores NFS sont évidement supportés) :

Vous pouvez ensuite regrouper vos graph par cluster :

Les graph on une fonction de remplissage automatique qui reprend la dernière bonne valeur connue pour éviter les vilains trous qui ne plaisent pas aux managers…

vi_host package

Tags: cacti, cluster, monitoring, nagios, rrdtool, vpx

Le grand suspens prend fin : on peut mettre 32Go de RAM dans un ML110 G6 contrairement à ce que dit HP (dans un G7 aussi très probablement) :

Cette bonne nouvelle, nous la devons à crucial qui produit des modules de 8Go DDR3 PC3-10600 Unbuffered ECC *Quad Rank*. Il vous en coûtera pas loin de 600€ pour 4 de ces “gros barreaux” mais cela décuplera sans nul doute le potentiel de votre lab.

Il est fort probable que d’autres modules compatibles existent aussi chez d’autres constructeurs mais qui s’y risquerait sans confirmation ?

Tags: 32GB, HP ML110

MAJ 06/06/2012 : Nous avions oublié de préciser que pour des tests de pourrissage de réseau nous avions utilisé WANem (Wide Area Network Emulator) qui permet toutes sortent de simulation visant à détériorer ou ralentir le trafic réseau (liveCD et Open Source).

MAJ 31/05/2012 : Les stats de dropped packets n’étant pas dispo pour les VM sur vCenter 4.x, nous avons ajouté un script pour créer des alarmes sur les vmnic, pour les vswitch des ESX donc. Merci à puchy pour son feedback.

Si, comme nous, vous vous êtes rendu compte un peu tard que de nombreux packets réseau étaient droppés sur des VM Windows 2008 R2 avec l’adapteur e1000, vous serez intéressé par notre petit oneliner (what else ?) qui vous permettra de créer des alarmes dans votre vCenter pour vous en avertir. Mieux vaut un mail de votre vcenter (5.0+) que d’un user en colère, non ?

Voici une illustration de notre cas :

Et voici le oneliner qui va créer une alarme pour chaque “instance” de carte réseau existante de votre vCenter (yellow >1 ; red > 5 ; mailto:admin@vmware.local) :

foreach ($vnic in (Get-View -ViewType VirtualMachine|%{$_.Config.Hardware.Device|?{$_.DeviceInfo.label -match "Network adapter"}}|select Key -Unique|%{$_.Key})){if (!((Get-View AlarmManager).GetAlarm((Get-Folder -NoRecursion |Get-View).MoRef)|?{(get-view $_).info.name -like "Virtual Machine dropped network packets (instance $vnic)"})){(Get-View AlarmManager).CreateAlarm((Get-Folder -NoRecursion |Get-View).MoRef,(New-Object VMware.Vim.AlarmSpec -Property @{Name = "Virtual Machine dropped network packets (instance $vnic)";Description = "Custom alarm to monitor dropped network packets (instance $vnic)";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 "net"}|?{$_.RollupType -match "summation"}|?{$_.NameInfo.key -match "droppedTx"}).key;Instance = $vnic});Operator = "isAbove";Yellow = "1";YellowInterval = "300";Red = "5";RedInterval = "180";Type = "VirtualMachine"});(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 "net"}|?{$_.RollupType -match "summation"}|?{$_.NameInfo.key -match "droppedRx"}).key;Instance = $vnic});Operator = "isAbove";Yellow = "1";YellowInterval = "300";Red = "5";RedInterval = "180";Type = "VirtualMachine"}))});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} has dropped network packets ({newStatus} state)";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 = $false}))})});ActionFrequency = "1800"}))}}

Vous devez réexecuter ce script si vous créez une nouvelle vm dans votre vCenter (5.0+) qui possède plus de cartes réseau virtuelles que celle qui en possédait le plus lors de la précédente exécution. Chaque alarme sera identifiée par l’instance qui lui est affectée :

Pour vCenter 4.x+, voici le même script pour les vmnics des ESX :

foreach ($vmnic in (Get-View -ViewType HostSystem|%{$_.Config.Network.Pnic|%{$_.Device}}|Select-Object -Unique)){if (!((Get-View AlarmManager).GetAlarm((Get-Folder -NoRecursion |Get-View).MoRef)|?{(get-view $_).info.name -like "Host dropped network packets (instance $vmnic)"})){(Get-View AlarmManager).CreateAlarm((Get-Folder -NoRecursion |Get-View).MoRef,(New-Object VMware.Vim.AlarmSpec -Property @{Name = "Host dropped network packets (instance $vmnic)";Description = "Custom alarm to monitor Host dropped network packets (instance $vmnic)";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 "net"}|?{$_.RollupType -match "summation"}|?{$_.NameInfo.key -match "droppedTx"}).key;Instance = $vmnic});Operator = "isAbove";Yellow = "1";YellowInterval = "300";Red = "5";RedInterval = "180";Type = "HostSystem"});(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 "net"}|?{$_.RollupType -match "summation"}|?{$_.NameInfo.key -match "droppedRx"}).key;Instance = $vmnic});Operator = "isAbove";Yellow = "1";YellowInterval = "300";Red = "5";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} has dropped network packets ({newStatus} state)";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 = $false}))})});ActionFrequency = "1800"}))}}

Tags: alarm, droppedRX, droppedTX, e1000, packets dropped, PowerCLI, powershell, scripting, vmxnet3