Fuimos el primer partner al que se le dió formación sobre el producto cuando aún era una versión beta.

Vino un francés a darnos el curso y lo que ví me encantó. Por aquel momento llevaba ya como un año dando el coñazo en mi empresa con la virtualización en Linux. No por que la cosiderará lista para entornos en producción, de una forma generalista, si no por conocer el producto y posicionarse en el mercado y ser uno de los referentes o el referente para cuando estuviera lista para una adopción de forma generalizada.

Muchos hablarán maravillas de la virtualización en Linux que si el antiguo UML (User Mode Linux), Xen o KVM. La virtualización lleva funcionando en Linux mucho tiempo pero la tecnología no está lo sufucientemente madura como para ser considerada en serio de forma generalizada.

Me explico, hay clientes para los que a día de hoy los sistemas de virtualización basados en tecnologías OpenSource (no confundir con gratis) les pueden servir y les dan garantías para su negocio pero hay otros muchos en los que no.

Hoy por hoy y le pese a quien le pese (y yo soy uno de ellos) VMware es el Rey en virtualización (Intel y AMD) y está a años luz de cualquier competidor desde el punto de vista tecnológico.

El producto de Red Hat es, para mi, la segunda opción más fiable. Me han hablado maravillas del producto comercial de Xen pero como no lo he podido evaluar no voy a dar mi opinión sobre él basandome en leer PDFs como hacen los gurús de hoy en día.

El producto de Red Hat, RHEV, está lo suficientemente maduro como para encajar en los planes de muchas empresas que no necesitan toda la potencia que VMware te ofrece y obviamente pagas.

Las mayores pegas que le encuentro al sistema de Red Hat son:

• No hay posibilidad de hacer Snapshots en caliente. Esto es un gran inconveniente ya que a la hora de hacer actualizaciones nos permite una marcha atrás rápida, comoda y flexible. Sin tener que apagar la máquina.

• No hay posibilidad de añadir hardware virtual en caliente. A la hora de añadir discos en caliente para gestionar el crecimiento de nuestros servidores si tenemos que apagar la máquina deberemos pedir una ventana con el consiguiente impacto.

• Para montar discos en cluster solo se puede hacer por iSCSI. Esto saldrá subsanado en la versión 3.0, o quizá en la 2.3 (ahora estamos en la 2.2).

• Virtualización de Solaris x86. Desde mi punto de vista creo que Red Hat ha decidido no incluir esto debido a la gran campaña que tiene para migrar entornos Solaris a Red Hat. Creo que es un error ya que tengo algún cliente, GRAN CLIENTE, que no se decidió en su momento a considerar a Red Hat como una alternativa a VMware por este motivo decidiendose a favor de Oracle VM. Pero gracias a las políticas de Oracle y a una demo del que escribe estas líneas han vuelto a considerarlo.

• No es posible, de una forma sencilla, el instalar el manager en una VM dentro del entorno RHEV. Esto puede parecer una tontería pero en la vida real es una practica habitual, mientras que en VMware es una tontería en RHEV no es tan sencillo y es necesario montarla mediante libvirt.

Es cierto que estos temas se van a solucionar en las proximas versiones.

¿Cual es la política por la que se decide en que feature se trabaja para añadirla? Pues es muy sencillo y lógico, la demanda de sus clientes. Obviamente si hay más clientes que demandan la característica A en lugar de la B Red Hat va a poner más carne en el asador para implementar A.

Hay que darle tiempo a Red Hat para que se ponga a nivel en características y fiabilidad con VMware. Hay que reconocer que la velocidad que lleva Red Hat a la hora de mejorar su producto es espectacular y no sólo por añadir características rápido, si no por hacerlo con bastante madurez y robustez. Desde luego que hay bugs, uno me lo he comido, pero el trabajo que están haciendo es sensacional.

Voy a comentar los problemas que me he encontrado en esta migración:

