By restricting ESXi Shell access for the vpxuser, you prevent attackers, which can also be insiders who have access to vCenter Server the ability to just change the ESXi root password without knowing the original password.

Après l’énorme succès de notre billet Administrators = root qui vous permet de reset le mot de passe root de vos ESX sans le connaître (si vous êtes admin du vCenter) grâce à Get-EsxCli, voici une nouvelle méthode utilisable depuis vSphere 6.7 U2 qui nécessite encore moins de droits :

Updates a local user account using the parameters defined in the HostLocalAccountManagerAccountSpecification data object type.

Required Privileges Host.Local.ManageUserGroups

(Get-View (Get-VMHost|Get-View).ConfigManager.AccountManager).UpdateUser($(New-Object VMware.Vim.HostAccountSpec -Property @{id="root";password="VMw4re!"}))

Attention, contrairement à la méthode Get-EsxCli, cette fois un petit event va vous trahir instantanément :

Datastore UUID is required when a cluster UUID is specified

Get-VMHost|%{($_|get-esxcli).vsan.datastore.add($null, "vsanDatastore2", "11111111-1111-1111-1111-111111111111")}

En utilisant $null pour la propriété ClusterUUID, ca passe crème.

MAJ 18/05/2021 : On me signale dans l’oreillette que VMware supporterai officiellement cette méthode :

Engineering have advised that the procedure you are carrying out is applicable to your specific need and is considered supported from us

Tous les admin VMware le savent, après renommage d’une VM il convient de faire un petit Storage vMotion (aka d-motion pour les boomers) pour “propager” le nouveau nom aux fichiers de la VM en question. Et pour ceux qui l’ignorait encore, cette feature était un bug jusqu’à la version 5.0 U2 d’ESXi.

Évidement, cela nécessite d’avoir un 2eme datastore (idéalement avec des performances identiques et la bonne volumétrie) pour faire l’aller-retour de la VM (ou un Storage Pod) ce qui n’est pas souvent le cas sur un cluster vSAN pour des raisons évidentes.

Jusqu’à maintenant, les seules solutions étaient de … ne rien faire ou de connecter un datastore NFS ponctuellement pour faire le svmotion. Mais en cherchant à faire du HCI mesh en ligne de commande nous sommes tombé sur la solution (très discrètement documenté) : esxcli vsan datastore add pour créer un 2eme datastore sur le vmdk namespace.

Cette feature semble être apparu à partir de la version 6.7 U3 et est évidement accessible en PowerCLI également. Il suffit donc d’ajouter un “datastore” vSAN en précisant le nom et l’UUID de votre choix si vous le souhaitez. Il est nécessaire d’exécuter cette même commande sur tous les ESX du cluster avec le même nom et le même UUID.

Add a new datastore to the vSAN cluster. This operation is only allowed if vSAN is enabled on the host. In general, add should be done at cluster level. Across a vSAN cluster vSAN datastores should be in sync.

Voila ce que ça donne sur un cluster à 3 noeuds :

On peut donc maintenant faire notre svmotion aller-retour sans perte de performances.

Une fois l’operation terminé on peut utiliser la commande “remove” en precisant le nom et l’UUID du datastore ou carrément la commande “clear” :

Remove all but the default datastore from the vSAN cluster. This operation is only allowed if vSAN is enabled on the host. In general, add should be done at cluster level. Across a vSAN cluster vSAN datastores should be in sync.

Et aucun risque de se rater, si une vm est toujours présente sur le datastore, vous aurez droit à une belle erreur. Après avoir fait du ménage, ça passe crème :

Pour résumer, nous avions besoin d’exécuter un script situé sur un share depuis un ensemble de VM et nous avons bien évidement tenté de profiter du fait que VIX supporte le SSO, comme des gros fainéants. Et là, c’est le drame:

When using Integrated Security, anonymous access is disabled, and impersonation is turned on, a security measure kicks in and doesn’t allow your site to access resources on any network servers.  This includes access to a UNC path directly from IIS or SQL Server using Windows authentication.

Il nous a suffit de passer les credentials à l’Invoke-VMScript pour que l’UNC devienne accessible:

