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.

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.

Nous savions que c’était techniquement envisageable compte tenu du fait qu’un patch pour ESXi se résume à la copie d’une nouvelle build dans la “bootbank” après avoir copier la build courante dans la “altbootbank“ la “bootbank” inactive. Compte tenu du fait qu’ESXi est un OS stateless, le fait d’écraser la “bootbank” et la “altbootbank” pendant le fonctionnement ne pose pas de problème. Malgré tout, il nous a fallu chercher un peu pour trouver le bon paramètre à passer à “esxupdate” pour forcer la mise à jour (qui nécessite le “maintenance mode” par défaut) avec des vm en fonctionnement.

Voici un petit oneliner qui vous permettra de reproduire cet exploit (oubliez le support vmware naturellement) :

(get-view (get-vmhost vsp41esx01*|get-view).configmanager.PatchManager).InstallHostPatchV2($null, "http://www.hypervisor.fr/img/ESXi410-201206001.zip", $null, ((new-object Vmware.Vim.HostPatchManagerPatchManagerOperationSpec -Property @{cmdOption = "--maintenancemode"})))

Comme le détail le SDK, il est possible de choisir entre 3 sources de patch : metaUrls, bundleUrls ou vibUrls, tout dépendra du format du patch. Concernant le “maintenance mode”, toute la magie réside dans le paramètre ”–maintenancemode” qui fait parti des “hidden options” d’esxupdate (malheureusement pas toutes commentées) :

–HA
–vib-view
–maintenancemode
–force
–test ‘Test update transaction only–do not change sytem.’
–all ‘Display all bulletins. Default is to display only the applicable updates.’
–long ‘Produce more detailed response in query or info output.’
–noobsoletes ‘Ignore obsoletions during update. (Enables downgrading to older bundles.)’
–reinstall ‘Re-install a bundle that is already installed.’
–nodeps
–nosigcheck
–nocache
–olderversion
–cachesize
–cleancache
–compliant

A l’opposé, il est aussi possible de désinstaller un patch (à chaud toujours), ce qui est malheureusement impossible à faire avec VUM :

(get-view (get-vmhost vsp41esx02*|get-view).configmanager.PatchManager).UninstallHostPatch("ESXi410-201101223-UG",((new-object Vmware.Vim.HostPatchManagerPatchManagerOperationSpec -Property @{cmdOption = "--maintenancemode"})))