Datastore UUID is required when a cluster UUID is specified

Get-VMHost|%{($_|get-esxcli).vsan.datastore.add($null, "vsanDatastore2", "11111111-1111-1111-1111-111111111111")}

En utilisant $null pour la propriété ClusterUUID, ca passe crème.

MAJ 18/05/2021 : On me signale dans l’oreillette que VMware supporterai officiellement cette méthode :

Engineering have advised that the procedure you are carrying out is applicable to your specific need and is considered supported from us

Tous les admin VMware le savent, après renommage d’une VM il convient de faire un petit Storage vMotion (aka d-motion pour les boomers) pour “propager” le nouveau nom aux fichiers de la VM en question. Et pour ceux qui l’ignorait encore, cette feature était un bug jusqu’à la version 5.0 U2 d’ESXi.

Évidement, cela nécessite d’avoir un 2eme datastore (idéalement avec des performances identiques et la bonne volumétrie) pour faire l’aller-retour de la VM (ou un Storage Pod) ce qui n’est pas souvent le cas sur un cluster vSAN pour des raisons évidentes.

Jusqu’à maintenant, les seules solutions étaient de … ne rien faire ou de connecter un datastore NFS ponctuellement pour faire le svmotion. Mais en cherchant à faire du HCI mesh en ligne de commande nous sommes tombé sur la solution (très discrètement documenté) : esxcli vsan datastore add pour créer un 2eme datastore sur le vmdk namespace.

Cette feature semble être apparu à partir de la version 6.7 U3 et est évidement accessible en PowerCLI également. Il suffit donc d’ajouter un “datastore” vSAN en précisant le nom et l’UUID de votre choix si vous le souhaitez. Il est nécessaire d’exécuter cette même commande sur tous les ESX du cluster avec le même nom et le même UUID.

Add a new datastore to the vSAN cluster. This operation is only allowed if vSAN is enabled on the host. In general, add should be done at cluster level. Across a vSAN cluster vSAN datastores should be in sync.

Voila ce que ça donne sur un cluster à 3 noeuds :

On peut donc maintenant faire notre svmotion aller-retour sans perte de performances.

Une fois l’operation terminé on peut utiliser la commande “remove” en precisant le nom et l’UUID du datastore ou carrément la commande “clear” :

Remove all but the default datastore from the vSAN cluster. This operation is only allowed if vSAN is enabled on the host. In general, add should be done at cluster level. Across a vSAN cluster vSAN datastores should be in sync.

Et aucun risque de se rater, si une vm est toujours présente sur le datastore, vous aurez droit à une belle erreur. Après avoir fait du ménage, ça passe crème :

<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

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.