Hypervisor.fr

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

Tags: scratch, SD card, stateless, support, usb, VisorFS, VSAN

Pour les 7 ans d’Hypervisor.fr (si,si, c’est aujourd’hui) nous vous offrons un petit onliner pour mettre en maintenance un des nœuds de votre cluster VSAN en PowerCLI, dans la lignée de nos précédents posts “vSphere sans le webclient”.

Nous étions parti pour utiliser le script disponible sur VSANTeam.info mais il est malheureusement faux car il n’inclus pas l’objet VsanHostDecommissionModeObjectAction et donc le mode “ensureObjectAccessibility” est utilisé par défaut. Donc pour pouvoir utiliser le mode “evacuateAllData” ou “noAction” c’est comme ça qu’on fait :

Get-View -ViewType HostSystem -Filter @{"Name" = "esx.vmware.com" }|?{!$_.Runtime.InMaintenanceMode}|%{$_.EnterMaintenanceMode(0, $false, (new-object VMware.Vim.HostMaintenanceSpec -Property @{vsanMode=(new-object VMware.Vim.VsanHostDecommissionMode -Property @{objectAction=[VMware.Vim.VsanHostDecommissionModeObjectAction]::NoAction})}))}

Sinon vous pouvez aussi le faire avec Get-EsxCli en vous inspirant du post de William.

Tags: esxcli, Get-EsxCli, PowerCLI, powershell, VSAN

Pour éviter de perdre encore 1/4 d’heure dessus la prochaine fois, voici comment désinstaller plusieurs vib en une seule commande (contrairement aux vilaines KB VMware) :

esxcli software vib remove -n vib1 -n vib2 -n vib3

Et pour ceux qui veulent du lourd sur esxcli, jetez un un oeil au Quick Tutorial de Steve Jin.

Tags: esxcli, ssh

A chaque nouvelle version de vSphere, c’est toujours un plaisir de fouiller dans le SDK. La cuvée 2015 offre son lot de surprises comme le GuestWindowsRegistryManager qui permet de gérer la registry de Windows directement via les API VIX, des traces du projet VMFork (aka Linked Clones ++) qu’on attend avec impatience ou encore la possibilité d’envoyer une non-maskable interrupt (aka NMI) à une VM pour un troubleshooting velu.

Historiquement, il était un peu complexe de générer ce genre d’interruption comme le détail William mais avec cette nouvelle API cela devient un jeu d’enfant en PowerCLI :

(Get-VM toto|Get-View).SendNMI()

Malheureusement, connecté au vCenter, on se mange une jolie erreur :

Exception calling “SendNMI” with “0″ argument(s): “The requested operation is not implemented by the server.”

Connecté en direct sur un ESX ça se passe nettement mieux :

En prime, on droit au nouvel événement VmGuestOSCrashedEvent :

<166>NoneZ visor04.lab.schitz.org Hostd: 2015-06-04T22:21:45.933Z info hostd[6DE83B70] [Originator@6876 sub=Vimsvc.ha-eventmgr] Event 894 : Win10 on visor04.lab.schitz.org: Guest operating system has crashed.

Tags: API, NMI, PowerCLI, powershell, SDK

Il y a bientôt 3 ans, nous testions le Backplane Icy Dock ToughArmor Full Metal 6 permettant de faire tenir 6 HDD/SSD 2.5″ de 7 à 9 mm dans un emplacement 5.25″ ce qui était déjà une performance honorable à l’époque. Aujourd’hui, nous testons son improbable grand frère le Full Metal 8 qui permet, comme vous l’aurez certainement deviné, de faire tenir 8 HDD/SSD 2.5″ de 7 mm dans un seul emplacement 5.25″ ! Contrairement à son petit frère, le Full Metal 8 n’a toujours pas de concurrent à ce jour.

Pour ce test nous nous sommes procuré des SSD Intel 530 afin de vérifier que le design du PCB ne représente pas un frein aux performances et la faible latence des puces NAND. Nous nous sommes également amusé à démonter le backplane pour étudier la construction générale du produit.

Contrairement à ce que nous avions imaginé, vous pouvez constater sur les photos qu’il reste encore un peu de place entre les SSD ce qui peut laisser envisager une version 10 slots (SSD only par contre) ! Compte tenu de l’usage cible nous avons retiré les 2 ventilateurs 40 mm ce qui facilite le câblage et nous précisons au passage qu’une seule prise d’alimentation peut suffire même si nous craignons que ce ne soit pas idéal pour le PCB. Comme pour les autres produit de la gamme, la finition est très bonne et le coté “full metal” offre clairement une impression semblable aux produits des gammes professionnels chez les grands constructeurs.

Pour le benchmark, nous avons installé le rack dans un HP ML 110 G6 équipé d’un Xeon  x3430 et d’une carte LSI 9240-8i. C’est sur FreeNAS 9.3 que nous avons lancé iozone afin d’obtenir un résultat un peu plus réaliste qu’avec un simple dd :

180 µs de latence à 2.5 Go/s c’est quand même pas mal du tout

Durant le test de “reread”, nous avons pris une capture d’iostat pour avoir une idée de l’état des SSD et on remarque qu’ils ne sont même pas au maximum de leur capacité à en croire le %b :

Et pour le fun, on s’est dit que ce serait la classe dans mettre ça dans un N40L même si le processeur est loin de pouvoir suivre :

Tags: EZ Compact, FreeNAS, Icy Dock, IOPS