VMDK orphelins lockés

On a rencontré un comportement étrange avec notre zozor pendant une maintenance de datastore.

Vu qu’on a pas encore migré sur ESXi5, l’opération s’effectuait via le script de maintenance des datastore d’hypervisor.fr

Aucun problème de ce côté là, sauf qu’en vérifiant sur le datastore source, on a trouvé des résidus de vmdk qui n’avait pas migré.

Après vérification, ces vmdk n’étaient plus utilisés par les VM, les vmdk de la VM étant bien sur le datastore de destination.

Après double vérification (il vaut mieux dans ce cas là) dans le fichier de configuration .vmx et dans les pointeurs .vmdk, on décide de les supprimer directement.

Et là, erreur de suppression des fichiers :

On obtient le même résultat en essayant de les supprimer en se connectant directement en SSH sur les serveurs ESXi …

En regardant de plus près, on remarque des messages d’erreur au moment de la tentative de suppression dans le fichier /var/log/message :

Sur l’étape n°1, on voit bien la commande rm afin de supprimer un fichier -flat.vmdk (celui restant après la migration de datastore)

Sur l’étape n°2, on voit un message à propos du propriétaire, mais sans erreur

Sur l’étape n°3, on a une tentative de verrouillage du fichier avec ensuite le même message qu’en étape 2, mais avec un message d’erreur cette fois : is not free

A la lecture des erreurs, on comprend que le propriétaire noté dans le message de l’étape 2 ne libère pas le fichier que l’on tente de supprimer = pas glop …

Donc partant de là, on a plusieurs solutions. Si on se trouve dans la situation où on a peu de serveurs ESXi, on peut aller sur chaque serveur pour tenter d’exécuter la suppression afin d’espérer tomber sur le bon …

Sinon, en partant du principe qu’à partir de 2 on veut automatiser, on peut voir comment trouver directement le bon serveur.

Pour cela, on reprend l’ID du priopriétaire vu en étape 2 :

En s’appuyant sur la KB VMware 1008728, on voit que la dernière partie (en rouge) de cet ID correspond à l’adresse MAC du serveur ESXi.

Donc au final, on a une piste pour trouver l’esxisme récalcitrant :p

Maintenant pour trouver le serveur avec cette adresse MAC, on peut utiliser l’excellent script de rapport réseau d’hypervisor.fr (pas encore publié, ça ne saurait tardé) ou alors on peut utiliser ce petit OneLiner PowerCLI :

Get-VMHost | Get-VMHostNetworkAdapter | ?{$_.Mac -eq "3c:4a:92:de:1b:44"}

Et voilà, on a notre coupable, on peut directement se connecter dessus et supprimer les vmdk orphelins, et là ça marche :p = glop

10 comments

    • Si on veut afficher le host directement oui, mais de base on a déjà l’IP du network adapter pour s’y connecter en SSH
      Sachant qu’on peut aussi avoir le host en rajoutant juste | %{$_.vmhost} à la fin

Laisser un commentaire

Required fields are marked *.