Hypervisor.fr

MAJ 23/05/2015 : Et un petit screenshot du firewall pour la route:

Aussi farfelu que cela puisse paraître, une nouvelle partie de notre homelab est *temporairement* connecté sur du CPL. Et du coup, “les débits doivent être pourris ?!” me demanderez vous. Et bien figurez vous que nous nous sommes posé la même question au moment de connecter un ESX sur cette portion de notre réseau domestique !

Pour tester un segment de réseau rien de tel qu’iperf évidement mais nous ne voulions pas faire le test entre 2 VM, entre 2 ESX c’est beaucoup plus intéressant… Nous avons donc déterré un vieux post du forum vm-help où danisoto détail que le binaire iperf i386 pour rhel5 fonctionne nativement sur ESXi. C’était à l’époque d’ESXi 4 mais le binaire fonctionne toujours aussi bien sur ESXi 5.5 :

Après quelques tests où nous avons du désactiver (temporairement) le firewall d’ESXi faute de règle associée, nous avons pensé qu’il serait bien pratique d’avoir une jolie vib avec une version uptodate d’iperf, une règle de firewall custom et une “SecPolicy”…

Un petit coup d’ESXi5-CPT plus tard, et nous voila avec une vib contenant la version 2.0.5-1 i386 d’iperf (pour laquelle nous avons honteusement pompé le binaire d’un rpm plutôt que de le compiler nous même #shame) et la règle de firewall qui ouvre le port 5001 en TCP/UDP :

Pour information, nous n’avons pas pu compiler de version 2.0.5-11 ni de version 3.x fonctionnelle mais la v2 semble la plus répandue à ce jour et la version 2.0.5-1 ne semble pas souffrir de bug majeur.

Ce petit exercice nous a permis de découvrir le “VMkernel Access Control System” (SecPolicy) qu’Andreas décrit dans l’un de ses posts dédiés à la création d’une vib. Sans son aide on y serait encore… Vielen Dank! Au passage, pour faire passer la secpolicy, il faut impérativement le level “VMwareAccepted” ce qui rend le –no-sig-check obligatoire malheureusement.

Pour ceux qui ont la chance de pouvoir accéder au net depuis leur ESXi, la vib est disponible sur le vibsdepot d’Andreas, sinon c’est ici :

iperf-2.0.5-1

Tags: iperf, network benchmark, vib, VmkAccess

MAJ 21/05/2014 : Mise à jour du script (version 1.2) : Ajout de la taille des disk VMware/Windows

MAJ 25/04/2014 : Mise à jour du script (version 1.1) : A la demande express de notre ami DR, nous avons rajouté le paramètre -VIX pour faire la requête WMI via les vmtools et le paramètre -noSSO pour spécifier des credentials autre que ceux de votre session courante. A ce propos, et à notre plus grande surprise, la cmdlet Invoke-VMScript semble dorénavant supporter le SSO donc si votre compte AD à les bons droits sur le vCenter et dans le GuestOS, plus besoin du paramètre “GuestCredential” pour faire du VIX !

Lorsqu’on vous demande de retirer quelques disques d’une VM Windows qui en possède une cinquantaine, c’est généralement le début d’une longue chasse où on essaye de faire correspondre les id scsi, les contrôleurs ou les tailles de volume quand on est vraiment au bout du rouleau…

Il y a bien des scripts PowerCLI pour surmonter la tâche mais l’élément de référence est toujours l’id scsi ce qui pose parfois des problèmes comme ça l’à été pour nous lors d’une opération similaire :

Une kb VMware décrit comment faire une correspondance via le device manager de windows (et non pas le disk manager) mais où il faut chercher à la main la propriété “location” qui correspond au contrôleur scsi :

To correlate the virtual device node SCSI controller to the Windows drive letter. Each controller increments by 32.
The first SCSI controller is given a location ID of 160. Therefore the second controller is 192, 224 for the third and 256 for the fourth.

Nous vous laissons apprécier l’ampleur de la tache lorsqu’on a plusieurs disques à détacher :

En cherchant un peu sérieusement, nous avons trouver un point commun parfaitement identique entre Hard disk et PHYSICALDRIVE : l’UUID (ou SerialNumber sous Windows). Un petit coup de PowerCLI plus tard, on obtient un beau tableau pour faire la correspondance sans risque (avec le chemin du vmdk en bonus) :

Les prérequis du script sont que vous soyez connecté au bon vcenter et que vous puissiez accéder en WMI à la VM en question (si le FQDN de la vm ne correspond pas à son nom, il faut utiliser le paramètre -winname). Le paramètre -grid controle la sortie dans un GridView pour ceux qui n’aime par le style CLI :

Get-VMWinUUIDMap

Tags: PowerCLI, UUID, vmdk, Win32, WMI

Comme chaque année depuis 2010 c’est un honneur de voir apparaître son nom dans la liste des vExpert (750+ cette année). Merci encore pour votre soutien, vos réactions, vos commentaires et bravo à tous les nominés.

Tags: vExpert

Lorsque nous critiquons Hyper-V c’est évidement dans l’optique de voir mûrir le produit. Malgré tout, on ne peut pas s’empêcher de penser qu’il reste encore un peu de chemin…

Tags: Bullshit

Ceux d’entre nous qui faisons de l’administration d’infrastructure vSphere au quotidien ont au moins une fois entendu la fameuse phrase “Mais pourquoi DRS ne fait rien alors que le cluster n’est pas équilibré ?!“. Le sujet à déjà largement été traité par des références dans le domaine comme l’est Frank Denneman mais nous allons reformuler la raison une bonne fois pour toute et en français : DRS ne déclenchera un vmotion que si le gain du déplacement est supérieur à son coût.

Evidemment il y a un algorithme complexe, du paramétrage et des seuils variables pour rendre le mécanisme suffisamment intelligent mais dans le cas d’un cluster pas ou peu overcommité (cpu et/ou ram uniquement), le déséquilibre est une situation “normale” puisque le coût d’un vmotion sera presque toujours supérieur a son bénéfice. DRS estime le gain à partir de la demande des vm et n’a de raison d’agir que si elles ne peuvent pas obtenir les ressources demandées. Le bon nivellement des VM dans le cluster n’est absolument pas pris en compte. De plus, DRS fait une projection de ce que la vm pourrait consommer dans un futur proche en fonction des statistiques passées afin de ne pas réagir trop tard.

Néanmoins, dans certains cas il peut s’avérer nécessaire de forcer DRS à “secouer” un peu le cluster pour répartir les vm. Après une opération de maintenance ou de façon proactive (moins de vm par host=moins de conséquences en cas de crash) ou encore pour niveler les I/O disque/réseau pas (encore) pris en compte par DRS.

Nous nous sommes justement retrouvés dans cette situation suite à l’ajout de plusieurs host dans un cluster 5.0 U1 et face à l’immobilisme de DRS, nous nous sommes souvenus d’un post détaillé de Frank à ce sujet faisant référence à une kb vmware.

This issue may occur in an environment with a large number of relatively low demand virtual machines

Il s’agit de modifier *temporairement* les paramètres MinGoodness et CostBenefit pour que DRS déclenche un vmotion à la moindre occasion sans en considérer le coût. le résultat est immédiat :

Depuis vSphere 5.1, l’algorithme de DRS à été modifié pour palier à des situations similaires (vSphere 4.1 U3 et vSphere 5.0 U2 intègre aussi la modification) mais il est toujours possible de forcer si besoin avec d’autres paramètres :

Starting with this release, DRS algorithm is improved to better balance the load in a DRS cluster. If you notice that the cluster is still not balanced with the default settings, you can configure the advanced DRS options with the following values and run DRS to further improve the load balancing capability of the DRS cluster:

SevereImbalanceDropCostBenefit 1
FixSevereImbalanceOnly 0

Tags: Distributed Resource Scheduler, DRS, overcommit