Hypervisor.fr

Nous découvrons par hasard l’existence  du paramètre “-kill” de la cmdlet Stop-VM :

Indicates that you want to stop the specified virtual machines by terminating their processes running on the ESX. You can use this parameter to stop a virtual machine that is not responding and cannot be stopped or restarted in other ways.

Cela ressemble fortement à un kill des process vmx dans un shell, via esxtop ou esxcli mais nécessiterai d’être connecté à l’ESXi plutôt qu’au vcenter :

To use the Kill parameter, you need to have a direct connection to ESX 4.1 or later.

Mais une fois de plus le monkey test à payé, nous testons la commande en étant connecté au vcenter et ça marche. la vm est littéralement killée sans aucune tache apparente dans le vcenter ni sur l’ESX et HA la restart :

Nous avons également vérifié avec Wireshark qu’aucune communication n’avait lieu entre le client PowerCLI et l’ESXi.

Tags: FDM, HA, PowerCLI, powershell, sso, Wireshark

Le stretched cluster c’est un peu l’ultime fantasme de tous les admin VMware car il permet de couvrir le crash d’un serveur ou d’un site avec un seul et même design.

Malheureusement, si vous ne voulez pas investir dans une solution telle que SRM, Zerto ou VPLEX ou encore si vous aspirez à plus de simplicité, le failback des VM peut rapidement se transformer en cauchemar (register de vmx à la main par exemple). En effet, depuis vSphere 5.0, HA (aka FDM) est capable à lui seul d’assurer le redémarrage des VM (failover) dans un stretched cluster tant que le stockage d’un site est répliqué sur l’autre site et présenté aux ESX après un crash (extrais tiré de VMware vSphere 5 Clustering Technical Deepdive) :

The master [agent] will also attempt to take ownership of any datastores it discovers along the way, and it will periodically retry any it could not take ownership of previously.

Il est donc possible d’envisager un cluster étendu sur 2 sites où HA serait capable de redémarrer les VM d’un site crashé après une simple manipulation coté stockage. Après de nombreux tests, il s’avère que cette solution est parfaitement fonctionnelle mais elle souffre néanmoins d’un gros problème : le failback. En effet, lorsqu’il est question de renvoyer les VM sur leur site initial, il est nécessaire d’arrêter les VM pour re-synchroniser le stockage et redémarrer les VM sur le site primaire. Lors de cette opération, on se retrouve inévitablement confronté à des VM “inaccessible” :

A partir de ce moment, il n’est plus possible de faire autre chose que d’enregistrer les VM manuellement sur un des ESX (directement) du site primaire et laisser l’agent vpx faire le reste. Evidemment, c’est l’un des pires scénarios mais il existe des solutions comme celle de faire un storage vmotion pour déplacer les VM sur un autre espace de stockage avant de faire les opérations sur les baies mais bien qu’il soit possible de faire le failback à chaud dans ce cas, il faut prévoir un espace supplémentaire non négligeable et trop de manipulations à nos yeux.

Après avoir travaillé un certain temps sur le sujet avec notre ami vmdude.fr, nous avons trouvé LA solution la plus élégante pour qu’un passage en production soit envisageable. Elle nécessite quelques manipulations simples et parfaitement scriptables. A vrai dire, la solution était sous notre nez depuis le début et existe depuis longtemps car utilisé dans un autre cas de figure. Il y a même de forte chance pour que vous vous en soyez déjà servi une fois… Lorsqu’une VM est configurée pour ne pas être redémarrée par HA, elle apparaît comme “disconnected” tant que l’ESX n’est pas redémarré (lui aussi est “disconnected” d’ailleurs “not responding”) et dans cet état, vous pouvez démarrer cette VM car vcenter va automatiquement enregistrer la VM ailleurs alors qu’il ne peut plus communiquer avec l’ESX pour “unregister” la VM. Nous avons donc utiliser cette fonctionnalité pour “cacher” au vcenter les manipulations de stockage en regroupant les VM sur un ESX que l’on déconnectera avant. Ouvrez grand les yeux :

La liste des commandes PowerCLI utilisées est disponible ici, elles doivent évidement être modifiées pour correspondre à votre environnement (nom de cluster, ESX et resource pool). Voici un récapitulatif des étapes post crash :

• <==failover==>
• présentation du stockage aux ESX
• montage des snapshot VMFS ou des shares NFS
• <==failback==>
• shutdown des VM
• move des VM sur l’ESX helper
• enter maintenance mode de l’ESX helper
• disconnect de l’ESX helper
• *disable SIOC*
• démontage des snapshot VMFS (ou des share NFS)
• failover du stockage
• Power on des VM
• reconnect de l’ESX helper
• exit maintenance mode de l’ESX helper

Une autre solution consiste à présenter un petit espace temporairement à tous les ESX (un share NFS est ideal dans ce cas) afin d’y déplacer uniquement la “home” de la VM (vmx, log, etc…) avec un svmotion scripté afin d’éviter l’état “inaccessible” et pouvoir facilement redémarrer les VM après la re-synchronisation du stockage. L’avantage est qu’il n’est pas nécessaire de “sacrifier” un ESX mais cela rajoute des manipulations au PRA et un espace de stockage à gérer en plus.

Tags: DRP, HA, PowerCLI