Nous avons ajouté la taille de la VM pour vous motiver à faire un VeeamZIP et à en finir définitivement avec ces VM qui risque d’être redémarrées après un crash d’ESX…

get-view -viewtype virtualmachine -property name,runtime,layoutex|?{$_.Runtime.PowerState -eq "poweredOff" -and $_.Runtime.ConnectionState -eq "connected" -and !$_.config.template}|?{$_.LayoutEx.File|?{$_.type -match "nvram"}}|%{$_|select Name, @{n="Modification";e={((get-view (get-view -viewtype datastore –filter @{"Name"=($_.LayoutEx.File|?{$_.type -eq "nvram"}).name.split("[]")[1]}).browser).SearchDatastore(($_.LayoutEx.File|?{$_.type -eq "nvram"}).name.split("/")[0],(New-Object VMware.Vim.HostDatastoreBrowserSearchSpec -property @{matchPattern=("*.nvram"); details=(New-Object VMware.Vim.FileQueryFlags -property @{modification=$true})}))|%{$_.file}).Modification}}, @{n="SizeGB";e={[math]::round(($_.LayoutEx.File|measure -Property size -sum).sum/1GB,1)}}}

In Virtual SAN 6.2, we introduced an advanced host setting called SwapThickProvisionDisabled, when enabled, removes the space reservation for .vswp files.

Une preuve de plus, s’il en fallait, que la bataille du SDS/HCI est rude jusqu’à en rogner ses best practices. En effet, nous rappelons à ceux qui auraient un trou de mémoire que placer le fichier de swap d’une VM sur un stockage “thin provisioné” va à l’encontre de toutes les bonnes règles de gestion et d’overcommit.

Do not store swap files on thin-provisioned LUNs. Running a virtual machine with a swap file that is stored on a thin-provisioned LUN can cause swap file growth failure, which can lead to termination of the virtual machine.

Regardless of the storage type or location used for the regular swap file, for the best performance, and to avoid the possibility of running out of space, swap files should not be placed on thin-provisioned storage.

Qu’importe, ca nous arrange bien aussi et pour l’occasion nous avons fait peter un petit oneliner pour fixer la bonne valeur :

Get-VMHost|%{(Get-EsxCli -VMHost $_).system.settings.advanced.set($null,"1","/VSAN/SwapThickProvisionDisabled",$null)}

Et un autre pour vérifier que c’est bien appliqué :

Get-VMHost|%{(Get-EsxCli -VMHost $_).system.settings.advanced.list($null,"/VSAN/SwapThickProvisionDisabled",$null)}

Avec un petit coup de SexiGraf pour monitorer le tout, on est bon :

Due to changes in Microsoft’s virtual machine generation counter specification that was introduced in the Windows 8 Release Preview and Windows Server 2012 RC, corresponding changes were also required in the virtual machine BIOS. Snapshots, checkpoints and VMotion actions of virtual machines with these versions of Windows are not compatible between ESXi hosts that have implemented different revisions of Microsoft’s virtual machine generation counter specification.

Snapshots and checkpoints of virtual machines with Windows 8 or Windows Server 2012 that are taken on a host running ESXi 5.0 Update 1 or ESXi 5.0 P03 will not resume on a host running later versions of ESXi ( ESXi 5.0 Update 2, ESXi 5.1, etc.) and the reverse.

VMotion is prevented between hosts running ESXi 5.0 Update 1 or ESXi 5.0 P03 to and from hosts running later versions of ESXi.

2015-11-05T15:01:32.804Z| vmx| I120: DUMPER: Group ‘VMGenCtr’ not found.
2015-11-05T15:01:32.804Z| vmx| I120: CPT: could not find group VMGenCtr
2015-11-05T15:01:32.804Z| vmx| I120: DUMPER: Item ‘AddrReg’ [-1, -1] not found.
2015-11-05T15:01:32.804Z| vmx| I120: DUMPER: Item ‘CtrCount’ [-1, -1] not found.
2015-11-05T15:01:32.804Z| vmx| I120: DUMPER: Item ‘CtrCountX’ [-1, -1] not found.
2015-11-05T15:01:32.804Z| vmx| I120: VMGenCtrCheckpoint: Failing restore from old Win8 checkpoint
[...]
2015-11-05T15:01:32.804Z| vmx| I120: [msg.checkpoint.migration.failedReceive] Failed to receive migration.
2015-11-05T15:01:32.804Z| vmx| I120: [msg.checkpoint.mrestoregroup.failed] An error occurred restoring the virtual machine state during migration.

