storageRM level 1

Instruit par la kb Troubleshooting Storage I/O Control (1022091), nous nous sommes rendu compte qu’en fixant le log level à 1, le service storageRM crachait les informations de latency, qdepth et iops des datastores concernés dans les logs d’ESXi (et donc vers le(s) serveur(s) syslog) toutes les 4 secondes. Sur une grosse infra ça peut faire beaucoup mais ça offre de belles perspective de monitoring/troubleshooting :

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

Tags: , , , , ,

Purple Screen on Demand

MAJ 30/07/2014 : VMware vient de nous informer de la prise en compte du bug (PR 1286205) et que le correctif sera dispo Q4 2014 dans le patch 3 d’ESXi 5.5 :

Customer observed ESXi PSOD when polling IP-MIB. snmpd calling NetVsi_TcpipSysctlGet

Hormis la fameuse commande crashMe de vsish, il est généralement très difficile de reproduire un PSOD à la demande. Pourtant, nous avons trouvé un cas assez violent où l’utilisation de SNMPv3 via cacti fait crasher l’ESX de façon systématique et ce sur toutes les version depuis la 5.1 :

Evidemment, VMware est sur le coup. Pour info, nous avons utilisé le “walk through” de William pour la configuration.

Tags: , , ,

Happy Events

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: , , , , , , ,

WinBSOD in vmware.log

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: , , , , ,

Zero-G Storage vMotion

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: , , ,