MAJ 03/10/2015 : mise à jour du script (version 1.2) correction de bug et ajout sur GitHub.

MAJ 10/10/2013 : mise à jour du script (version 1.1) correction de bug.

Après avoir fait des tests de drivers Emulex sur un cluster, nous avons voulu savoir quelle version de la vib lpfc820 était installée sur chaque host. Pas évident même avec VUM, nous avons donc fait un petit coup de get-esxcli sur tous les ESX pour comparer la list mais bon voila, c’était pas pratique non plus. Au passage, nous nous sommes aperçu que certaines vib du constructeur n’étaient pas à la même version sur tous les serveurs. On a dû faire chauffer le notepad++ !

Voici donc un script de reporting de vib qui renvoi la liste des serveurs dont certaines vib sont différentes de la majorité du cluster :

Vous avez la possibilité d’utiliser les paramètres suivants :

• cluname : nom du cluster dont sera tirée la liste des ESX connectés au vcenter
• fullviblist : 1 renvoi une liste non filtrée dans un out-gridview
• compactviblist : 1 renvoi une liste filtrée (ESX et vib)
• compactviblistout : “csv” ou “view” pour avoir la liste en csv ou dans un out-gridview plutot quand dans la console

Vous pouvez l’exécuter sur plusieurs cluster grâce à une simple boucle :

En mode compacte, seules les vib qui comportent une différence sont remontées et la colonne “majority” représente le serveur de référence (un de ceux qui ont exactement les mêmes vib et à la même version). Le symbole == indique que la version de la vib est identique à la vib de la majorité.

get-vibdiff

Tags: compliance, esxcli, PowerCLI, powershell, vib

On attend toujours la dispo officielle de vSphere 5.5 annoncée au VMworld US 2013 mais comme d’habitude on a droit à une avalanche de posts de la part de tous les beta testeurs en manque de créativité avec des morceaux de screenshot dedans. Comme c’est pas le genre de la maison, on va se contenter de spéculer sur une “nouvelle” feature qui a déjà eu droit à son whitepaper : VM Latency Sensitivity.

In order to support virtual machines with strict latency requirements, vSphere 5.5 introduces a new per-VM feature called Latency Sensitivity.

Cela nous a fait curieusement penser à une autre feature disponible dans la version 5.1 : VM Latency Sensitivity.

vSphere 5.1 simplifies the process of configuring a virtual machine to support low-latency applications. It now offers a latency sensitivity advanced setting that automatically makes low-level changes in the vSphere kernel to reduce latency for the virtual machine.

Ah tiens c’est bizarre, elles ont le même nom…

Vous constaterez qu’il n’en est nullement fait référence dans le whitepaper de la 5.5 donc impossible de savoir si c’est “vraiment” une nouvelle fonctionnalité, la même fonctionnalité améliorée ou un gros pipeau.

En attendant d’en savoir plus, on vous a préparé un petit oneliner pour activer la fonctionnalité et même fixer le nombre de µs secondes que vous souhaiter (2000 dans notre exemple) :

Get-VM "Flash_Gordon"|Get-View|?{-not $_.Config.Template}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{latencySensitivity=(New-Object VMware.Vim.LatencySensitivity -Property @{level="custom";sensitivity="2000"})}))}

Et pour savoir ce qui a été configurer :

(Get-VM "Flash_Gordon"|Get-View).Config.LatencySensitivity

Tags: Bullshit, PowerCLI, powershell

Quand on joue un peu trop “le cowboy de l’overcommit”, on peut se retrouver dans une situation où les VM et donc les datastore sont pleins de vide : les filesystem des VM ont été rempli au moins une fois mais ont été vidé depuis. Il y a plusieurs moyens de palier à cela mais avant il est intéressant de savoir quelle volumétrie serait récupérable. Donc on a fait péter le oneliner :

Get-View -ViewType virtualmachine -Property Name, Summary, Config, Guest|?{!$_.snapshot -and $_.Guest.GuestFamily -eq "windowsGuest" -and $_.Guest.ToolsRunningStatus -eq "guestToolsRunning"}|?{!($_.Config.Hardware.Device|?{$_ -is [VMware.Vim.VirtualDisk]}|?{$_.Backing.ThinProvisioned}) -eq $false}|select name, @{n="GuestId";e={$_.Guest.GuestId}}, @{n="vmdkCommitted";e={[math]::round($_.Summary.Storage.Committed/1GB,1)}}, @{n="GuestCommitted";e={[math]::round(($_.Guest.Disk|%{$_.Capacity - $_.FreeSpace})/1GB,1)}}, @{n="ThinDiff";e={[math]::round((($_.Summary.Storage.Committed - (($_.Config.Hardware.MemoryMB*1MB - $_.Config.MemoryAllocation.Reservation) + $_.Config.InitialOverhead.InitialSwapReservation)) - ($_.Guest.Disk|%{$_.Capacity - $_.FreeSpace}))/1GB,1)}}|?{$_.ThinDiff -gt 20}|Out-GridView

Ce petit bout de script vous affichera un beau tableau des VM (windows uniquement – pour l’instant) dont la différence entre la taille commitée outGuest (vmdk) et inGuest (ntfs) est supérieure à 20Go.

Tags: overcommit, thin provisioning, TRIM, UNMAP, vmdk