Problemas con snapshots en máquinas virtuales

Como norma general no soy muy amigo de utilizar snapshots en las máquinas virtuales, al menos durante mucho tiempo, ya que ralentizan el acceso a disco. Al fin y al cabo hay que comprobar en que disco virtual está escrito el dato antes de leerlo o modificarlo, y eso quiere decir más I/O al sistema de almacenamiento.

Normalmente, en sistemas pequeños de pocas decenas de máquinas, esto no suele presentar muchos problemas pero, cuando pasamos a contarlas con números de tres o cuatro cifras, la cosa cambia ya que el rendimiento del disco suele ser en lo que menos se piensa cuando se dimensiona un sistema virtual. Por lo general solemos sumar la memoria RAM de las máquinas y el espacio en disco que ocupan, pero cuando el entorno crece (y es muy fácil crecer un entorno virtual) nos llevamos el susto.

Para el que no conozca en que se basa la técnica de snapshot aquí hay un vídeo de la KB de VMWare que lo explica a la perfección.

A pesar de eso hay que reconocer que los snapshots son muy potentes y útiles, especialmente cuando no estamos seguros si una actualización nos va a dar problemas, o vamos a hacer algún cambio importante en una máquina o queremos realizar una copia de seguridad de la máquina “en caliente”.

La gran mayoría de programas de backup se basan en esta técnica para copiar las máquinas virtuales sin que tengamos que pararlas y casi siempre funcionan bien… casi siempre…

Concretamente, uno de los errores que nos ha reportado un cliente hace poco, consistía en varias máquinas virtuales que no arrancaban dando el siguiente mensaje de error:

Failed to open 'virtual machine disk': The parent virtual disk has been modified since the child was created

Un compañero encontró que el problema residía en que, los CID de los discos de cada máquina virtual no concordaban con su “Parent CID”, y por lo tanto la máquina virtual no podía arrancar al no encontrar parte del disco.

En los ficheros *.vmdk se guarda la información referente al disco (los datos están en el *-flat.vmdk), como por ejemplo: el tamaño, los cabezales, platos, sectores y, lo que nos interesa, el CID y Parent CID.

El CID es el número que referencia al fichero que compone el disco de forma única mediante un código hexadecimal de 8 caracteres. El “Parent CID” referencia al fichero que le precede (el anterior snapshot o el original) de la misma forma. En caso de tratarse del primer fichero, como no tiene anterior, el Parent CID es “#FFFFFFFF”.

La forma de solucionar el problema es modificando los CID de los ficheros para que se referencien correctamente y en orden, es decir, que el Parent CID del último fichero corresponda al CID del penúltimo, el Parent CID del penúltimo con el CID del antepenúltimo y así sucesivamente hasta llegar al primero.

Para mí la forma más sencilla de realizar estos cambios es desde una conexión SSH a uno de los hosts (instrucciones de como hacerlo aquí), aunque podéis elegir la forma que os sea más cómoda. Son simplemente ficheros de texto, aunque hay tener cuidado con los retornos de carro.

El trabajo es un poco tedioso y, si la máquina virtual tiene muchos snapshot, quizás sería bueno apuntar los CID en papel para no equivocaros, pero  una vez modificados los ficheros la maquina debería arrancar correctamente.

Por si no queda muy claro, o no os fiáis (no os culpo, que modificar estas cosas “a pelo” siempre da miedo) tenéis la solución completa y oficial en este enlace.


Comments are closed.