Evidemment la solution proposée par VMware passe par un shutdown de la VM mais lors d’une grosse migration ça fait pas sérieux donc nous avons cherché un vrai workaround.

Sachant que cette feature est exclusivement utilisé par Active Directory Domain Services (pourquoi l’imposer à toutes les VM d’ailleurs ?!), nous avons chercher à la désactiver pour que le resume du vmotion sur l’ESXi de destination ne pose plus de problème. Et pas plus loin que dans une autre kb vmware, nous avons trouvé la solution:

The workaround involving adding the vmGenCounter.enable parameter to the virtual machine .vmx file may cause the new snapshot protection for domain controllers introduced in Windows 8/Windows Server 2012 to stop functioning.

Un petit coup de PowerCLI pour appliquer le setting à chaud :

Get-VM Windows2012R2|Get-View|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=@((New-Object VMware.Vim.optionvalue -Property @{Key="vmGenCounter.enable";Value="FALSE"}))}))}

Et le vmotion passe en douceur

Nous étions parti pour utiliser le script disponible sur VSANTeam.info mais il est malheureusement faux car il n’inclus pas l’objet VsanHostDecommissionModeObjectAction et donc le mode “ensureObjectAccessibility” est utilisé par défaut. Donc pour pouvoir utiliser le mode “evacuateAllData” ou “noAction” c’est comme ça qu’on fait :

Get-View -ViewType HostSystem -Filter @{"Name" = "esx.vmware.com" }|?{!$_.Runtime.InMaintenanceMode}|%{$_.EnterMaintenanceMode(0, $false, (new-object VMware.Vim.HostMaintenanceSpec -Property @{vsanMode=(new-object VMware.Vim.VsanHostDecommissionMode -Property @{objectAction=[VMware.Vim.VsanHostDecommissionModeObjectAction]::NoAction})}))}

Sinon vous pouvez aussi le faire avec Get-EsxCli en vous inspirant du post de William.

Historiquement, il était un peu complexe de générer ce genre d’interruption comme le détail William mais avec cette nouvelle API cela devient un jeu d’enfant en PowerCLI :

(Get-VM toto|Get-View).SendNMI()

Malheureusement, connecté au vCenter, on se mange une jolie erreur :

Exception calling “SendNMI” with “0″ argument(s): “The requested operation is not implemented by the server.”

Connecté en direct sur un ESX ça se passe nettement mieux :

En prime, on droit au nouvel événement VmGuestOSCrashedEvent :

<166>NoneZ visor04.lab.schitz.org Hostd: 2015-06-04T22:21:45.933Z info hostd[6DE83B70] [Originator@6876 sub=Vimsvc.ha-eventmgr] Event 894 : Win10 on visor04.lab.schitz.org: Guest operating system has crashed.

Et voici le oneliner PowerCLI pour le faire vite et bien :

Get-View -ViewType HostSystem|?{$_.Runtime.ConnectionState -eq "connected" -and $_.config.product.ProductLineId -eq "embeddedEsx" -and ($_.Config.Option|?{$_.Key -eq "Misc.SIOControlLogLevel"}).Value -ne "1"}|%{(Get-View $_.ConfigManager.AdvancedOption).UpdateOptions((New-Object VMware.Vim.OptionValue -Property @{Key="Misc.SIOControlLogLevel";Value=[Int64]1}))}

Que ce soit pour créer de nouvelles alarmes dans le vCenter ou parce que certains messages d’alerte ne sont visible que dans les logs d’ESXi, nous avions autrefois recours à la page vCenter Events de Veeam pour trouver l’inspiration. Cette page n’étant plus mise à jour depuis fin 2011, nous avons chercher à produire un page similaire pour nos propres besoins et l’avons, depuis quelques temps, mise à dispo dans la rubrique “Links”. Voici la commande PowerCLI qui vous permettra de générer la votre depuis votre vCenter (et plugins) :