1. Después de migrar una máquina, la primera tardó 7 horas en migrar … Me encuentro con un error al realizar la importación “No puede importar la máquina debido a que el tipo de discos no está soportado”. Bueno pues esto es un bug. La solución era modificar el fichero OVF (Open Virtualization Format) y cambiar los discos de tipo Sparse a Preallocated. No me funcionó.
2. Decido probar con una máquina windows más pequeña. Después de convertirla a kvm me dió un fallo debido a que no encontraba unos paquetes. Revisando la documentación me encontré que era necesario instalar unos paquetes adicionales. Esta información se encontraba en la documentación de RHEL 6 y no del hypervisor. Uno de esos paquetes no está disponible para RHEL 5 ¿adivinad que SO tenía la máquina que había montado para la migraciones? Con lo cual me tocó montar un RHEL6.
3. Realizando la conversión con una RHEL6 me encontré el mismo problema de la importación de discos. Salvo que ahora el “workaround” si funcionó.
4. La importación de los windows fue bien, salvo que no se conservó la configuración de red y tuve que replicarla a mano.
5. Con los linux fue todo bien, salvo que no se el motivo por el cual RHEV le asignó una MAC a la VM pero no la cambió en el SO y me toco hacerlo a mano.

La batalla ahora mismo no se encuentra en tener un producto de virtualización, de hecho pocas novedades van a haber que sean revolucionarias en este campo. La batalla está en todos los productos que hay alrededor del software de virtualización. Desde hace tiempo VMware tiene una suite de productos que complementan su principal producto, vSphere, como:

• Site Recovery Manager, un software que realiza un BRS de un CPD a otro. Ahora mismo estoy trabajando en un proyecto para implementar esto con dos CPDs a 12.000 km.
• Capacity Planner, te realiza un estudio de tu infraestructura física y te determina el número de servidores y características que necesitas para consolidarlo.
• Charge Back, te permite conocer los costes de tu entorno para poder facturar a departamentos, … Ahora con el Cloud Computing esto es esencial.
• Capacity IQ, te permite tener estimaciones de cuando te vas a quedar sin recursos.

Además de esto VMware está trabajando en otra serie de productos entorno a entornos de virtualización que como no estoy seguro de si puedo mentarlos (confidencialidad) no voy a hacerlo. Es en este campo donde ahora mismo está la batalla y no tenemos alternativas Open Source. No se si Red Hat u alguna otra compañia está trabajando en este área. De no ser así volveremos a perder la batalla, que no la guerra. Pero siendo positivo tendremos que decir que sólo tendremos a un paso de distancia a las alternativas no Open Source.

Hoy, revisando unos logs en un cluster de VMware ESX Server me he encontrado con esto en el fichero /var/log/vmware.log:

Todos aquellos que hayan seguido la sitcom Frasier se acordarán de que todos los episodios terminaban con la frase Frasier has left the building.

La frase proviene de la época de Elvis. Cuándo Elvis terminaba un concierto para evitar que la gente se quedará para ver si el Rey se dignaba a volver al escenario se anunciaba al público que Elvis ya no se encontraba en el recinto con un:

Elvis has left the building

¿Será Frasier o quizá Elvis quien inspiró este huevo de pascua?

Estos procesos se llevan a cabo mediante software especializado como por ejemplo Converter (VMware) o Platespin.

Otra forma de afrontarlo es mediante la creación de una imagen de la máquina a virtualizar y restaurarla sobre una máquina virtual. Este método tiene el inconveniente de que el hardware sobre el que va a correr no es el mismo sobre el que la máquina física estaba ejecutándose y el software de restauración deberá soportar el cambio de los drivers de los dispositivos en la imagen restaurada en el entorno virtual.

Todos estos procesos son conocidos y existe software preparado para realizar virtualizaciones de sistemas Windows y Linux. Pero no es el caso de querer virtualizar una máquina Solaris.

Lo primero que hay que aclarar es que las máquinas a virtualizar serán Solaris 10 ejecutándose en servidores x86:

• Solaris 10 ya que es la versión de Solaris soportada por VMware
• Ejecutándose en arquitecturas x86 ya que al virtualizar una máquina los binarios de la física y la virtual serán los mismos. Un binario de SPARC no se ejecuta en x86
• El sistema utiliza UFS

El proceso de virtualización, visto de una forma simple, es el siguiente:

• Creación de la máquina virtual
• Copia de los ficheros de la máquina física a la virtual
• Reajustes en la máquina virtual debido a la infraestructura virtual sobre la que se va a ejecutar, los dispositivos pueden cambiar, se pueden requerir nuevos drivers, …
• Dejar la máquina arrancable

La virtualización la podremos realizar de dos formas:

• En frío, el servidor a virtualizar no estará arrancado
• En caliente, el servidor estará arrancado pudiendo o no estar dando servicio

Virtualización en frío

Para ello es necesario que la máquina no esté arrancada y sin embargo deberemos tener acceso a los discos donde reside la información.

Para ello arrancaremos la máquina física a virtualizar con un sistema Live basado en Linux o Solaris. La mejor opción es utilizar un sistema basado en Solaris.

Una vez arrancado deberemos:

• Configurar la red y tener comunicación con el entorno virtual
• Montamos todo el sistema a virtualizar respetando la jerarquía en un directorio

Al no estar ejecutándose la máquina con el sistema operativo a virtualizar nos aseguraremos de que la máquina virtual será consistente al no estar modificándose los archivos de la misma por ningún proceso.

Virtualización en caliente

La virtualización en caliente la realizaremos con el sistema levantado y corriendo. Dependiendo de los aplicativos que se esten ejecutando en el servidor quizá sea necesario pararlos. Un aplicativo que modifique datos constantemente, como una base de datos, sería conveniente pararlo ya que de lo contrario los datos no serían consistentes.

Creación y preparación de la máquina virtual

Deberemos crear una máquina virtual sobre la que virtualizaremos la máquina física y darle acceso por red a la máquina física. Acto seguido arrancaremos la máquina física con un sistema Live.

Crearemos el particionado, formatearemos las particiones.

Proceso de virtualización

Una vez creadas las particiones y los sistemas de ficheros transferiremos los datos:

• Montamos el sistema de ficheros root y transferimos los datos desde la máquina física
• Una vez transferido el sistema de ficheros root, montaremos uno a uno el resto de sistemas de ficheros e iremos transfiriendo los datos

La transferencia de datos la podemos hacer de varias formas, por scp, rsync o mediante ufsdump/ufsrestore.

Ahora ya tenemos los datos en la máquina virtual pero no arrancará.

A continuación deberemos reconstruir los dispositivos, el fichero /etc/path_to_inst y modificar el boot path de la máquina.

Tenemos que modificar el fichero /etc/vfstab para que los sistemas de ficheros que se montaban de forma automática en la máquina física se puedan seguir montando en la virtual. Esto aplica también a cualquier script o aplicativo que tengamos instalado y monte o utilice dispositivos de bloque.

Los dispositivos de red también habrán cambiando y ahora serán e1000g? con lo cual será necesario renombrar los antiguos ficheros /etc/hostname.???? a /etc/hostname.e1000g?

A continuación deberemos hacer arrancable el sistema reinstalando el gestor de arranque GRUB.

Ya casi hemos terminado. Deberemos desmontar todos los sistemas de ficheros de la máquina virtual y reiniciar en modo failsafe para configurar los nuevos dispositivos. Una vez hecho esto podremos arrancar la máquina y proceder a instalar las VMware Tools.

Tenemos la máquina lista.

Propósito de este artículo

El propósito de este artículo es mostrar como afrontar la virtualización de sistemas Solaris x86 en un entorno virtual.

Este procedimiento ha sido utizado con éxito virtualizando Solaris 10 sobre VMware ESX 3.5 Update 2.

¿Quiere decir esto que la virtualización de Solaris está resumida en este artículo? La respuesta es un rotundo NO.

Este artículo pretende servir de ilustración a como proceder a virtualizar un Solaris 10 sobre VMware. Cada máquina es un mundo y nos podemos encontrar situaciones que no hemos contemplado aquí:

• El sistema está instalado con ZFS
• Se está utilizando Veritas Volume Manager
• Se está utilizando Solaris Volume Manager (SVM) utilizando metadispositivos, replicas, …
• Se está utilizando IPMP
• …

En estos casos el proceso de virtualización se complica y será necesario realizar más tareas en la máquina virtual para adecuar la configuración de la máquina física a la virtual.

Autores

Este procedimiento ha sido realizado por José Angel de Bustos Pérez y José Luis Barquin Guerola.