Nous nous sommes donc rabattu sur les informations remonté via les API CIM :

Tant qu’on y était, on a fignolé le truc pour que ça ne remonte que les cluster non uniformes :

Get-BIOSMismatch

Si vous préférez un bon vieux one-liner qui vous affiche les version des BIOS de tous vos ESX, c’est par ici :

Get-View -ViewType HostSystem|?{$_.Runtime.ConnectionState -eq "connected"}|sort name|select name,@{n="BiosVersion";e={[Regex]::Match(($_.Runtime.HealthSystemRuntime.SystemHealthInfo.NumericSensorInfo|?{$_.name -match "bios" -and $_.SensorType -match "Software Components"}).name,"BIOS (.*) (20[0-9]{2,2}-[0-9]{2,2}-[0-9]{2,2})").groups[1].value}},@{n="ReleaseDate";e={[Regex]::Match(($_.Runtime.HealthSystemRuntime.SystemHealthInfo.NumericSensorInfo|?{$_.name -match "bios" -and $_.SensorType -match "Software Components"}).name,"BIOS (.*) (20[0-9]{2,2}-[0-9]{2,2}-[0-9]{2,2})").groups[2].value}}

PS : Il se peut que les infos visibles dans l’onglet “Hardware Status” du vSphere client ne correspondent pas à celle remonté en powershell, dans ce cas suivez les instructions de la kb 1037330, si cela ne suffit pas il faudra rebooter l’ESX.

Aussi effrayant que ce message puisse paraître lorsqu’on le croise dans la liste des events d’une VM, il n’en est pas moins inoffensif :

The guest OS tried to update the microcode [...] but VMware ESX does not allow microcode patches to be applied from within a virtual machine

C’est chez Microsoft qu’on trouvera une autre partie de l’explication :

The Microcode Update device is an interface between the operating system and an Intel processor based on the x86 architecture. This device provides the latest microcode updates for the processor if the BIOS does not already contain this information.

Et c’est chez HP enfin que l’on découvrira qu’une update de microcode est bien disponible pour nos HP ML110 G6 (machine idéale pour un petit lab) :

Updated to latest Intel microcode for the i3 series processor.