Outil lazyMethodEnabler

Pour faire suite au billet de hypervisor.fr Storage vMotion : the method is disabled, on est aujourd’hui dans une nouvelle mission chez un client qui avait trop énormément de machines virtuelles avec les méthodes désactivées (et augmentant quotidiennement au fil des sauvegardes…) :

Sans blâmer l’outil pérave de sauvegarde existant jaune et noir (quoique c’est assez tentant…), le nombre de machines virtuelles touchées étaient trop important pour qu’aucun des workaround de la KB VMware ne soit acceptable. Pour rappel, les workaround proposés sont :

  • unregister/register de la VM (donc là, on oublie les statistiques, custom fields et historique à cause du changement de MoRef > NoWay)
  • Purge manuel de la base de données du vCenter (opération nécessitant un arrêt du service vCenter donc on oublie en production si le problème est récurrent > NoWay)
  • Relancer un job de backup (c’est viable à petite échelle, mais dans notre cas, le nombre de VM ayant ce problème augmentait d’environ 60 tous les jours… > NoWay)

En attendant la migration vers une vraie solution de sauvegarde (le passage vers Veeam Backup se faisant désiré), il fallait quand même trouver une solution plus propre :p

Partant du principe qu’un backup de la VM a des chances de remettre ce paramètre comme il faut, on s’est demandé ce qui provoquait l’erreur. La KB explique :

When a VM-level backup begins, the backup system informs vCenter to disable Storage vMotion for that VM to ensure that the backups can complete successfully

Le passage intéressant est « the backup system informs vCenter« . Après quelques recherches, il s’avère que cela passe par des appels au Virtual Disk Development Kit (VDDK). Histoire de comprendre plus en détails les mécanismes de sauvegarde et de manipulation des fichiers VMDK par les outils tiers, on a commencé à lire le Virtual Disk Programming Guide afin de trouver l’explication.

Outre le côté extrêmement intéressant du SDK (on vous invite d’ailleurs à jeter un coup d’oeil histoire de voir sa richesse), la partie qui nous intéresse se trouve dans Advanced Transport APIs dans l’article Prepare For Access and End Access.

Voici l’extrait qui répond à la question et à notre problème :

The VixDiskLib_PrepareForAccess() function notifies a vCenter-managed host that a virtual machine’s disks are being opened, probably for backup, so the host should postpone virtual machine operations that might interfere with virtual disk access. Call this function before creating a snapshot on a virtual machine. Internally, this function disables the vSphere API method RelocateVM_Task.


The VixDiskLib_EndAccess() function notifies the host that a virtual machine’s disks have been closed, so operations that rely on the virtual disks to be closed, such as vMotion, can now be allowed. Call this function after closing all the virtual disks, and after deleting the virtual machine snapshot. Normally this function is called after previously calling VixDiskLib_PrepareForAccess, but you can call it to clean up after a crash. Internally, this function re-enables the vSphere API method RelocateVM_Task.

La solution se trouve donc au niveau des appels VixDiskLib_PrepareForAccess() et VixDiskLib_EndAccess() qui s’occupent de notifier au serveur vCenter de gérer la partie Method Disabled (permettant ainsi d’éviter un Storage vMotion pendant un backup par exemple).

Par rapport à notre problème, le fait de relancer un job de backup effectue le traitement PrepareForAccess>Backup>EndAccess et donc est bien censé corriger le soucis via l’appel EndAccess(). Partant de ce principe, on s’est donc dit qu’une solution viable à grande échelle (outre changer d’outil de sauvegarde ^^) serait d’avoir un programme qui ne fait que le traitement PrepareForAccess>EndAccess (et donc qui serait beaucoup plus rapide qu’un backup complet de chaque VM).

VDDK étant fait pour les langages C/C++, il a fallu que l’on ressorte de vieux souvenirs sur le développement en C++ (on est effectivement très loin du C# ou PowerShell…). On a donc développer un programme qui va permettre de « réactiver » les méthodes disabled mal enlevées par un outil de m..

Le tool s’utilise pour l’instant en standalone, donc il faut passer le MoRef de la VM en argument (ou je sais c’est moyen, mais bon, c’est du C++ !). Il prend les arguments suivants :

lazyMethodEnabler.exe -host 10.69.69.69 -user "vmdude" -password "esxi4ever" -vm "moid=vm-69"
  • -host <host IP> : IP du serveur vCenter
  • -user <vcenter Username> : nom d’utilisateur pour se connecter au vCenter
  • -password <vcenter Password> : mot de passe de l’utilisateur
  • -vm « moid=moref » : MoRef de la machine virtuelle

Il existe un argument optionnel supplémentaire -disableMethods qui permet de forcer la désactivation de la méthode RelocateVM_Task. Au final, cette opération n’effectue que l’appel VixDiskLib_PrepareForAccess() (c’est à dire sans terminer par un appel à VixDiskLib_EndAccess() ) et permettra de « simuler » une VM avec le problème.

Attention, l’argument -disableMethods n’est à utiliser qu’en cas de debug !

Les sources Visual Studio 2012 (Visual C++) sont disponibles ici :

lazyMethodsEnabler.zip : exécutable uniquement

lazyMethodsEnabler-VDDK.zip : exécutable + librairies VDDK5.0

lazyMethodsEnabler-Sources.zip : Sources Visual C++

Comme l’outil se base sur des appels VDDK, il faut que le SDK soit installé sur le PC qui lancera lazyMethodEnabler. Les tests ont été réalisé avec VDDK 5.0 (disponible ici : http://www.vmware.com/download/download.do?downloadGroup=VDDK50U2) sur un serveur Windows 2008 R2.

PS: Désolé Samir d’avoir mis aussi longtemps pour publier ce billet :p Mea Culpa !

6 comments

  1. Bravo !

    Tu as enfin trouver le temps!!!

    En tous cas c’est une très belle solution, bien mieux que les WorkAround VMware!!!

    Bon courage à toi et ton acolyte 😉

  2. Super tool, ayant déjà subit ce type de désagrément suite à des restore, enfin un vrai workaround !!
    Et pour les jaune et noir +1, à démonter, à repeindre, ou pas 🙂

    • Content que l’outil ait rendu service !
      C’est effectivement assez étonnant de continuer a voir des workaround vraiment décalé avec la réalité de la production…
      Dans un prochain billet, je mettrais un script PowerCLI permettant de l’exécuter sur toute une plateforme (et non plus sur une seule VM).

  3. J’ai déjà été confronté à ce problème sur des machines de production. A la lecture du kb, j’ai failli pleurer.

    Avant la sortie de votre programme, j’ai trouvé une solution alternative (moins propre) qui consiste à supprimer le flag directement dans la bdd du vCenter. Ça fonctionne.

    Si vous êtes intéressé, je peux vous retrouver le kb de Symantec il me semble.

    • Effectivement c’est possible de le faire directement en BDD (il me semble que la KB en parle), mais pour que ce soit pris en compte, il faut redémarrer le service vCenter.

Répondre à Samir Annuler la réponse

Required fields are marked *.