Hace un par de días tuve un problema al tratar de borrar un snapshot de una máquina virtual OpenMediaVault. Como me llevó bastante tiempo localizar el problema (novato que es uno) y la solución técnica es bastante sencilla la detallo por aquí confiando en que a alguien le sea de utilidad en el futuro.
Como decía, el problema surgió al borrar el snapshot. Durante el proceso, por algún motivo, la máquina se queda en estado congelado. Al finalizar, trato de acceder a ella para poder apagar el sistema operativo sin recurrir al botonazo pero se encuentra inaccesible incluso desde la consola remota de vSphere. Tras apagarla de forma abrupta me encuentro con que no es posible iniciarla de nuevo de ninguna manera, de modo que trato de subsanar el problema consolidando los discos, sin éxito.
Yendo a los detalles en el registro de eventos se indica que no se pudo encender por una sucesión de errores a partir de la inaccesibilidad al vmdk (disco de la vm) que soporta la máquina OpenMediaVault. Aunque a la postre haber actuado leyendo este esbozo del log habría sido suficiente para resolver el problema, opté por descargar el log de sucesos de la máquina virtual para ver un registro más detallado de lo ocurrido en los momentos previos al intento de arranque.
El archivo de log de la máquina se puede descargar usando el explorador de archivos de vSphere, navegando desde el datastore hasta el directorio de la máquina. El archivo más reciente siempre es el vmware.log, ya que la rotación de logs funciona de tal manera que cuando el archivo se completa se guarda como vmware-1.log y todos los que haya a mayores (desde el anterior vmware-1.log a los siguientes) suman un número.
El log de la máquina viene a confirmar lo que trasladaba el error de la segunda captura: que el origen del fallo al encender radica en que el sistema no puede encontrar el path del vmdk que contiene el sistema operativo.
Volviendo a vSphere, comprobamos en la máquina que los paths de los dos discos apuntan a un vmdk que no es el del disco duro base sino el delta, que no se muestra en el explorador de archivos debido a que se eliminó con el snap.
De manera que, identificado el problema, la operativa para resolverlo es muy sencilla: desatachamos los discos de la máquina y volvemos a montarlos apuntando al path correcto. Aunque parece evidente, es importante no clicar en el checkbox «Eliminar archivos del almacén de datos», ya que lo que haría sería borrar el disco del datastore, del mismo modo que si formateásemos un disco físico. Esto sólo lo haríamos en caso de que quisiéramos borrar la máquina virtual y recuperar el espacio de los vdisks que contiene.
De modo que volvemos a agregar los discos, eligiendo obviamente un disco existente, y nos aseguramos de seleccionar el archivo vmdk correcto dentro del datastore y máquina adecuados.
En mi caso, para el disco principal debo ir al disco SSD que contiene el vmdk del sistema operativo y para el secundario, de datos, al disco NAS.
Hecho esto, comprobamos que tanto el inicio de la máquina como la consolidación de discos se realizan correctamente, con lo que queda solucionado un problema que (localizado) no lleva más de cinco minutos resolver.
Bonus track: lo que sucedió con el sistema de archivos te sorprenderá
En este caso en particular, además, cuando encendí cuál fue mi disgusto al comprobar que el sistema de archivos se había dañado durante el proceso de borrado del snap que provocó la incongruencia en los paths.
Por suerte, bastó con una simple ejecución de la herramienta fsck, que comprueba y repara los bloques de ficheros dañados. Ejecutada sin especificar discos examinará todos los que integren el sistema y estén desmontados. Podemos desmontar un disco usando umount seguido bien del disco, bien del punto de montaje.
Al ejecutarse con los argumentos -f y -y fuerza el chequeo de todo el sistema de ficheros y responde afirmativamente a las peticiones de arreglo de manera automática, ya que de otro modo nos pasaríamos un buen rato interaccionando con la máquina innecesariamente (dado que no sé dónde se localiza el problema quiero que examine el sistema íntegramente).
Una vez reparado el sistema de ficheros ya se puede acceder a él con normalidad. Conviene recordar que fsck no debe ser la primera opción a la hora de reparar un fs (y menos ejecutado de esa manera), ya que podría dar como resultado la pérdida de datos válidos.
