PunchZero online

Depuis l’apparition du thin provisioning, la question de la récupération de l’espace disque libéré après allocation refait surface régulièrement.

Historiquement, il suffisait de “zeroer” l’espace libre inGuest et faire un storage vmotion vers n’importe quel autre datastore pour récupérer l’espace “zeroé” grâce au datamover fsdm qui zappe les zéros. Malheureusement, depuis l’apparition du datamover fs3dm dans vSphere 4.0 cet avantage a disparu comme l’explique Duncan dans un vieux post de 2011.

A cette époque, il était courant d’avoir des datastores configurés avec des blocksize différents ce qui permettait de contourner le problème facilement. Aujourd’hui, VMFS 5 a changé cette approche avec le blocksize unifié à 1M.

Pour tricker comme avant et forcer fsdm à faire le boulot il faut une rupture technologique VMFS <> NFS ou jouer avec un paramètre caché de vsish comme l’indique William Lam dans son commentaire :

Whether VMFS should handle data movement requests by leveraging FS3DM

Et depuis le temps que nous voulions le tester, nous sommes enfin tomber sur une VM avec ~60Go à récupérer dans un environnement VMFS5 only:

Un coup de sdelete -z plus tard, on change le paramètre /config/VMFS3/intOpts/EnableDataMovement dans vsish et on lance un storage vmotion.

Au passage on remarque bien la phase de lecture sans écriture pendant le svmotion :

Après la migration (qui vous permettra aussi de renommer officiellement les fichiers de votre VM), la VM a maigri comme il faut :

Pour ceux qui voudrait tout simplement le faire offline, il y a l’option –punchzero de vmkfstools.

Tags: , , ,

Large Pages on Demand

Comme nous vous l’avions promis, voici un retour d’expérience sur l’implémentation du paramètre LPageAlwaysTryForNPT à “0″ qui force ESX à n’allouer une Large Page que lorsque le GuestOS d’une VM le lui demande explicitement et qui permet de bénéficier de TPS sans attendre que l’ESX n’ait à les “casser” en cas de contention.

In the cases where host memory is overcommitted, ESX may have to swap out pages. Since ESX will not swap out large pages, during host swapping, a large page will be broken into small pages.

Afin d’avoir une meilleure visibilité sur ce qui change au moment où nous avons activé le paramètre et lancé une vague de vmotion au sein du cluster pour l’appliquer, nous avons utilisé les mêmes compteurs que le “dashboard” Guest Memory (aka ResourcePoolQuickStats) pour en faire un rrd sous cacti (avec les même couleurs) :

Un gain immédiat de 20% de RAM sans consommation CPU supplémentaire ni augmentation manifeste de latence (dans notre cas) :

Et pour ceux qui se posent la question, dans ce cluster cumulant 1.5To de RAM attribuée à des VM Windows 2008 R2 et RHEL 6 x64, seulement 40Go de Large Pages sont allouées en moyenne.

Moralité, TPS c’est bon, mangez-en !

Tags: , , , , ,

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

MAJ 19/10/2014 : Le patch ESXi550-201410001 règle le problème sans un mot dans les release notes ni les fixed PRs

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