Hypervisor.fr

11 ans après le fameux LazyMethodsEnabler tool de notre collègue vmdude, Broadcom VMware ajoute à vCenter Server 8.0 Update 3 la possibilité de réactiver la method RelocateVM_Task suite à un backup interrompu (ou autre mais c’est plus rare) par exemple :

Starting with vCenter Server 8.0 Update 3, in the vSphere Client under Virtual Machine > Configure > Disabled Methods you can remove restrictions on virtual machine operations such as migration.

Malheureusement, il semble qu’il n’y ait pas d’api public pour cette feature…

MAJ 11/01/2023 : William Lam vient de nous faire remarquer qu’il etait possible d’hardener vSphere 8 pour limiter cette “feature” ainsi que de limiter le shell aux user non root (dcui par exemple…)

By restricting ESXi Shell access for the vpxuser, you prevent attackers, which can also be insiders who have access to vCenter Server the ability to just change the ESXi root password without knowing the original password.

Après l’énorme succès de notre billet Administrators = root qui vous permet de reset le mot de passe root de vos ESX sans le connaître (si vous êtes admin du vCenter) grâce à Get-EsxCli, voici une nouvelle méthode utilisable depuis vSphere 6.7 U2 qui nécessite encore moins de droits :

Updates a local user account using the parameters defined in the HostLocalAccountManagerAccountSpecification data object type.

Required Privileges Host.Local.ManageUserGroups

(Get-View (Get-VMHost|Get-View).ConfigManager.AccountManager).UpdateUser($(New-Object VMware.Vim.HostAccountSpec -Property @{id="root";password="VMw4re!"}))

Attention, contrairement à la méthode Get-EsxCli, cette fois un petit event va vous trahir instantanément :

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

MAJ 30/07/2021 : Sur vSphere 7.0 U2 il est nécessaire de préciser l’UUID du cluster vSAN dans la commande, très probablement pour le fonctionnement d’HCI mesh :

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 :

Tags: PowerCLI, SVMotion, VSAN

Nous profitons de la coincidence d’un problème rencontré récemment chez un client et d’un excellent post de Niels Hagoort, le co-auteur du célèbrissime VMware vSphere 6.5 Host Resources Deep Dive, pour vous parler d’une fonctionnalité de vMotion apparu dans ESX 5.0 : Stun During Page Send (SDPS).

vSphere 5 introduces a new enhancement that ensures vMotion will not fail due to memory copy convergence issues. As noted in the “Architecture” section, transfer of the virtual machine’s memory contents during the vMotion process involves an iterative precopy procedure. In most cases, a precopy iteration should take less time to complete than the previous iteration. However, a pathological case where the virtual machine modifies memory faster than it can be transferred—due to workload characteristics or network infrastructure limitations—results in aborting vMotion in vSphere 4.1 and prior releases, because precopy fails to make forward progress. The enhancement in vSphere 5 slows down the virtual machine during such pathological cases and ensures that the memory modification rate is slower than the precopy transfer rate, thereby preventing any possible vMotion failures.

Vous l’aurez compris, si l’ESX source n’arrive pas à “dépiler” la vram suffisamment vite lors d’un vMotion, l’execution de la VM en question est ralentie jusqu’à ce qu’une convergence soit possible, dans la limite des timeout par défaut.

Cette fonctionnalité semble parfaite pour les monster VM qu’on a du mal à évacuer lors d’un passage en maintenance mode mais elle est aussi très “problématique” lorsque l’infrastructure réseau n’est pas ou plus adaptée. D’où le très discret “network infrastructure limitations” dans le descriptif.

En l’occurence, le client en question mène une campagne de “refresh” de son parc afin de remplacer des machines ayant largement dépassé leur date de péremption technique. Mais sans faire évoluer son réseau. Il se retrouve donc avec machine de 2To de RAM sur un réseau 1GbE.

Evidement, à mesure que des VM de plus en plus grosses sont provisionnées sur ces environnements, les fenêtres de maintenance sont de plus en plus grande mais surtout des ralentissements apparaissent lors des mise en maintenance ou simplement quand DRS déplace de VM :

018-12-13T16:32:29.378Z cpu18:74031)VMotion: 4943: 7811810961774337297 S: Not enough forward progress, enabling SDPS (Pages left to send: prev2 693298, prev 461605, cur 497489, network bandwidth ~28.619 MB/s, 94% t2d)
2018-12-13T16:38:32.426Z cpu188:72874)VMotion: 4943: 7811810962073701659 S: Not enough forward progress, enabling SDPS (Pages left to send: prev2 126959, prev 18467, cur 15909, network bandwidth ~60.158 MB/s, 103% t2d)

SDPS fait son boulot et il le fait bien alors évidement pour faire passer des VM de 256Go qui bossent fort dans du 1GbE ca pique… Donc la prochaine fois qu’on vous dit que la bande passante de vmotion peut être sacrifiée, vous saurez quoi répondre.

Evidement, il y a un (mauvais) plan B :

To work around this issue, the Stun During Page Send (SDPS) feature can be disabled on a per-host basis.
[...]
Change the value of Migrate.SdpsEnabled to 0.

Nous en profitons pour souligner un autre “petit” détail du texte au sujet du Page Tracing :

During the pre-copy phase, the vCPU’s, in use by the virtual machine, are briefly stunned to install the page tracers.

Tags: stun, troubleshooting, VMotion

Time flies. Ce qu’il y a de génial avec cette expression anglaise américaine c’est qu’on visualise tout de suite un avion de chasse passer à mach 5 avec votre todo list. En tout cas, cela résume bien le silence d’un an entre ce post et le précédent qui avait pour vocation, lui  aussi, de célébrer l’anniversaire de ce blog. Et de 11 !

On va en profiter pour remercier VMware, Veeam et toute la communauté pour les nominations de vExpert, vExpert vSAN et Veeam Vanguard de cette année, c’est toujours un honneur. 10 étoiles ca commence à faire

Nous avons même eu droit à une “honorable mention” dans un des vSpeaking Podcast de VMware pour SexiGraf. La classe

Et puisque c’est les 30 ans du World Wide Web ET de/du la/le Game Boy, nous nous sommes permis :

Tags: SexiGraf