(Get-View EventManager).Description.EventInfo|select @{n="event";e={if ($_.key -match "^EventEx$|^ExtendedEvent$") {$_.FullFormat.split("|")[0]} else {$_.key}}},category,description,FullFormat|Out-GridView

Nous nous sommes très largement inspiré d’un post de Luc pour ce oneliner

Récemment, William à posté une liste similaire issue d’un fichier disponible en clair dans les librairies d’ESXi mais nous avons remarqué qu’il ne contenait pas les événements vob.* que nous pouvions trouver dans les logs. Après quelques recherches, nous avons fini par faire un coup de strings sur le binaire /usr/lib/vmware/vob/bin/vobd (issue d’un ESXi 5.5 1331820) pour en extraire les précieux messages. Nous avons ensuite “dédoublonné” la liste obtenue (vob.vmfs.heartbeat.timedout == esx.problem.vmfs.heartbeat.timedout par exemple) pour ne garder que le différentiel :

vob.net.fence.port.fail
vob.net.pg.uplink.transition.down
vob.net.pg.uplink.transition.up
vob.net.dvport.uplink.transition.down
vob.net.dvport.uplink.transition.up
vob.net.uplink.watchdog.timeout
vob.net.migrate.bindtovmk.failed
vob.net.portset.port.connect.fail
vob.net.lacp.uplink.peer.noresponse
vob.scsi.scsipath.add
vob.scsi.scsipath.remove
vob.scsi.scsipath.por
vob.scsi.scsipath.badpath.unsafepe
vob.scsi.scsipath.badpath.unreachpe
vob.scsi.scsipath.pathstate.dead
vob.scsi.scsipath.pathstate.off
vob.scsi.scsipath.pathstate.on
vob.scsi.scsipath.pathstate.standby
vob.iscsi.connection.started
vob.iscsi.connection.stopped
vob.iscsi.connection.error
vob.iscsi.target.async.event
vob.iscsi.session.recovery.timeout
vob.iscsi.target.permanently.removed
vob.iscsi.isns.discovery.error
vob.vmfs.lock.corruptondisk.v2
vob.user.dcui.factory.network.restored
vob.user.dcui.restarting.hostagents
vob.user.dcui.restore.factory.defaults
vob.user.dhclient.lease.offered.noexpiry
vob.user.coredump.unconfigured2
vob.user.coredump.capacity.insufficient
vob.user.scratch.partition.size.small
vob.user.scratch.partition.unconfigured
vob.user.dcui.reboot.host
vob.user.dcui.shutdown.host
vob.user.esxcli.host.reboot
vob.user.coredump.configured2
vob.cpu.mce.log
vob.cpu.nmi.ipi.vmkcs
vob.cpu.nmi.ipi.unknowncs
vob.cpu.nmi.ipi.halt
vob.cpu.nmi.ipi.savebt
vob.uw.core.dumped
vob.external.warning
vob.external.error
vob.external.info
vob.user.external.warning
vob.user.external.error
vob.user.external.info
vob.visorfs.tardisk.readonlyfile
vob.vsan.pdl.offline
vob.vsan.pdl.online
vob.vsan.net.gotip
vob.vsan.net.noip
vob.vsan.rdt.noip
vob.vsan.net.no.connectivity
vob.vsan.net.created
vob.vsan.net.reconfigured
vob.vsan.cmmds.disabled
vob.vsan.cmmds.unloaded
vob.vsan.cmmds.enabled
vob.vsan.lsom.diskerror

Pour les curieux, voici la liste originale.

La seule référence que nous ayons pu trouver à ce sujet est une kb d’un path pour ESXi 5.0, dommage.

En passant, nous vous rappelons qu’il est possible de rediriger le log d’une VM vers le syslog d’ESXi pour vous éviter de fouiller dans le fichier vmware.log et c’est bien sûr faisable à chaud en PowerCLI (comme d’hab, vmotion pour appliquer le setting) :

