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=3947 http://www.hypervisor.fr/?p=3947#comments Mon, 16 Jul 2012 00:08:28 +0000 NiTRo http://www.hypervisor.fr/?p=3947 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

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"}))}}

Sachez aussi qu’historiquement statiques, les pourcentages équivalent aux différents states sont “dynamique” depuis ESX 5 et VMware recommande de tuner le paramètre minFreePct sur ESX 4.1 au dessus de 64Go de ram (nous, on vous recommande 3% à partir de 32Go).

Le compteur n’est pas accessible pour faire une alarme dans le vcenter donc nous avons fait chauffer le PowerCLI pour vous en faire une belle qui brille dans la nuit et qui vous alerte dès que le compteur passe à 1 (=1 : warning, >1 : alert) :

(Get-View AlarmManager).CreateAlarm((Get-Folder -NoRecursion |Get-View).MoRef,(New-Object VMware.Vim.AlarmSpec -Property @{Name = "Host memory state";Description = "Custom alarm to monitor Host memory state high-soft-hard-low";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 "mem"}|?{$_.nameinfo.key -match "state"}|?{$_.RollupType -match "latest"}).key;Instance = ""});Operator = "isAbove";Yellow = "1";YellowInterval = "20";Red = "2";RedInterval = "20";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} memory state 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"}))

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.

Nous vous proposions il y a quelques temps un script qui stop les jobs en cours sur un serveur veeam backup, aujourd’hui nous allons plus loin dans la démarche avec 2 fichiers xml correspondant à 2 export de tache planifiée pour Windows 2008 R2 contenant les commandes. Le fichier StopActiveVBRJobs.xml va vous permettre de créer une tache planifiée qui arrêtera les jobs veeam en cours à 7h du matin, les jours de semaine, et le fichier RetryFailedVBRJobs.xml automatisera le retry des jobs arrêtés ”manuellement” à 21h, les mêmes jours.

Nous vous proposons également une tache planifiée qui automatise l’export des jobs veeam backup sur un partage CIFS (\\server\share\ à ajuster) et un autre qui permet d’exporter régulièrement (en xml) la liste des points de restauration possibles pour chaque vm de chaque job.

Voici maintenant un oneliner pour un usage très particulier, celui de trouver (replacez le get-item par remove-item pour supprimer) les fichiers veeam backup orphelins dans les répertoires cibles des jobs (cela peut arriver en cas de reboot violent du serveur veeam ou indisponibilité du repository pendant un backup).

v5 :

Compare-Object (Get-VBRJob|%{$_.Info.TargetDir|%{Get-ChildItem $_|%{$_.FullName}}}) (Get-VBRBackup|%{$_.GetStorages()|%{$_.FilePath}})|%{Get-Item $_.InputObject}

v6 :

Compare-Object (Get-VBRJob|%{$_.Info|%{Get-ChildItem "$($_.TargetDir)\$($_.Path)"|%{$_.FullName|?{$_ -match ".vrb|.vbk|.vib"}}}}) (Get-VBRBackup|%{$_.GetStorages()|%{$_.FilePath}})|%{Get-Item $_.InputObject}

On continue avec un autre oneliner qui permet d’afficher la liste des vm dont la date du dernier backup veeam (si vous avez activé la fonction qui rempli l’un des custom fields, “veeam” dans notre exemple) est supérieure à 21 jours, que vous pouvez utiliser dans un script pour vous envoyez un mail périodiquement par exemple.

Get-View -Viewtype virtualmachine|select name,@{n="backup";e={[Regex]::Match(($_.value|?{$_.key -eq ((get-view (Get-View ServiceINstance).content.CustomFieldsManager).field|?{$_.name -match "veeam"}).key}).value, "([0-9]{1,2}/){2,2}201[0-9]{1,1}[ ]*([0-9]{1,2}:?){3,3}").Value}},@{n="pool";e={(get-view $_.ResourcePool).name}}|?{$_.backup}|?{([datetime]::ParseExact(($_.backup), "dd/MM/yyyy HH:mm:ss", (New-Object System.Globalization.CultureInfo("fr-FR")))) -le (get-date).AddDays(-21)}

Et pour finir, un oneliner qui nous a prit un peu de temps (à cause du comportement bizarre du -ExpandProperty de la cmdlet Select-Object) qui vous permet de lister les vm présentent dans plusieurs jobs de backup.

