Los errores típicos en este caso son: Unable to access a file since it is locked, Unable to access a file ARCHIVO since it is locked, Unable to access Virtual machine configuration, etc.
Ejemplo:
~ # rm -f /vmfs/volumes/data01/vm_foo/maquina_virtual_foo.vmdk rm: can't remove '/vmfs/volumes/data01/vm_foo/maquina_virtual_foo.vmdk': Device or resource busy
Lo primero que se suele realizar es intentar migrar y arrancar la máquina virtual a otro host ESXi para ver si así el problema queda solucionado. Si esto no lo soluciona, lo mejor es que accedamos por ESXi Shell o SSH al servidor ESXi de la infraestructura en que está ubicada la máquina virtual y encontremos el origen del bloqueo.
El comando «vmkfstools -D » seguido del archivo bloqueado nos facilitará información muy relevante sobre el origen del bloqueo, ejemplo:
~ # vmkfstools -D /vmfs/volumes/data01/vm_foo/maquina_virtual_foo.vmdk Lock [type 10c00001 offset 46301184 v 205, hb offset 4018176 gen 15, mode 2, owner 00000000-00000000-0000-000000000000 mtime 47187 num 1 gblnum 0 gblgen 0 gblbrk 0] RO Owner[0] HB Offset 3727360 54476ac6-6e835e56-eaaf-0020ea5cc1f2 Addr <4, 92, 16>, gen 22, links 1, type reg, flags 0, uid 0, gid 0, mode 600 len 64424509440, nb 61440 tbz 0, cow 0, newSinceEpoch 61440, zla 3, bs 1048576
Al parecer, la salida estándar del comando es distinta en versiones anteriores a 4.1 que la que os he mostrado, pero es similar y se entiende su interpretación con esta explicación.
Lo interesante de este comando es que nos va a facilitar la dirección MAC de la interfaz de red del servidor que está bloqueando el archivo. La MAC puede aparecer en la primera línea o en la tercera. Si sale en la segunda línea el bloqueo será de sólo lectura (RO). En el ejemplo anterior, en la primera línea no aparece la MAC:
gen 15, mode 2, owner 00000000-00000000-0000-000000000000 mtime 47187
Pero sí en la segunda, la MAC la extraemos del último campo:
RO Owner[0] HB Offset 3727360 54476ac6-6e835e56-eaaf-0020ea5cc1f2
Es decir, la MAC que está bloqueando el VMDK maquina_virtual_foo.vmdk es 0020ea5cc1f2. El siguiente paso es buscar la MAC 00:20:ea:5c:c1:f2 y verificar a qué servidor ESXi pertenece. Para ello podemos ejecutar el siguiente comando en todos los ESXi:
~ # esxcfg-nics -l Name PCI Driver Link Speed Duplex MAC Address MTU Description vmnic0 0000:20:00.00 igb Down 0Mbps Half 00:20:ea:5c:c1:f2 1500 Intel Corporation [...]
Una vez localizado, ya sabemos que el bloqueo se origina desde ese servidor. Podemos ver si el disco está asignado a alguna máquina virtual que está en ejecución en ese servidor y tomar la acción que estimemos oportuna. Como ya sabemos cual es el servidor bloqueante, podemos usar el comando lsof para averiguar exactmaente cual es el proceso al que pertenece el bloqueo:
lsof | grep maquina_virtual_foo.vmdk
Según el proceso que sea, ya es cuestión de saber si podemos/debemos matar el proceso…
~# kill <PID>
Si trabajamos con NFS hay que revisar si tenemos archivos de bloqueo (con extensión .lck. Estos archivos pueden ser eliminados siempre y cuando la máquina virtual esté apagada.
Si el disco bloqueado es el disco principal de la máquina virtual, lo que se suele hacer es eliminar del inventario de ese ESXi la VM y se añade de nuevo para que se desbloquee. Personalmente nunca he probado esta solución. Si tras estos pasos seguís sin encontrar el origen del bloqueo o no conseguís solucionarlo, echad un vistazo a esta KB de VMware donde explican esta y alguna otra solucion más para casos concretos.
Por supuesto, reiniciar el host ESXi en el que se encuentra la VM bloqueada también es una opción válida, simplemente migramos con vMotion el resto de máquinas virtuales que haya en ese servidor y procedemos al reinicio.