VMware: Cómo Solucionar el Error 'VMDK Locked' – Causas y Resolución

En entornos vSphere, es común encontrarse con el error Unable to access file since it is locked al intentar encender una máquina virtual o realizar una migración (vMotion). Este problema, aunque frustrante, suele ser un mecanismo de protección del sistema de archivos VMFS para evitar la corrupción de datos.

A continuación, detallo el análisis técnico y los pasos para liberar estos bloqueos, específicamente cuando se presentan en modo Read-Only.

Diagnóstico Técnico del Error

El análisis de los logs de ESXi es fundamental para identificar qué host y qué proceso mantienen el archivo retenido. En un caso típico, el log muestra información parecida a esta:

• Archivos bloqueados: VM_NAME-flat.vmdk (los archivos -flat contienen los datos reales binarios).
• Host del bloqueo: Identificado por IP y dirección MAC.
• World ID: El ID de proceso interno de ESXi que posee el lock.
• Lock Mode: Read-Only.

Un bloqueo Read-Only indica casi siempre que el archivo está siendo leído por un proceso externo a la ejecución normal de la VM, como un agente de respaldo o un proceso de replicación.

La Causa Raíz: El fallo del Backup Proxy

La causa más frecuente de este error es el modo de transporte Hot-Add utilizado por softwares como Veeam, Commvault o Veritas.

Cuando se ejecuta un respaldo, el Backup Proxy (una VM dedicada) “mapea” o monta los discos de la VM objetivo en sí mismo para leer los datos directamente a través del bus SCSI, evitando el tráfico por la red de administración. Si el trabajo de respaldo falla o se cancela de forma abrupta, el software no envía la instrucción de “unmount”, dejando el disco bloqueado en el Proxy y, por ende, inaccesible para la VM original.

El Peligro de las Snapshots no Consolidadas

El bloqueo de archivos suele impedir la consolidación de snapshots. Ignorar este estado “Need Consolidation” conlleva riesgos operativos graves:

1. Degradación de I/O: Cada snapshot adicional obliga al host a consultar múltiples archivos de metadatos antes de leer un bloque, incrementando la latencia.
2. Llenado del Datastore: Las snapshots crecen de forma indeterminada. Si el datastore llega al 100%, todas las VMs en ese volumen se detendrán inmediatamente.
3. Stun Time Prolongado: Entre más tiempo pase sin consolidar, más grande será el archivo delta. Al intentar consolidar finalmente, el “stun time” (tiempo de congelación de la VM) puede ser tan alto que provoque la caída de servicios críticos o desconexiones de red.

Guía de Resolución Paso a Paso

1. Limpieza de Discos en el Backup Proxy

Es el primer paso obligatorio. No intentes forzar el encendido de la VM sin antes verificar esto.

• Localiza los Proxies de respaldo en tu infraestructura.
• En vCenter, selecciona Edit Settings sobre el Proxy.
• Identifica discos que no pertenecen al Proxy (compara las rutas de los archivos .vmdk).

2. Terminación de Procesos Huérfanos (World ID)

Si tras limpiar el Proxy el bloqueo persiste, es probable que el proceso vmx en el host ESXi haya quedado colgado (zombie).

1. Conéctate por SSH al host que retiene el bloqueo.
2. Identifica el proceso con el World ID obtenido del log:

   esxcli vm process list
   

3. Fuerza el cierre del proceso (reemplaza ID por tu World ID):

   esxcli vm process kill --type=force --world-id=ID
   

3. Reinicio de Agentes de Administración

Como último recurso, si el sistema de archivos sigue reportando el lock, reinicia los servicios de administración del host para limpiar la tabla de bloqueos en memoria.

/etc/init.d/hostd restart
/etc/init.d/vpxa restart

Nota: Esto no apaga las VMs en ejecución, solo refresca la conexión con vCenter.

4. Consolidación de la Máquina Virtual

Liberar el bloqueo del archivo a nivel de host o proxy no elimina los discos delta que quedaron huérfanos durante el fallo. vCenter seguirá mostrando la advertencia de que la máquina requiere consolidación. Es obligatorio ejecutar esta tarea para limpiar la advertencia y unificar los datos.

1. En vCenter, haz clic derecho sobre la máquina virtual afectada.
2. Navega a Snapshots > Consolidate.

3. Monitorea la tarea en el panel de eventos hasta su finalización.

Conclusión y Crítica

El bloqueo de archivos VMDK es un síntoma, no el problema raíz. Si este error ocurre con frecuencia, es necesario revisar la salud de la red de almacenamiento o el dimensionamiento de los Backup Proxies. Un proxy saturado de recursos es la causa principal de que los discos no se desmonten correctamente, generando deuda técnica en forma de snapshots huérfanas.