Get-VBRBackup|select jobname,@{n="vm";e={$_.GetObjectOibsAll()|%{@($_.name,"")}}}|select jobname -ExpandProperty vm|select @{n="vmname";e={$_}}, @{n="jobname";e={$_.jobname}}|?{$_.vmname}|Group-Object -Property vmname|?{$_.Count -gt 1}|select name, @{n="jobs";e={$_.group|%{$_.JobName}}}

Le mécanisme de shares, parfois mal connu malgré son apparition dans VI3 (oui oui, en 2006), est très bien expliqué sur le blog de Duncan ou par Frank dans l’excellent  VMware vSphere 5 Clustering Technical Deepdive.

Pour faire simple, si on veut toujours garder un bon ratio entres les pool, il faut recalculer les shares à chaque fois qu’une vm voit sa configuration cpu/mémoire changer ou qu’une vm est démarrée/arrêtée dans un des pool. L’idéal étant de le scripter, nous vous proposons un joli petit script PowerCLI (dérivé de celui posté par Andrew Mitchell sur le blog de Duncan) qui fera tout cela pour vous sur un model standardisé.

L’idée est d’avoir 4 resource pool toujours équilibrés (GOLD, SILVER, BRONZE et COPPER) qui représentent l’usage “classique” d’un cluster VMware, à savoir prod, pré-prod, qualif et dev. La seule chose que vous devez fournir au script est le nom du cluster et (en option) les pourcentages respectifs que vous jugez idéal pour votre environnement (45%, 30%, 15% et 10% par défaut).

Une fois les resource pool ajustés (si besoin), le script va créer pour le cluster un petit rapport html à la racine du site web du vcenter :

Vous l’aurez compris, ce script est fait pour tourner sur le vcenter à l’aide d’une tache planifiée (modèle pour Windows 2008 R2).

Set-ZResPoolShares

Nous vous rappelons que ce script se base sur le mécanisme de shares (QOS) et non sur celui de reservation/limit et qu’il est donc indispensable de monitorer les pools pour éviter toute contention qui dépasserait vos prévisions. Pour les petites infra, le vcenter reste l’outil idéal à nos yeux :

MAJ 30/10/2012 : Mise à jours des scripts pour n’exclure que les vm “invalid” ou “orphaned”.