Get-VM toto|Get-View|?{-not $_.Config.Template -and $_.Runtime.ConnectionState -eq "connected"}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=@((New-Object VMware.Vim.optionvalue -Property @{Key="vmx.log.destination"; Value="syslog-and-disk"}))}))}

Après on peut faire des belles requêtes dans son Graylog2 :

Un grand merci à William pour cette pépite.

La recette est assez simple : Image Builder pour générer l’Offline Bundle + Get-EsxCli pour l’update + Reboot. Du PowerCLI de bout en bout donc on est bon.

Dans notre cas, il fallait mettre à jour des serveurs HP et DELL de sorte que le résultat soit le même qu’avec la customized ESXi image fourni par les éditeurs. Malheureusement il est impossible d’utiliser une iso pour générer un Offline Bundle (indispensable à esxcli) et si vous vous demandez comment VUM y parvient, allez fouiller dans le répertoire /UPGRADE d’une iso d’ESXi et vous comprendrez… Pas le choix, il a fallut se taper les Bundle à la main !

La toute première étape c’est évidement le choix de la version d’ESXi à atteindre (ESXi 5.0 Complete Update 3) et de faire un clone de l’Image Profile afin de pouvoir le customizer en y ajoutant des packages :

Add-EsxSoftwareDepot https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

New-EsxImageProfile -CloneProfile ESXi-5.0.0-20131002001-standard -Name "VMware-ESXi-5.0.0-Update3-1311175-HP-5.44.21-Feb2014" -Vendor "Hypervisor.fr"

Si vous voulez voir la liste des build disponibles, l’idéal c’est un petit GridView :

Au passage, on peut apercevoir le process Image Factory Server (if-server.exe) qui fait office de moulinette :

HP propose depuis longtemps un vibsdepot (aka HP Online Depot) qui facilite grandement la tâche. Vous n’avez qu’à choisir le répertoire qui correspond à la date de l’iso (Feb2014 dans notre cas) et ajouter le dépôt (index.xml et index-drv.xml) à votre liste :

Add-EsxSoftwareDepot http://vibsdepot.hp.com/hpq/feb2014/index.xml, http://vibsdepot.hp.com/hpq/feb2014/index-drv.xml

Il faut ensuite ajouter les packages (un minimum filtrés pour éviter les insultes toutes rouge de powershell) au profil custom et l’exporter au format Bundle (.zip) :

Get-EsxSoftwarePackage|?{$_.SourceUrls -match "vibsdepot.hp.com/hpq/feb2014" -and !($_.Depends -match 'vmkapi_2_[1-9]')}|Add-EsxSoftwarePackage -ImageProfile "VMware-ESXi-5.0.0-Update3-1311175-HP-5.44.21-Feb2014"

Export-EsxImageProfile -ImageProfile "VMware-ESXi-5.0.0-Update3-1311175-HP-5.44.21-Feb2014" -ExportToBundle -FilePath "C:\Temp\VMware-ESXi-5.0.0-Update3-1311175-HP-5.44.21-Feb2014.zip"

Si vous voulez consulter la liste des package avant de les ajouter, encore un petit GridView :

Du coté de DELL c’est radicalement différent puisque leur dépôt ne contient que les vib “iDRAC Service Module” et “OpenManage”. Heureusement, en fouillant un peu nous avons pu trouver un pdf qui recense toutes les modifications apportées à l’iso originale de VMware pour parvenir à la version customizé made in DELL. S’en suit un travail de fourmi pour retrouver tous les offline bundle associés, les télécharger et les ajouter au profil custom.

Une fois que le bundle est prêt, un petit coup de Get-EsxCli pour le distribuer sur le même principe qu’ESXCLI mais a l’échelle d’un cluster :

Get-Cluster toto|Get-VMHost|%{($_|Get-EsxCli).software.profile.update($false, "/vmfs/volumes/datastore/HP/VMware-ESXi-5.0.0-Update3-1311175-HP-5.44.21-Feb2014.zip", $true, $null, $true, $null, $null, "VMware-ESXi-5.0.0-Update3-1311175-HP-5.44.21-Feb2014", $null)}

