visor-thin & vsantraces

NiTRo — Sat, 10 Oct 2015 21:13:14 +0000

Sur un cluster VSAN composé d’ESXi 6.0 bootant sur des cartes SD, nous avons récemment été confronté à ces erreurs :

<14>2015-09-04T22:03:39.616Z esx.vmware.com vobd: [VisorfsCorrelator] 2274728093499us: [esx.problem.visorfs.ramdisk.full] The ramdisk ‘vsantraces’ is full. As a result, the file /vsantraces/vsantraces–2015-09-04T21h31m52s079.gz could not be written.

[...]

<14>2015-09-04T21:00:53.492Z esx.vmware.com vobd: [VisorfsCorrelator] 2269273677949us: [vob.visorfs.ramdisk.full] Cannot extend visorfs file /vsantraces/vsantraces–2015-09-04T19h34m10s776.gz because its ramdisk (vsantraces) is full.

La cause de ce problème est assez simple : booter ESXi via USB ou SD card = visor-thin = partition /scratch dans la RAM. Et quand vous n’avez pas de scratch persistante, la partition /vsantraces est configurée par défaut à 300MB comme vous pouvez le constater dans /etc/vmware/vsan/vsantraced.conf :

# Ramdisk size in MB (do not increase over 300MB without a matching increase
# to coredump size).
#VSANTRACED_RAMDISK_SIZE=300

Or comme l’explique Cormac dans son post VSAN considerations when booting from USB/SD :

VSAN traces require ~500MB of disk space.

Aprés quelques échanges avec le support VMware, il nous a été confirmé qu’il était possible et supporté de changer la taille de cette partition en modifiant vsantraced.conf, ce que nous avons pu tester et valider en l’augmentant à 500MB pour mettre fin aux erreurs :

GSS nous a cependant mis en garde :

Just be aware that if you do so, you also must increase coredump size by the same value.

Il nous a également fallu rediriger le workingdir de la commande vm-support (lorsque nous en avons besoin) pour éviter l’erreur suivante :

IOError: [Errno 28] No space left on device

Une autre info interessante sur le sujet : Handling VSAN trace files when ESXi boots from a flash device

VisorFS : la clef de voûte d’ESXi

NiTRo — Wed, 04 Apr 2012 22:28:30 +0000

A l’occasion du lancement du VMware Technical Journal, un document traitant de VisorFS a été publié discrètement. Signé Olivier Cremel (si si vous connaissez…), ce document “VisorFS: A Special-purpose File System for Efficient Handling of System Images” décrit l’historique ainsi que le fonctionnement de VisorFS, l’ingénieux “ramfs” stateless d’ESXi.

On y découvre notamment le secret du format vmtar qui permet de d’optimiser le contenu des tardisks pour que TPS soit le plus efficace possible sur la zone mémoire utilisé par l’hyperviseur.

When the system image is built, the system tar archives that become the tardisks are constructed as usual. These tardisks are processed by the vmtar tool, which reorders the content to page align the binaries and add the number of pages needing fix-ups to their metadata header.

On retient également le principe de base qui fait d’ESXi un hyperviseur aussi léger qu’efficace :

Complexity is pushed to offline tools so that simplicity can be kept in the running system.

Ceux qui l’auraient raté peuvent également consulter la session TA8245 du VMworld 2010 “ESXi Internals: Better Understanding for Better Management and Troubleshooting” pendant laquelle VisorFS est également abordé.

Hypervisor.fr » VisorFS

visor-thin & vsantraces

VisorFS : la clef de voûte d’ESXi