MAJ 06/07/2012 : Mise à jour des scripts pour exclure “*/hostCache/*” pour ne pas remonter les fichiers vswp de la fonction Host Cache d’ESXi 5.

MAJ 05/07/2012 : Mise à jour des scripts pour intégrer les fichiers vswp.xxxxxx, merci à Larus Hjartarson pour l’idée.

MAJ 21/03/2012 : Mise à jour des scripts pour exclure “var/tmp/cache” dans le cas d’une redirection de la partition scratch sur un datastore.

MAJ 06/03/2012 : Mise à jour des scripts pour le support des multi-datacenter/multi-vcenter, des snapshot NetApp et des fichiers zdump qui trainent.

MAJ 28/02/2012 : Mise à jour des scripts suite à une erreur dans le “SideIndicator”

MAJ 24/02/2012 : Et pour ceux qui ont *VRAIMENT* confiance, voici le script pour supprimer les fichiers vswp orphelins (et si vraiment vous en avez, vous pouvez changer le filtrage au niveau du |?{$_.lostfile -match “vswp”}) :

foreach ($lost in (compare -passthru -property path $(foreach ($ds in ((get-view -ViewType datastore|sort name -unique|?{$_.summary.accessible}|%{(get-view $_.browser).SearchDatastoreSubFolders($("[" + $_.Name + "]"),(New-Object VMware.Vim.HostDatastoreBrowserSearchSpec -property @{matchPattern=("*zdump*","*.xml","*.vmsn","*.vmsd","*.vswp*", "*.vmx","*.vmdk","*.vmss","*.nvram","*.vmxf"); details=(New-Object VMware.Vim.FileQueryFlags -property @{filesize=$true;modification=$true})}))})|?{$_.file})){foreach ($files in $ds.file){$files|?{$_.Path -notmatch "-ctk.vmdk|esxconsole.vmdk|esxconsole-flat.vmdk"}|select @{n="path";e={$ds.FolderPath + $files.path|%{$_ -replace " ",""}}},FileSize,Modification|?{$_.path -notmatch ".zfs|.snapshot|var/tmp/cache|/hostCache/|.lck"}}}) $(get-view -ViewType virtualmachine|?{$_.Runtime.ConnectionState -notmatch "invalid|orphaned"}|%{$_.layoutex.file}|?{$_.type -ne "log"}|%{$_.name}|%{$_ -replace " ",""}|sort -unique|select @{n="path";e={$_}})|?{$_.SideIndicator -eq "<="}|select @{n="LostFile";e={$_.Path -replace "]","] "}}, @{n="FileSize";e={"{0:N0}" -f ($_.FileSize/1MB)}}, Modification|?{$_.lostfile -match "vswp"})){(get-view (Get-View ServiceInstance|select -first 1).content.filemanager|select -first 1).DeleteDatastoreFile($lost.LostFile,(Get-View -ViewType datacenter|?{$_.Datastore -match (get-datastore $lost.LostFile.split("[]")[1]|get-view).moref}|select -first 1).moref)}

MAJ 24/02/2012 : Mise à jour du script pour afficher la taille en MegaBytes et la date de modification des fichiers.

Très fortement inspiré du célèbre Raiders of the Lost VMX (mais aussi du post Orphaned files and folders – Spring cleaning) de LucD, nous avons enfin fini de finioler un oneliner PowerCLI qui va vous lister les fichiers .xml, .vmsn, .vmsd, .vswp, .vmx, .vmdk, .vmss, .nvram et .vmxf qui traînent sur vos datastores et qui ne sont pas rattachés à une quelconque vm du vcenter depuis lequel vous avez exécuté le script.

compare -passthru -property path $(foreach ($ds in ((get-view -ViewType datastore|sort name -unique|?{$_.summary.accessible}|%{(get-view $_.browser).SearchDatastoreSubFolders($("[" + $_.Name + "]"),(New-Object VMware.Vim.HostDatastoreBrowserSearchSpec -property @{matchPattern=("*zdump*","*.xml","*.vmsn","*.vmsd","*.vswp*", "*.vmx","*.vmdk","*.vmss","*.nvram","*.vmxf"); details=(New-Object VMware.Vim.FileQueryFlags -property @{filesize=$true;modification=$true})}))})|?{$_.file})){foreach ($files in $ds.file){$files|?{$_.Path -notmatch "-ctk.vmdk|esxconsole.vmdk|esxconsole-flat.vmdk"}|select @{n="path";e={$ds.FolderPath + $files.path|%{$_ -replace " ",""}}},FileSize,Modification|?{$_.path -notmatch ".zfs|.snapshot|var/tmp/cache|/hostCache/|.lck"}}}) $(get-view -ViewType virtualmachine|?{$_.Runtime.ConnectionState -notmatch "invalid|orphaned"}|%{$_.layoutex.file}|?{$_.type -ne "log"}|%{$_.name}|%{$_ -replace " ",""}|sort -unique|select @{n="path";e={$_}})|?{$_.SideIndicator -eq "<="}|select @{n="LostFile";e={$_.Path -replace "]","] "}}, @{n="FileSize";e={"{0:N0}" -f ($_.FileSize/1MB)}}, Modification|ft -autosize

Les snapshots ZFS (.zfs/snapshot), les fichiers -ctk.vmdk (fichiers CBT) et les vmdk des COS d’ESX classic (esxconsole-) sont filtrés, n’hésitez pas à nous remonter d’autres faux positifs que vous pourriez rencontrer. Prochaine étape : ménage automatique…

Disons que vous souhaitez limiter la possibilité de faire un snapshot sur vos vm uniquement s’il y a suffisamment d’espace sur les datastore, vous utiliseriez notre beau petit one-liner fait main :

Get-View -ViewType virtualmachine|?{-not $_.Config.Template -and $_.Runtime.ConnectionState -eq "connected"}|?{($_.Config.Hardware.Device|?{$_.GetType().Name -eq"VirtualDisk"}|%{$_.Backing.FileName.split("[]")[1]}|sort -Unique|measure-object).count -eq 1}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=@((New-Object VMware.Vim.optionvalue -Property @{Key="snapshot.minFreeSpace"; Value="$($($_.Config.Hardware.Device|?{$_.GetType().Name -eq"VirtualDisk"}|%{$_.CapacityInKB*1KB}|measure-object -sum).sum)"}))}))}

Ce script fixe le snapshot.minFreeSpace à la somme de la taille des vmdk (taille max d’un snapshot) et se limite aux vm dont les vmdk résident sur un seul et unique datastore.

Mais avant de passer ce script, peut être voudriez vous vérifier que vous n’avez pas des vm déjà dans cette situation ? Cet autre petit one-liner vous donnera la liste de chaque vm dont la taille totale est supérieure à l’espace libre du datastore où elle réside :

Get-View -ViewType virtualmachine|?{-not $_.Config.Template}|?{($_.Config.Hardware.Device|?{$_.GetType().Name -eq"VirtualDisk"}|%{$_.Backing.FileName.split("[]")[1]}|sort -Unique|measure-object).count -eq 1}|?{($_.Config.Hardware.Device|?{$_.GetType().Name -eq"VirtualDisk"}|%{$_.CapacityInKB*1KB}|measure-object -sum).sum -gt ((get-view -viewtype datastore -property name,summary -filter @{"name" = ($_.Config.Hardware.Device|?{$_.GetType().Name -eq"VirtualDisk"}|%{$_.Backing.FileName.split("[]")[1]}|sort -Unique)}).Summary.FreeSpace)}|select name

MAJ 04/10/2013 : mise à jour du script (version 3.8) Filtrage des datastore en mode maintenance, affichage des vm “skippées” ou incompatibles et correction d’un bug lors de l’utilisation de -vDiskFormat (thanks vmdude.fr)

MAJ 27/09/2013 : mise à jour du script (version 3.7) Renforcement des filtres.

MAJ 18/09/2013 : mise à jour du script (version 3.6) modification de l’objet du mailcheck pour les Storage Pod.

MAJ 13/09/2013 : mise à jour du script (version 3.5) possibilité d’égaliser un “datastore cluster” (-StoragePod), possibilité de recevoir un rapport par mail pour le vidage des datastore (-drainreport) et skip automatique des migrations en échec.

MAJ 09/05/2013 : mise à jour du script (version 2.5) filtrage des vm dont la method “RelocateVM_Task” est disabled et ajout du paramètre -vi5 pour déplacer les vm avec snapshot

MAJ 26/10/2012 : mise à jour du script (version 2.3) filtrage des vm non “connected”

MAJ 07/07/2012 : mise à jour du script (version 2.2) filtrage des vm avec contrôleur scsi en mode bus-sharing

MAJ 25/06/2012 : mise à jour du script (version 2.1) correction de bug d’espace libre mal remonté

MAJ 02/04/2012 : mise à jour du script (version 2.0) ajout du paramètre ”bypass” pour déplacer toutes les vm sans filtrage.

MAJ 09/02/2012 : mise à jour du script (version 1.6) ajout du pourcentage de “déviation” dans l’objet du mail :

MAJ 09/02/2012 : mise à jour du script (version 1.5) avec l’ajout de l’option “mailcheck” afin de pouvoir utiliser le script en tache planifié. Exemple de one-liner qui compare les datastores VMFS de tous les cluster (à filtrer selon vos besoins) :

get-view -viewtype clustercomputeresource|?{($_.Datastore|%{get-view $_}|?{$_.Summary.Accessible -and $_.Summary.MultipleHostAccess -and $_.Summary.Type -match "VMFS"}|%{$_.name}).count -gt 1}|%{ .\Datastore-Equalizer.ps1 ($_.Datastore|%{get-view $_}|?{$_.Summary.Accessible -and $_.Summary.MultipleHostAccess -and $_.Summary.Type -match "VMFS"}|%{$_.name}) -mailcheck 1 -clustername $_.name}

MAJ 19/12/2011 : mise à jour du script (version 1.1) afin d’exclure les templates.

Pour Noël, Hypervisor.fr vous offre une version “light” maison de Storage DRS. Si votre infra est encore en v4, ou que vous n’avez pas de licences enterprise++ pour votre infra v5 ou si vous ne voulez pas faire de Storage Pod (aka cluster de banques de données) parce que ça fait trop cloud, notre script PowerCLI Datastore-Equalizer est fait pour vous.

Comme son nom le laisse deviner, ce script va vous permette d’égaliser l’espace libre d’un groupe de datastores (fonction “equalize“) ou de vider un datastore vers d’autres (fonction “drain“). L’action à mener sera automatiquement déduite de la liste des datastores source/destination.

Le principe de base est de déplacer la vm la plus petite du datastore le plus rempli vers le datastore le plus vide, en boucle jusqu’à ce que l’écart entre le pourcentage de remplissage du datastore le plus rempli et du plus vide soit inférieur ou égal à la variable $FreeSpaceDeviation (10% par défaut). Ce script étant clairement pensé pour les cluster, il ne vérifie pas que les datastores sont bien tous connectés aux même ESX. Par contre, les espaces restant sont vérifiés avant tout mouvement mais les VM avec snapshot, RDM ou ayant de multiple datastores ne seront pas déplacées. En option il est possible de forcer un autre format de vmdk (thin ou thick).

Voici la liste des paramètres (mandatory en rouge) :

• SrcDatastores (ex : DS1,DS2,DS3)
• DstDatastores (=SrcDatastores par défaut)
• vDiskFormat (as-source par défaut, thick ou thin en option)
• FreeSpaceDeviation (10 par défaut, <5 à éviter)
• Force (0 par défaut, 1 pour éviter la confirmation ou pour une tache planifiée)
• DatastoreFreeLimit (pourcentage disponible limite, 10 par défaut)

Pour que ce soit vraiment la classe, le script vous affiche un petit récap du remplissage des datastores concernés avant d’agir :

Pour les fous ceux qui ont déjà migré leur prod en vSphere 5, nous ferons bientot une version qui permet de bouger les vm avec snapshot…

Datastore-Equalizer

MAJ 12/12/2011 : Mise à jour des scripts pour assurer la cohérence hostname/HA

MAJ 15/12/2011 : Sur un cluster en v4 il nous a fallu désinstaller les agents aam manuellement et redémarrer le service hostd

Si vous avez besoin de changer le nom d’un ESXi connecté à un vCenter, la méthode officielle consiste à détacher le server du vcenter, le renommer et le rattacher au vcenter. En plus d’être fastidieuse, cette action occasionnera la perte de certaines informations telles que les  statistiques ou le Swapfile Location. Pas cool.

Heureusement pour nous, il existe une solution de contournement qui va encore nous faire tâter du PowerCLI : la méthode ReconnectHost à laquelle on peut passer un certain nombre d’arguments comme le hostname ou plutôt un FQDN valide car ce paramètre n’à pas à correspondre obligatoirement au hostname de l’ESXi.

vSphere/PowerCLI 4 :

Get-VMHost oldhostname.olddomain.com|Get-View|%{(Get-View $_.ConfigManager.NetworkSystem).UpdateDnsConfig((New-Object VMware.Vim.HostDnsConfig -property @{Hostname = "newhostname";domainName = "newdomain.com";dhcp = $_.Config.Network.DnsConfig.Dhcp;address = $_.Config.Network.DnsConfig.Address;searchDomain = $_.Config.Network.DnsConfig.SearchDomain}));$_.DisconnectHost();$_.ReconnectHost((New-Object VMware.Vim.HostConnectSpec -property @{HostName = "newhostname.newdomain.com"}))}

vSphere/PowerCLI 5 :

Get-VMHost oldhostname.olddomain.com|Get-View|%{(Get-View $_.ConfigManager.NetworkSystem).UpdateDnsConfig((New-Object VMware.Vim.HostDnsConfig -property @{Hostname = "newhostname";domainName = "newdomain.com";dhcp = $_.Config.Network.DnsConfig.Dhcp;address = $_.Config.Network.DnsConfig.Address;searchDomain = $_.Config.Network.DnsConfig.SearchDomain}));$_.DisconnectHost();$_.ReconnectHost((New-Object VMware.Vim.HostConnectSpec -property @{HostName = "newhostname.newdomain.com"}),$null)}

Le one-liner ci-dessus (attention à la version) effectue les actions suivantes :

• déconnexion de oldhostname.olddomain.com du vcenter (et dé-configuration d’HA le cas échéant)
• reconnexion de l’ESXi au vcenter avec le nouveau nom (si newhostname.newdomain.com est valide)
• change le hostname newhostname et newdomain.com de l’ESXi (ne nécessite pas de reboot depuis la v4)

/!\ Ce script ne met pas à jour les IQN et ne régénère pas les certificats des ESXi /!\

]]> http://www.hypervisor.fr/?feed=rss2&p=3508 1 http://www.hypervisor.fr/?p=3485 http://www.hypervisor.fr/?p=3485#comments Sat, 10 Dec 2011 17:36:43 +0000 NiTRo http://www.hypervisor.fr/?p=3485 Au sein d’un même cluster , il a toujours été fortement recommandé d’uniformiser au maximum le hardware ainsi que le software. Cette règle s’appliquant évidement pour les versions de BIOS et firmware, nous étions parti sur un petit one-liner tout simple pour afficher la propriété HostBIOSInfo des ESX connectés à un vCenter mais nous avons très vite été surpris de constater que cette propriété n’est pas toujours peuplée :

Nous nous sommes donc rabattu sur les informations remonté via les API CIM :

Tant qu’on y était, on a fignolé le truc pour que ça ne remonte que les cluster non uniformes :

Get-BIOSMismatch

Si vous préférez un bon vieux one-liner qui vous affiche les version des BIOS de tous vos ESX, c’est par ici :

Get-View -ViewType HostSystem|?{$_.Runtime.ConnectionState -eq "connected"}|sort name|select name,@{n="BiosVersion";e={[Regex]::Match(($_.Runtime.HealthSystemRuntime.SystemHealthInfo.NumericSensorInfo|?{$_.name -match "bios" -and $_.SensorType -match "Software Components"}).name,"BIOS (.*) (20[0-9]{2,2}-[0-9]{2,2}-[0-9]{2,2})").groups[1].value}},@{n="ReleaseDate";e={[Regex]::Match(($_.Runtime.HealthSystemRuntime.SystemHealthInfo.NumericSensorInfo|?{$_.name -match "bios" -and $_.SensorType -match "Software Components"}).name,"BIOS (.*) (20[0-9]{2,2}-[0-9]{2,2}-[0-9]{2,2})").groups[2].value}}

PS : Il se peut que les infos visibles dans l’onglet “Hardware Status” du vSphere client ne correspondent pas à celle remonté en powershell, dans ce cas suivez les instructions de la kb 1037330, si cela ne suffit pas il faudra rebooter l’ESX.

MAJ 11/05/2012 : Script utilisé pour checker automatiquement vos clusters via une tache planifiée : ClusterProfileCheck.ps1

Thanks to Didier Pironet, our english followers can read this post without google translate

Inutile de vous rappeler l’intérêt des Host Profiles sur le plan déploiement et encore plus sur le plan suivi des ESX. Avec un bon PXE Manager et du powerCLI, on pourrait s’affranchir de la partie déploiement mais pour la partie suivit des modifications c’est devenu clairement incontournable (et c’est d’autant plus vrai en v5).

Pour les Cluster, la gestion se fait toujours à l’ancienne : on configure bien comme il faut au début, on laisse passer 6 mois, une poignée de modifications et quelques plages de maintenance où on a désactivé l’Admission Control et passé DRS en Partially Automated, et on se retrouve avec une lame crashé et des VM qui n’ont pas redémarré parce qu’on avait oublié de réactivé HA. Evidemment c’est du vécu mais notre tout nouveau script PowerCLI va vous faire oublier toutes ces vilaines méthodes médiévales : Meet Manage-ClusterProfile.

Manage-ClusterProfile à été conçu pour 3 taches très simples :

• exporter la configuration d’un cluster vers un fichier profile
• comparer la configuration d’un cluster avec un profile
• importer un profile sur un cluster existant

Le fichier xml qui fait office de profile contient l’intégralité de la configuration du cluster (HA, DRS, DPM, rules, swapfile, etc…) et permet donc une comparaison détaillée (avec envoi de mail en option) :

La fonction d’import ne va utiliser que les paramètres propres aux cluster, les règles d’affinités et autres paramètres concernant les vm (customization HA/DRS/DPM) ne sont pas pris en compte.

Les différents input du script sont :

• ManagedCluster [nom du cluster]
• Action [import|export|check]
• ProfilePath [répertoire pour l'export|fichier xml pour l'import  et le check]
• SendMail [1]
• ForceImport [1]

En résumé ce script vous permettra de créer de nouveau cluster en important un profile template correspondant à vos critères (préalablement exporté d’un cluster vide par exemple) et de tracker tout changement de configuration indésirable. Si vous utilisez ce script en tache planifiée, il faudra évidement refaire un export de profile à chaque modification du cluster.

Comme d’habitude, n’hésitez pas à nous faire partager votre feedback et vos suggestions dans les commentaires du post

Enjoy !

Manage-ClusterProfile

Pour les besoins d’un script en préparation, qui en ravira plus d’un (imaginez l’équivalent des Host Profiles pour les clusters…), nous avons eu besoin de lister récursivement les propriétés d’un objet Powershell. Nous avons donc pris comme base le fameux script Get-ALLPropertyNames d’Hugo Peeters et l’avons modifié pour qu’il supporte les “array” ainsi que les “deserialized object“. Nous l’avons aussi rebaptisé “Get-ALLProperties” par soucis de clarté à propos de sa fonction.

Get-ALLProperties

Par curiosité, nous l’avons utilisé pour mesurer le nombre de propriétés d’un ESXi 5.0 de lab. Jugez vous même :

Add-PSSnapin VeeamPSSnapIn ; Get-VBRJob|?{$_.GetLastResult() -eq 'Failed'}|?{($_|%{$_.FindLastSession()}|%{$_.info}).Description -match 'Job has been terminated'}|%{Start-VBRJob $_ -RetryBackup -RunAsync}

Add-PSSnapin VeeamPSSnapIn ; Get-VBRJob|?{$_.GetLastResult() -eq 'Failed'}|?{($_.FindLastSession()|%{$_.GetDetails()}) -match 'Job has been terminated'}|%{Start-VBRJob $_ -RetryBackup -RunAsync}

MAJ 07/11/2011 : Apparemment ce sera possible dans la v6.

L’une des petites options pratiques qui rapprocherai veeam backup de la perfection serai de pouvoir définir une heure limite d’exécution par job. Par exemple, vous ne voulez peut être pas qu’un job continue après 7h du matin. Pour ça il vous suffit de coller ce petit one-liner en tache planifiée sur votre serveur veeam et tous les jobs au statut ”Working” serons stoppés :

Add-PSSnapin VeeamPSSnapIn ; Get-VBRJob|?{$_.GetLastState() -eq "Working"}|%{Stop-VBRJob $_ -RunAsync}

Get-View -ViewType hostsystem -Property ConfigManager.PowerSystem -Filter @{"name" = "^esxsrv$"}|%{Get-View $_.ConfigManager.PowerSystem|%{$_.ConfigurePowerPolicy(2)}}

Avec ce petit one-liner, vous pourrez changer de 1 (low power) à 3 (high performance) la stratégie de gestion d’énergie des ESX correspondant au filtre de la cmdlet Get-View.

Nous rappelons que sur ESX 4, la stratégie par défaut est “High Performance” alors que sur ESX 5 la stratégie par défaut est ”Balanced” malgré son comportement :

The VMkernel uses the available power management features conservatively to reduce host energy consumption with minimal compromise to performance.

Voici un exemple des gains potentiels sur ESXi 5 :

Voici donc un petit one-liner qui permet de combiner les actions de rescan et refresh :

Get-View -ViewType HostSystem -Property ConfigManager.StorageSystem -Filter @{"Name"="^vmvisor"}|%{Get-View $_.ConfigManager.StorageSystem|%{$_.RescanAllHba();$_.RefreshStorageSystem()}}

L’équivalent en moins rapide mais en plus simple :

Get-VMHost vmvisor*|Get-VMHostStorage -RescanAllHba -Refresh

Vous aurez remarqué que nous n’avons pas inclus de RescanVmfs car selon le vSphere API Reference, la méthode RefreshStorageSystem l’intègre :

The RefreshStorageSystem method obtains information from the host platform and it performs a rescan of VMFS volumes. It does not look for new devices.

Bonus : la même commande pour la partie réseau, dont le refresh n’est aussi disponible qu’individuellement sur chaque host :

Get-View -ViewType HostSystem -Property ConfigManager.NetworkSystem -Filter @{"Name"="^vmvisor"}|%{Get-View $_.ConfigManager.NetworkSystem|%{$_.RefreshNetworkSystem()}}

Inutile de vous rappeler qu’il vous faudra ajuster le filtrage de la commande Get-View à votre nomenclature.

When making changes to the networks that your clustered ESX/ESXi hosts are on, VMware recommends that you suspend the Host Monitoring feature.

Nous vous recommandons pour cela notre petit OneLiner PowerCLI maison :

Get-View -ViewType ClusterComputeResource|%{$_.ReconfigureComputeResource_Task((New-Object VMware.Vim.ClusterConfigSpecEx -Property @{DasConfig=(New-Object VMware.Vim.ClusterDasConfigInfo -Property @{HostMonitoring="disabled"})}), $true)}

Vous trouverez facilement la commande inverse