Il vous faudra évidement personnaliser le nom du cluster, le chemin du bundle ainsi que le nom du profil mais surtout changer la variable de dry run $true (celui juste après le path dans le oneliner) en $false pour effectuer la mise a jour. Ce oneliner ne fait que vérifier que la mise a jour est possible et vous permet de contrôler le process :

Pour plus d’informations, nous vous recommandons vivement de consulter la série de post “ImageBuilder Deep Dive” d’Andreas Peetz.

La touche finale c’est un oneliner qui reboot le cluster en séquentiel (DRS auto obligatoire et les ESX doivent avoir au moins 1 jour d’uptime) :

Get-Cluster toto|Get-VMHost|Get-View|?{$_.Runtime.BootTime -lt (Get-Date).adddays(-1) -and $_.Runtime.ConnectionState -eq "connected" -and !$_.Runtime.InMaintenanceMode}|%{$_.EnterMaintenanceMode("60",0);while (!(get-view -viewtype hostsystem -filter @{"name"=$_.name}).Runtime.InMaintenanceMode){sleep 15};$_.RebootHost(0);while ((get-view -viewtype hostsystem -filter @{"name"=$_.name}).Runtime.ConnectionState -eq "connected"){sleep 15};while ((get-view -viewtype hostsystem -filter @{"name"=$_.name}).Runtime.ConnectionState -eq "notResponding"){sleep 30};$_.ExitMaintenanceMode("60");while ((get-view -viewtype hostsystem -filter @{"name"=$_.name}).Runtime.InMaintenanceMode){sleep 15}}

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

Premier constat, le temps de compute des valeurs moyennes de cpu et ram est très important et c’est évidement proportionnel au nombre de nœuds. Pour optimiser ce script, nous nous somme rabattu sur les quickstats du resource pool “racine” du cluster (aka “resources”). Ces valeurs étant basé sur les 5 dernières minutes d’activité (et non sur les 24 dernières heures comme le script original), il faut l’exécuter au moment de la journée où l’activité du cluster est la plus importante pour avoir des valeurs vraiment représentatives du workload. Le gros avantage de ces valeurs est qu’il n’est pas nécessaire de faire une requête dans les statistiques, elles sont pré-computées et disponibles sous forme de propriétés, on passe donc d’une exécution pouvant aller jusqu’à plusieurs minutes à 2 secondes par cluster. Comme dirait Mozinor, “tu peux pas test”.

Deuxième constat, le mode “slot size” d’admition control ne tiens pas compte de l’overcommit. Duncan et Frank l’explique en détail dans leur bouquin mais voici un exemple encore plus parlant :

3 hosts sur 12 (25%) en mode “slot size” contre 67% en mode “resources”. Dans ce dernier mode, HA tiens compte de la consommation réelle du cluster pour déterminer ce qu’il reste.

With the resources failover policy in place, vSphere HA uses the following calculations to control virtual machine migration in the cluster
1. Calculate the total resource requirements for all powered-on virtual machines in the cluster.
[...]

Il est donc clair que sur des gros cluster avec de l’overcommit, le mode “slot size” est totalement inutilisable.

En attendant de déguster la dinde farcie aux marrons de tante Yolande, voici le oneliner powershell à deguster en amuse-bouche :

