Hypervisor.fr

MAJ 08/01/2019 :  Pour les events vCenter, il faut prefixer avec “Vim.Event.” quand on joue avec l’EventManager.

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.

Tags: alarm, esx.problem, event, PowerCLI, powershell, syslog, VMkernel Observations, vob

Lors d’une petite séance de troubleshooting décontractée, nous avons été agréablement surpris de constater que lors d’un BSOD sous Windows, le texte affiché était redirigé dans le vmware.log de la VM. Ça évite l’OCR…

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.

Tags: BSOD, dump, log, PowerCLI, powershell, syslog

Notre expérience de Storage vMotion remonte à l’arrivée d’ESX 3.0.1 (aka VI3) où DMotion permettait de migrer à chaud de VMFS 2 à VMFS 3 :

Follow the Migrate Virtual Machine Wizard to select the ESX 3.0.1 host and VMFS3 datastore destination. The Wizard validates the destination and moves the configuration files of the virtual machine and virtual disks to the new VMFS3 datastore.

Depuis, nous avons étudié, testé, troubleshooté, et utilisé en production (de manière parfois intensive) cette fonctionnalité (qui a beaucoup évolué depuis 2007) devenue presque banale depuis SDRS.

C’est au moment où nous croyons tout savoir du mécanisme que nous prenons une grande claque d’humilité lors d’une migration de plusieurs centaines de VM et que nous nous apercevons pour la première fois qu’un svmotion d’un vmdk thin (ou Lazy Zeroed) génère 2 fois plus d’écritures que de lectures :

Nous n’avions jamais fait le rapprochement entre un svmotion et un sujet qui a longtemps fait polémique :

Because zeroing takes place at run-time for a thin disk, there can be some performance impact for write-intensive applications while writing data for the first time.

Et le pire c’est qu’il nous a fallu un temps infini à l’échelle de Google pour tomber sur un thread reddit où un VCDX explique tout d’une seule phrase :

It has to zero the block before writing the actual data.

Voila pourquoi sans VAAI (ou au moins la primitive WRITE_SAME) vos svmotion (thin ou lazy zeroed) prendrons 2 fois plus de temps car 2 fois plus de données transiterons vers le stockage (entre 2 VMFS avec le même blocksize).

A titre de démonstration, voici un visualEsxtop de 2 svmotion consécutifs de la même VM entre 2 datastore, avec et sans le setting DataMover.HardwareAcceleratedInit :

Ce n’est pas une défaillance de votre téléviseur, avec le zeroing offloadé à la baie c’est presque 2 fois plus rapide (ou 2 fois moins long si vous préférez…).

Ce comportement n’a évidement aucun rapport avec la “non-récupération” des zéros lors d’un svmotion… Bien qu’il semble etre possible de le forcer d’une manière non supportée !

Tags: SVMotion, thin provisioning, VAAI, zeroing

Les rares emplacements disque sont cruciaux sur les serveurs blade. Si, comme nous, vous envisagez de tester une solution de caching comme PernixData, vous aurez peut être besoin de dédier les 2 uniques emplacements (comme c’est souvent le cas) pour des SSD et de déplacer l’install d’ESXi ailleurs.

La solution la plus “connue”, même si c’est la moins pratique à notre avis, est le boot from SAN. En plus d’être longue à mettre en place, cette solution impose une dépendance forte au SAN qui peut poser de sérieux problèmes en cas d’incident sur la baie ou la fabric. A notre avis, le seul avantage de cette solution est la redondance liée au multipathing scsi.

La deuxième solution est évidemment le boot PXE, connue depuis qu’Autodeploy fait partie officiellement de l’arsenal de déploiement d’ESXi. Bien que pensé à la base pour du PXE, l’idée de dépendre du réseau pour booter ESXi ne fait pas encore l’unanimité. Il est possible de booter en PXE en repoussant un backup de la configuration (comme le faisait PXE Manager) mais la solution officielle de VMware est Autodeploy qui boot des ESXi vierges et repousse un host profile dessus. Pour peu que l’infrastructure DHCP/TFTP/vCenter soit hébergée sur les ESX managés par cette même infra, vous avez l’interdiction de couper le courant à vie.

La troisième solution est le boot from USB flash ou SD flash qui fut la solution “de lancement” d’ESX 3i en 2007 :

[...] Veso has thrown out hard disks in favor of embedding VMware’s new 32MB ESX 3i hypervisor in flash memory.

Cette solution à l’avantage d’être peut coûteuse, facile à mettre en place et indépendante. ESXi étant stateless, le nombre d’écritures sur la mémoire flash est très faible et réduit par conséquent les risques d’usure prématurée du support. C’est selon nous la solution la plus élégante et efficace, c’est donc celle ci que nous avons choisi pour libérer les 2 slots disques de nos blades.

Suite à de nombreux problèmes de contrôleurs, le cartes SD et micro SD ont pris le dessus sur les clefs USB en entreprise mais le principe reste identique donc nous testerons notre méthode de migration sur une clef kingston. Le principe est de restaurer un backup du bundle d’un ESXi visor-thin sur une nouvelle installation visor-usb.

visor-thin indicates an installable deployment
visor-usb indicates an embedded deployment
visor-pxe indicates a PXE deployment

Après avoir vérifié qu’aucune trace du “mode” d’installation n’était présente dans le fichier esx.conf du bundle, nous avons tout simplement utilisé vmplayer pour tester la migration sur un ESXi nested. Et pour ceux qui se demande comment nous avons booté sur une clef usb avec vmplayer, allez faire un tour chez Plop :

Comme vous pouvez le constater, la migration vers une clef usb se déroule sans accrocs et si VMware vous dit que ce n’est pas une méthode supportée, demandez leur de vous prouver que vous l’avez utilisé…

Tags: PXE, thin, usb, visor, vmvisor

Pour une raison aussi néfaste que mystérieuse et que même notre cher confrère vmdude n’a pu expliquer, nous avons “perdu” un VUM (VMware Update Manager). Plus rien, nada, que dalle, même pas de backup. Evidemment, nous ne nous en sommes rendu compte que quelques jours avant une grosse campagne de patch. Y voyant là un signe divin, nous avons pris la décision de ne pas réinstaller le composant et d’essayer de patcher cet environnement, sans VUM mais de façon totalement automatisé (~90 ESXi quand même). Et figurez vous que ça s’est très bien passé !

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

Tags: esxcli, Image Builder, PowerCLI, VMware Update Manager