Hypervisor.fr

MAJ 12.09.2013 : Nouvelle version 2.3 collecte des infos supplémentaires sur les LUN et permet d’ouvrir l’html après exécution (-invokehtml) et ne rien afficher dans la console (-noconsole)

MAJ 07.06.2013 : Nouvelle version 2.1 plus rapide et dotée des nouveaux paramètres -onlyfree (pour ne retourner que les LUN vides) et -minVMFSsizeGB (pour ne retourner que les datastore d’une taille minimum de xGB – 1GB par défaut)

Avec la cmd-let Get-ScsiLunPath, il est très facile de repérer les “dead path” sur un ou une liste d’ESX et c’est d’ailleurs de cette façon que vCheck v5+ les obtient. Le problème est qu’il n’est pas facile ensuite de faire le rapport avec le datastore concerné et si c’est bien d’un datastore dont il est question (cela peut être un périphérique de stockage autre comme un lecteur cdrom ou une clef usb par exemple).

Nous avons donc créé pour cela un script avec la collaboration de notre ami JJR (qui souhaite conserver l’anonymat dans cette affaire) qui nous a été d’une grande aide en ce qui concerne l’optimisation du script lorsqu’il est exécuté sur un gros environnement. Ce script génère une liste des chemins de LUN (dead ou non selon le paramétrage) avec les informations suivantes :

• ClusterName : nom du cluster
• ESX : nom de l’ESX
• CanonicalName : LUN identifier
• Runtime : vmhba<Adapter>:C<Channel>:T<Target>:L<LUN>
• State : active, standby ou dead
• IsWorkingPath : true ou false
• LunSize : exprimé en MB, GB ou TB (le cas échéant)
• Datastore : nom du datastore VMFS (le cas échéant)
• UUID : VMFS UUID (ou “cdrom” si le périphérique est un lecteur optique)

Pour plus d’informations, nous vous recommandons de consulter la kb Identifying disks when working with VMware ESX

Voici le détails et les valeurs par défaut des paramètres disponibles :

• cluname : permet de spécifier un cluster (parcours tous les hosts par défaut)
• nofile : n’affiche que le résultat dans la console et ne génère pas de fichier (“0″ par défaut)*
• html : génère un fichier html au lieu d’un csv (“0″ par défaut)*
• onlydead : ne liste que les chemins “dead” (“1″ par défaut)
• onlyvmfs : ne liste que les chemins de LUN comportant un datastore VMFS (“0″ par défaut)

* le fichier est généré dans le répertoire de travail.

Exemple d’usage pour afficher tous les chemins d’un cluster :

.\Get-DeadPath+.ps1 -cluname "CLU01" -html "1" -onlydead "0"

Exemple d’usage pour n’afficher que les chemins “dead” :

.\Get-DeadPath+.ps1 -html "1" -onlydead "1"

Nous ne manquerons pas mettre à jour vCheck en conséquence.

download

Tags: LUN, PowerCLI, powershell, scripting, vmhba

Comme nous en parlions lors de l’annonce de la GA, la façon dont les snapshot sont consolidés a beaucoup changée (en mieux évidement) depuis ESX 4.0 U2. Le blog VMware Support Insider a publié la veille de noël un billet avec 2 schéma qui valent plus de 1000 mots :

Avant l’U2

Après l’U2

Tags: snapshot

Depuis ses débuts, ESXi ne supportait pas le passthrough usb/serial/parallel. La version 4.1 solutionne les limitations pour les ports série et usb ce qui permet enfin d’utiliser les adaptateurs 1-Wire. Pour ceux qui ne connaissent pas, le 1-Wire est un principe de bus de communication entre capteurs à l’aide d’un seul câble, utilisé notamment en domotique.

Hobby Boards est un des sites très connus dans le petit monde du 1-Wire qui fournissent de quoi se monter un réseau de capteurs.

L’intérêt des produits Hobby Boards est d’utiliser le RJ45 comme connectique pour relier les capteurs, ce qui rend possible des montages reliés par des baies de brassage classique.

Nous utilisons, depuis quelques temps déjà, 2 capteurs Humidity/Temp et un adaptateur série (pour maximiser la comparabilité avec les systèmes embedded type WRT54G) connectés à un Linux grâce à OWFS (one wire filesystem) qui permet de monter les capteurs dans le filesystem de l’OS pour facilement les interroger via un script. Couplé à cacti, on obtient de beau graphiques :

(on voit clairement ici que le capteur ne craint pas le gel…)

(à l’intérieur c’est nettement plus stable…)

Vous trouverez une compilation de liens dans la rubrique “links” (étonnamment) d’Hobby Boards. Évidement c’est beaucoup plus fun et moins cher qu’une solution snmp/ip/web/kifélecafé/holinewouane…

Tags: 1-wire, ESXi, hobby boards, owfs

Si vous avez besoin d’utiliser vmplayer dans une vm (pour du FLR sous veeam 4.x par exemple), il faut ajouter le même paramètre que pour un ESX dans une vm :

monitor_control.restrict_backdoor = “true”

Avec vmplayer 3.1, sans ce paramètre on a droit à ce message :

Par contre, ce paramètre ne fait pas bon ménage avec les vmtools :

A n’utiliser donc qu’en cas de besoin ou dans une vm dédiée, hors production.

Tags: nested vmplayer, vmplayer

MAJ 12/12/2011 : petit one-liner PowerCLI pour mettre à jour votre parc d’un coup :

Get-VMHost|?{$_.PowerState -eq "poweredOn"}|?{($_|Get-VMHostAdvancedConfiguration -Name Net.FollowHardwareMac).values -contains "0"}|Set-VMHostAdvancedConfiguration -Name Net.FollowHardwareMac -Value "1"

Sur ESXi, si vous devez remplacer une carte réseau utilisée par une interface vmkernel de management ou si vous restaurez la configuration d’un serveur sur un autre (panne hardware par ex), vous vous retrouver dans une situation où l’adresse MAC de la carte réseau du (ou des) “vmkernel port” a changée. Pour que ce changement soit bien effectif, et pour éviter que l’ESXi ne communique avec l’ancienne MAC (problématique en cas de boot PXE/DHCP ou de sécurité réseau renforcé), il faut activer le paramètre indiqué dans cette kb :

The MAC address of vmk0 management network might not get updated after you replace or assign a new MAC address to the NIC
[...]
esxcfg-advcfg -s 1 /Net/FollowHardwareMac

Sinon, on obtient ceci :

Par contre ce n’est valable que pour l’interface de management :

Tags: ESXi, MAC, vmk0