foreach ($cluster in (Get-View -ViewType ClusterComputeResource|?{$_.ConfigurationEx.DasConfig.Enabled})) {,($cluster|?{$_.host}|select @{n="mem";e={(($_|%{(Get-View $cluster.ResourcePool|?{$_.Parent -eq $cluster.Moref}).Summary.QuickStats.HostMemoryUsage/(Get-View -ViewType virtualmachine -SearchRoot $cluster.moref -Property Runtime.PowerState|?{$_.Runtime.PowerState -eq "poweredOn"}).count}))}}, @{n="cpu";e={(($_|%{((Get-View $cluster.ResourcePool|?{$_.Parent -eq $cluster.Moref}).Summary.QuickStats.OverallCpuUsage)/(Get-View -ViewType virtualmachine -SearchRoot $cluster.moref -Property Runtime.PowerState|?{$_.Runtime.PowerState -eq "poweredOn"}).count}))}}, @{n="vcpu";e={(Get-View -ViewType virtualmachine -SearchRoot $cluster.moref -Property Runtime.PowerState,Config.Hardware.NumCpu|?{$_.Runtime.PowerState -eq "poweredOn"}|Select @{n="vcpu";e={$_.Config.Hardware.NumCPU}}|Measure-Object -Average -Property vcpu).average}}|measure -average -property mem,cpu,vcpu|%{[math]::round($_.average,0)})|%{if (($_|measure -Sum).sum -ne ($cluster.ConfigurationEx.DasConfig.Option|?{$_.key -match "das.slotCpuInMhz|das.slotMemInMB"}|measure -Sum -Property value).sum -and ($_|measure -Sum).sum -gt "64") {$cluster.ReconfigureComputeResource((New-Object VMware.Vim.ClusterConfigSpecEx -property @{dasConfig=(New-Object VMware.Vim.ClusterDasConfigInfo -property @{option=@((New-Object VMware.Vim.OptionValue -property @{key="das.vmMemoryMinMB";value=$_[0].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.vmCpuMinMHz";value=$_[1].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.slotMemInMB";value=$_[0].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.slotCpuInMhz";value=$_[1].tostring()}))})}),$true)}}}

Joyeux Noël à tous !

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.

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.

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

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

vSphere Storage DRS attempts to avoid an out-of-space situation and therefore runs a load-balancing operation as soon as the datastore exceeds its space-utilization threshold. This operation can be outside of the normal load-balancing interval of every 8 hours.

La première phrase est aussi intéressante qu’imprécise. On y apprend que la réaction est immédiate mais aussi qu’elle dépend de vCenter. Et suite à une batterie de tests sur différents environnement (5.0 et 5.1), nous avons remarqué que la fréquence de rafraîchissement de cette information dans vCenter n’est malheureusement que d’une (1) fois toutes les 30 minutes au mieux. (on soupçonne un algorithme basé sur l’utilisation du datastore mais visiblement pas encore très efficace). Pour le vérifier, rien de tel qu’un petit oneliner de PowerCLI qui check la propriété info.timestamp des datastores :

Get-View -ViewType datastore -property info,name,summary|?{$_.summary.accessible}|select name,{$_.info.timestamp.ToLocalTime()}

On constate donc qu’un des pilier de SDRS repose sur une donnée dont la fiabilité peut malheureusement varier et dont la fraîcheur peut laisser à désirer même dans le cas des 30 minutes. En attendant que ça bouge coté VMware, voici un workaround (nettement moins dingue que celui d’une certaine kb), qui consiste à forcer le refresh rapide à votre convenance sans que la tache n’apparaisse dans le vCenter (merci le SDK). Dans notre exemple, refresh de tous les datastores dont la propriété info.timestamp serait “veille” de plus de 5 minutes :

Get-View -ViewType datastore -property info,summary|?{$_.summary.accessible}|?{($(get-date) - $_.info.timestamp.ToLocalTime()).TotalMinutes -gt 5}|%{$_.RefreshDatastore()}

La seconde phrase de la citation, c’est un RTFM politiquement correct pour ceux qui font encore l’amalgame entre les 8h d’intervales de l’I/O load balancing et le Space-Utilization Load Balancing.

Malheureusement la page de ce fling n’existe plus (même si l’outil est toujours disponible) mais nous avons trouvé son équivalent en PowerCLI au détour de 2 kb traitant de SIOC (ici et là). Il s’agit d’un module powershell qu’il suffit de charger avec la commande “Import-Module” et vous aurez ensuite accès à 2 nouvelles cmdlet (Get-PxCounterLevelMapping et Set-PxCounterLevelMapping) pour opérer les changements désirés.

A titre d’exemple, voici le niveau par défaut du compteur mem.active.average dont nous parlions plus haut :

Après exécution de la commande magique, le résultat (avant/après sur les graphiques) :

Get-PxCounterLevelMapping|?{$_.Name -eq "mem.active.average"}|Set-PxCounterLevelMapping -AggregateLevel 1

Ces modifications auront des conséquences sur la taille et peut être les performances de la base de données de votre vCenter mais ce sera toujours mieux qu’une augmentation “globale” qui entraînera la collecte de compteurs dont vous n’aurez peut être jamais besoin…