Accueil > KB, VMware > impossible de démarrer une VM, fichier verrouillé
Fév/1150

Voici un problème que j’ai rencontré récemment et ca résolution: impossible de démarrer une VM car un fichier non-spécifié est verrouillé, on a le message d’erreur suivant « Unable to access file <unspecified filename> since it is locked« .

Plutôt que de redémarrer simplement les serveurs ESX, il vaut mieux identifier ce verrou. Donc en cherchant dans la KB VMware, on trouve ce premier article KB10051, pour trouver quel ESX verrouille la VM. Pour cela suivre le mode opératoire suivant:

  • En ligne de commande dans le service console, aller dans le répertoire de la VM
  • Ouvrir le fichier vmware.log, à la fin du fichier rechercher une erreur indiquant le nom du fichier
  • On peut aussi identifier le fichier avec le commande « touch *« 
  • Maintenant que vous avez le nom du fichier verrouillé, taper la commande vmkfstools -D /vmfs/volumes/<LUN>/<VMDIR>/<LOCKEDFILE.xxx>
  • Ensuite regarder quel ESX verrouille le fichier avec la commande tail /var/log/vmkernel (pour ESX) ou tail /var/log/vmkernel (pour ESXi)
  • Vous trouverez comme ci-dessous ou la 4ième partie de « owner » contient l’adresse MAC de l’ESX qui verrouille le fichier:
  • Feb  2 10:04:01 servesxXX vmkernel: 45:22:36:01.071 cpu4:4200)FS3: 142: <START SrvXXXXXXXXX-flat.vmdk>
    Feb  2 10:04:01 servesxXX vmkernel: 45:22:36:01.071 cpu4:4200)Lock [type 10c00001 offset 39131136 v 25300, hb offset 3334144
    Feb  2 10:04:01 servesxXX vmkernel: gen 1363, mode 2, owner 00000000-00000000-0000-000000000000 mtime 14898363]
    Feb  2 10:04:01 servesxXX vmkernel: 45:22:36:01.071 cpu4:4200)Addr <4, 33, 155>, gen 1209, links 1, type reg, flags 0x0, uid 0, gid 0, mode 600
    Feb  2 10:04:01 servesxXX vmkernel: 45:22:36:01.071 cpu4:4200)len 21474836480, nb 2560 tbz 156, cow 0, zla 3, bs 8388608
    Feb  2 10:04:01 servesxXX vmkernel: 45:22:36:01.071 cpu4:4200)FS3: 144: <END SrvXXXXXXXXX-flat.vmdk>

Malheureusement dans mon cas, l’adresse MAC est nulle, je ne sais donc pas qui verrouille mon fichier. Toujours dans la KB VMware, il y a aussi cet article KB1006401, quand un snapshot verrouille un vDisque sans avoir d’identifiant pour l’ESX. Pour cela suivre le mode opératoire suivant:

  • Pour savoir quel process verrouille le fichier taper la commande: lsof /vmfs/volumes/<LUN>/<VMDIR>/<LOCKEDFILE.xxx>
  • Le résultat doit ressembler à ca et contenir le PID du process:
  • COMMAND     PID USER   FD   TYPE DEVICE        SIZE   NODE NAME
    activeblo 10532 root    5r   REG   0,18 21474836480 116262 /vmfs/volumes/4c066dba-d1821d9e-f4f0-001a64265d96/SrvXXXX/SrvXXXX-flat.vmdk

  • Regarder maintenant quel process se cache derrière ce PID qui verrouille le fichier, avec la commande ps -ef | grep <PID>
  • Dans mon cas, j’obtient ca:
  • root     10532 20937 92 Jan30 pts/4    2-11:25:45 /tmp/.vzbin/26a8426e-72ac-4f9e-b040-d176d28bbb68/activeblock -i /vmfs/volumes/LUNXXX/SrvXXXX/SrvXXXX.vmdk -o /vmfs/volumes/LUNXXX/SrvXXXX/SrvXXXX.vmdk-abbt.vztemp -b 256

  • Enfin, il ne reste plus qu’a tuer ce process avec un kill <PID>

Dans mon cas, le process incriminer était lié à un logiciel de réplication. Le problème c’est qu’il n’avait pas libérer le Snapshot mais que les SnapShots n’était pas visible dans le SnapShot Manager du vSphere Client. Donc troisième article: KB1002310, pour supprimer à la main des Snapshots non-visible dans le Snapshot Manager. Pour cela suivre le mode opératoire suivant:

  • En ligne de commande, vérifier que la VM ne voit pas ces SnapShots taper la commande vmware-cmd /vmfs/volumes/LUNXX/SrvXXXX/SrvXXXX.vmx hassnapshot qui doit vous retourner « hassnapshot() = 0 » car elle ne pense pas avoir de SnapShot alors qu’ils sont bien présent.
  • Créer un nouveau SnapShot (sans le quiesce de la mémoire) avec la commande vmware-cmd /vmfs/volumes/LUNXX/SrvXXXX/SrvXXXX.vmx createsnapshot « test » «  » 0 0
  • Puis supprimer tous les SnapShots avec la commande vmware-cmd /vmfs/volumes/LUNXX/SrvXXXX/SrvXXXX.vmx removesnapshots ce qui nettoyera les anciens SnapShots non-vu.

Maintenant tout est revenue à la normale, la VM peut démarrer, la réplication fonctionne et les SnapShots sont cohérents.

  1. Pas encore de commentaire
  1. Pas encore de trackbacks