Hypervisor.fr

Suite à un problème connu (heavy I/O load) du service iscsi d’Openfiler 2.3, un des membres du forum avait trouvé une parade qui consiste à ajouter une ou plusieurs target sur la même LUN afin du simuler un multipathing et ainsi assurer une redondance primaire du service (chaque target étant géré par un process individuel, en cas de crash ESX bascule sur un “autre path”) :

Souhaitant remplacer cet Openfiler par un NexentaStor community edition (qui méritera certainement un petit retour), nous nous lançâmes dans un one-liner en powershell pour ôter les targets de chaque ESX utilisant l’unique LUN présentée. Malheureusement pour nous, la commande suivante ne traite qu’un path à la fois :

Get-VMHost|Get-VMHostHba -Type IScsi|Get-IScsiHbaTarget|Remove-IScsiHbaTarget

Nous avons donc préparé un petit script qui vous permettra d’un coup, d’un seul, de supprimer une target iSCSI multipath d’un ESX(i) et faire un rescan :

Petit détail : Sur ESX 4, pas besoin de rebooter après le remove, un rescan suffit à faire disparaître la (ou les) LUN présentée(s) par la target. Par contre, sur ESX 3.5 il faut rebooter ou masquer la LUN puis faire un rescan.

download

Tags: iSCSI, PowerCLI, powershell

Même avec 31°C à l’ombre, nous continuons notre travail sur vCheck : 3 nouveaux checks au programme.

• Hardware status warnings/errors (Toutes les informations de l’onglet Hardware Status n’étant pas remontés en alarmes)
• Cluster Nodes version check (Permet de vérifier rapidement l’uniformité des versions au sein d’un cluster)
• Disk Max Total Latency check (liste les ESX(i) 4.x ayant enregistré des temps de latence maxi supérieurs à un seuil défini)

Résultats dans un report :

Pour obtenir la nouvelle version, rendez vous dans la rubrique vCheck du blog.

Tags: PowerCLI, powershell, vCheck

Longtemps nous avons lu avec délectation les posts interposés de Duncan Epping et Frank Denneman au sujet des performances liées aux queue depths QLogic et Emulex. Le maître mot en matière de tuning étant de ne modifier une valeur que pour une raison très très valable ou pour un problème identifié, nous nous sommes toujours abstenu de modifier ces fameuses valeurs (en production du moins).

Heureusement pour nous, le jour tant attendu est enfin arrivé : nous avons identifié une contention d’I/O sur du SAN ! Après avoir vérifié que le problème ne venait pas de l’infrastructure SAN, nous allions pouvoir procéder à l’augmentation des files d’attente sur les ESX.

Seul petit problème, en powershell/powercli comme en esxcli, cette valeur ne peut être modifiée que connecté directement au serveur.

Pour un cluster il faut donc prévoir un script qui se connecte sur chaque serveur avec les bons credentials pour modifier le bon module.

Nous avons donc écrit un petit script qui fait tout cela, et plus encore puisque le ou les noms des modules sont variabilisés (il peut donc servir pour autre chose que les Queue Depth). Il est possible de gérer une collection de passwords et de modules (si par exemple votre cluster contient des ESX avec passwords diffèrent et cartes SAN différentes).

Il suffit de se connecter au vCenter pour transmettre au script la liste des host à traiter (il est possible de les lui transmettre via une liste de FQDN) pour afficher l’existence du module à traiter ainsi que ses options. Pour la modification, il suffit d’ajouter le paramètre “set” ou “unset” :

Et n’oubliez pas le reboot pour que cette valeur soit prise en compte

download

Tags: PowerCLI, powershell, scripting

Upgrading VMware Tools in a virtual desktop causes PCoIP connections to fail

To avoid this issue, do not upgrade to ESX 4.0 Update 2 if you are using View 4.x with PCoIP.

Si vous utilisez View 4 en environnement ESX 4.0 U1, ne bougez plus et soyez attentif à la résolution de ce problème sur cette kb.

Tags: bug, view

vCenter, ESX 4 et ESXi 4 viennent d’atteindre l’Update 2. La grosse nouveauté c’est esxtop (ou resxtop) qui peut maintenant afficher les diverses infos liées au stockage en environnement NFS. Avant cela, c’était vscsiStats qu’il fallait utiliser pour le troubleshouting mais obligatoirement via le Tech Support Mode dans le cas d’ESXi. Le reste de l’update concerne correction de bug et support d’OS/materiel supplémentaire mais un détail à retenu notre attention :

When using the Delete All option in Snapshot Manager, the snapshot farthest from the base disk is committed to its parent, causing that parent snapshot to grow

This issue is resolved in this release in that the order of snapshot consolidation has been modified to start with the snapshot closest to the base disk instead of farthest.

Exit les snapshots surprise

Pour ceux que ca intéresse, VDR passe en version 1.2 avec quelques nouveautés intéressantes :

• File Level Restore (FLR) is now available for use with Linux.
• Each vCenter Server instance supports up to ten Data Recovery backup appliances.
• The vSphere Client plug-in supports fast switching among Data Recovery backup appliances.

Tags: backup, update