Hypervisor.fr

MAJ 06/07/2015 : mise à jour du script (version 3.9) qui corrige le problème de retry loop et marque l’arrivée du script sur GitHub (thanks vmdude.fr)

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

Tags: dmotion, PowerCLI, scripting, SDRS

MAJ 06/01/2012 : Mise à jour des scripts pour conserver la configuration DNS

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 /!\

Tags: ESXi, PowerCLI, powershell, scripting, vCenter

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.

Tags: BIOS, bug, PowerCLI, scripting, x86

MAJ 09/05/2013 : Mise à jour du script (1.5) pour supporter les changements de “definition” de powershell v3 et ajout du paramètre -NoOld pour ne pas générer un fichier .old.

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

Tags: PowerCLI, scripting

MAJ 09/05/2013 : Mise à jour du script pour supporter les changements de “definition” de powershell v3.
MAJ 17/11/2011 : Modification du script pour une meilleure gestion des “VMware.Vim.OptionValue”, ClusterDasVmConfigInfo, ClusterDpmHostConfigInfo, ClusterDrsVmConfigInfo, ClusterGroupInfo, ClusterRuleInfo
MAJ 15/11/2011 : Modification du script pour une meilleure gestion des “scriptproperty”
MAJ 14/11/2011 : Modification du script pour la gestion des propriétés “value__” deserialized

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 :

Tags: powershell, scripting