<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

Et on a bien fait, parce qu’on a même réussi à créer une partition VMFS sur une clef de boot ESXi 6.0 :

Pour que ça ait de la gueule, nous avons utilisé ce qui se fait de mieux en la matière : une clef USB 3.0 MX-ES SLC NAND Ultimate Endurance capable d’encaisser 180Mo/s en écriture.

La procédure est la même que pour créer un datastore en cli avec partedUtil et vmkfstools :

Et pour le fun, on a aussi essayer sur une clef Kingston/VMware ESXi “special” :

Nous vous laissons imaginer les possibilités que cette nouvelle “unsupported“ feature pendant que nous préparons un post qui n’attendait que ça pour voir le jour…

]]> http://www.hypervisor.fr/?feed=rss2&p=5461 3 http://www.hypervisor.fr/?p=5149 http://www.hypervisor.fr/?p=5149#comments Tue, 03 Jun 2014 06:42:54 +0000 NiTRo http://www.hypervisor.fr/?p=5149 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é…