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 :

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.

esxcli software vib remove -n vib1 -n vib2 -n vib3

Et pour ceux qui veulent du lourd sur esxcli, jetez un un oeil au Quick Tutorial de Steve Jin.

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}}

The upgrade contains conflicting VIBs. Remove the conflicting VIBs or use Image Builder to create a custom upgrade ISO image that contains the newer versions of the conflicting VIBs, and try to upgrade again.

Il nous a fallu fouiller au fin fond des logs d’ESXi pour identifier les VIB en question :

Si vous lisez attentivement les release notes, vous savez déjà que depuis ESXi 5.1 il est possible d’upgrader avec la commande esxcli directement depuis le vib depot de VMware (William Lam a d’ailleurs écrit un post à ce sujet pour détailler le process) :

You can upgrade and apply patches to ESXi 5.0.x hosts by using the esxcli command-line utility for ESXi to upgrade to ESXi 5.1 from a download depot on vmware.com or from a downloaded ZIP file of a depot that is prepared by a VMware partner.

Nous avons donc tenté la même opération en ssh et l’erreur retournée par ESXCLI est nettement plus précise que celle de VUM :

Au passage, on attend toujours un plugin VUM digne de ce nom pour le webclient…

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

Et bien nous en a pris car cet indice nous a permis de découvrir (1 an plus tard…) que la cmdlet Get-EsxCli de PowerCLI 5+ ne nécessite pas de connections direct aux ESX (mais uniquement avec un vCenter 5+ comme en témoigne le changelog) :

Added vCenter Server support for Get-EsxCli. (requires vCenter Server 5.0 or later)

Vous pouvez donc facilement vérifier l’état du paramètre UNMAP…

Get-VMHost|select Name, @{n="UNMAP";e={$(($_|Get-EsxCli).system.settings.advanced.list("/VMFS3/EnableBlockDelete")).IntValue}}

… Ou afficher la liste des claimrule (pratique pour masquer un path)…

Get-VMHost|%{" ";write-host -background white -foreground red $_.Name;($_|Get-EsxCli).storage.core.claimrule.list()|ft *}

… Ou encore modifier le paramètre “IOOperationLimit” des LUN configurées en roundrobin :

ForEach ($VMHost in Get-VMHost){" ";write-host -background white -foreground red $VMHost.Name;($VMHost|Get-EsxCli).storage.nmp.device.list()|?{$_.PathSelectionPolicy -match "VMW_PSP_RR"}|%{($VMHost|Get-EsxCli).storage.nmp.psp.roundrobin.deviceconfig.get($_.device)}}

ForEach ($VMHost in Get-VMHost){" ";write-host -background white -foreground red $VMHost.Name;($VMHost|Get-EsxCli).storage.nmp.device.list()|?{$_.PathSelectionPolicy -match "VMW_PSP_RR"}|%{($VMHost|Get-EsxCli).storage.nmp.psp.roundrobin.deviceconfig.get($_.device)}|?{$_.IOOperationLimit -ne 1 -and $_.LimitType -ne "iops"}|%{($VMHost|Get-EsxCli).storage.nmp.psp.roundrobin.deviceconfig.set($null,$_.device,"1","iops",$null)}}

Moralité : RTFChangelog