Clonar una máquina virtual es realmente sencillo. En el caso de KVM es tan simple como apagar la máquina virtual para tener consistencia de datos y utilizar el comando virt-clone.

Podemos hacerlo de dos formas, siguiendo un asistente ejecutando virt-clone con el parámetro –prompt o pasar a mano todos los parámetros necesarios.

En el primer caso simplemente respondemos las preguntas que van saliendo, que básicamente son:

1. Nombre de la máquina virtual a clonar
2. Nombre para la máquina virtual resultante
3. Ruta al disco o discos clonados (discos destino).

# virt-clone --prompt
What is the name of the original virtual machine?
virtual01
What is the name for the cloned virtual machine?
clon_virtual01
What would you like to use as the cloned disk (file path) for '/var/lib/libvirt/images/virtual01.img'?
/var/lib/libvirt/images/clon_virtual01.img
Allocating 'clon_virtual01.img'      5% [=-             ]  29 MB/s | 437 MB     04:25
...
...
Clone clon_virtual01 created successfully

Este mismo ejemplo podríamos ejecutarlo directamente de esta forma (si ejecutáis un –help veréis todos los paramétros:

# virt-clone -o virtual01 -n clon_virtual01 -f /var/lib/libvirt/images/clon_virtual01.img
Cloning virtual01.img 4% [==- ] 134 MB/s | 390 MB 00:58 ETA

Otra opción que hace aún más sencillo el trabajo es dejar al propio sistema que elija automáticamente el nombre de la máquina virtual destino y las rutas a los nuevos discos. Para ello usamos el parámetro auto-clone:

# virt-clone -o virtual01 --auto-clone

Un consejo: la primera vez que arranquéis un clon, hacedlo en single-user, runlevel 1 o cualquiera que os permita modificar la configuración de red para evitar conflictos, MAC e IPs duplicadas, etc.

Ya he hablado en otras ocasiones de Kickstart, explicando el modo de automatizar instalaciones de CentOS con Kickstart. En este caso el proceso es igual, pero aplicándolo a la automatización en virtualización. Si desconocéis como funciona Kickstart/Anaconda os recomiendo revisar antes ese post.

Vamos a ver como automatizar la instalación de máquina virtuales, en este caso KVM, pero es aplicable a Xen y otros sistemas de virtualización.

Vamos a hacer uso de la herramienta virt-install para las instalaciones. Esta es la línea de comandos que podemos usar para instalar una máquina virtual Scientific Linux (sería igual para RHEL, CentOS, Fedora…) sin intervención manual:

# virt-install  --name testKS \
                --ram 512 \
                --disk /var/lib/libvirt/images/testks.img,size=5 \
                 -l "ftp://ftp.scientificlinux.org/linux/scientific/6.1/x86_64/os/" \
                 -x "ks=ftp://192.168.1.130/pub/ks.cfg"

Starting install...
Retrieving file .treeinfo...                           |  768 B     00:00 ...
Retrieving file vmlinuz...                             | 7.4 MB     00:05 ...
Retrieving file initrd.img...                          |  68 MB     00:53 ...
Creating domain...                                     |    0 B     00:00

Los parámetros utilizados son los siguientes:

• –name: nombre de la máquina virtual.
• –ram: tamaño de memoria RAM en MB.
• –disk: ruta y nombre del fichero .img que será utilizado como disco duro virtual. Tras la ruta a la imagen se especifica el tamaño en GB de la imágen (5).
• -l (–location): especifica el lugar donde se encuentra el instalador del sistema (vmlinuz e initrd.img), en este caso especificamos el respositorio oficial de Scifi Linux y la ruta exacta para 64bits.
• -x (–extra-args): especificamos argumentos extra para la instalación, en este caso tiene que ser la ruta al fichero Kickstart que tiene toda la configuración del proceso de instalación.

Y esto es todo. Si el fichero Kickstart está bien, se realizará una instalación totalmente desatendida del sistema operativo.

A la hora de crear una zona en Solaris (Solaris Zones|Solaris Containers), es imprescindible que el zonepath, que es el lugar físico en el que se va a alojar sea un sistema de ficheros zfs independiente, también llamado ZFS dataset. En caso contrario recibiremos este error a la hora de instalarla:

ERROR: No zonepath dataset; the zonepath must be a ZFS dataset.

El error es lo suficientemente descriptivo. A la hora de configurar la zona, establecemos el zonepath del siguiente modo dentro del modo de configuración de la zona:

# zonecfg -z zona01
zonecfg:zona01> set zonepath=/ruta/a/la/zona

El paso previo es entonces crear el dataset correspondiente:

# zfs create /rpool/zones
# zfs create /rpool/zones/zona01

Una vez realizado, podemos establecer como zonepath “/rpool/zones/zona01″, verificar la configuración con “verify”, hacer el “commit” e instalar la zona:

# zoneadm -z zona01 install

El otro día se publicó una KB de Parallels sobre algo que llevaba tiempo intentando poder hacer. Cuando te bajas el instalador de Parallels Virtuozzo Containers para Linux, al comenzar la instalación siempre te fuerza a instalar la última versión disponible. En caso de estar obligado a instalar una versión específica, podemos hacerlo siguiendo estos pasos:

Lo primero es bajar el instalador como lo haríamos normalmente:

# wget http://download.parallels.com/pvc/47/lin/vzinstall-linux-x86_64.bin
# chmod a+x vzinstall-linux-x86_64.bin

Una vez descargado, con el parámetro ‘list‘ podemos ver las versiones y arquitecturas disponibles para la instalación:

# ./vzinstall-linux-x86_64.bin list
Downloading index files...
Templates set: (Default set)
Version  Platform  Architecture  Download size
4.7.0-94 Linux     i386          544MB
4.7.0-94 Linux     x86_64        789MB
4.6.0-187Linux     i386          607MB
4.6.0-187Linux     x86_64        782MB
4.0.0-448Linux     i386          848MB
4.0.0-448Linux     ia64          940MB
4.0.0-448Linux     x86_64        1.0GB
4.0      w2k3      i386          41MB
4.0      w2k3      ia64          60MB
4.0      w2k3      x86_64        48MB

Ahora solo queda elegir la versión, plataforma y arquitectura para nuestra instalación. Si quisieramos instalar la versión 4.6.0-187 para 64 bits Linux:

# ./vzinstall-linux-x86_64.bin install --archs x86_64 --dist-ver 4.6.0-187 --platforms Linux

Vamos a ver la posible solución a este problema, que se nos presenta cuando intentamos convertir un sistema Linux de una máquina física a una máquina virtual (vmware p2v) de VMware con la herramienta VMware vCenter Converter Standalone.

El problema se reproduce después de introducir los datos correctos de conexión SSH al servidor. Estos datos vemos que son correctos porque si ponemos unos incorrectos salta el error. Además, en la máquina que intentamos migrar si hacemos un tcpdump vemos que efectivamente está llegando bien.

Este es el error que recibimos en el primer paso de la conversión:

VMware: Unable to query the live Linux source machine

En nuestro caso, el problema no tenía que ver ni con el firewall del sistema, ni con restricciones TCP Wrappers, ni con SELinux, etc. El problema tenía origen en las restricciones establecidas en la partición temporal /tmp. Nosotros montamos /tmp con los bits noexec y nosuid. Algo común en servidores con cPanel:

/usr/tmpDSK on /tmp type ext3 (rw,noexec,nosuid,loop=/dev/loop0)

Al parecer VMware intenta ejecutar y realizar acciones en /tmp, y debido a esto no puede. Podemos solucionarlo entonces montando /tmp temporalmente con los bits de ejecución:

# mount -o remount  -t ext3 /usr/tmpDSK /tmp -o rw,exec,nodev -o loop

Y cuando acabemos securizar de nuevo:

# mount -o remount  -t ext3 /usr/tmpDSK /tmp -o rw,noexec,nosuid -o loop

En los últimos días, debido al problema acontecido en el servicio de Cloud Computing de Amazon provocado por la caída de un rayo en el CPD de Irlanda, ha vuelto a surgir el debate sobre los beneficios del Cloud Computing frente a otro tipo de soportes más convencionales, como por ejemplo los servidores dedicados. Cada producto tienes sus ventajas e inconvenientes, así que vamos a intentar ver a que tipo de cliente puede ir dirigido uno y otro.

Puesta en marcha

En una infraestructura Cloud Computing/cloud hosting puedes poner en marcha un buen número de instancias de servidores, balanceadores, redes, firewalls, etc en escasos minutos. Esto es impensable en servidores dedicados, en los que normalmente se tarda entre 24 y 48 horas como mínimo en tener el servicio activo.

Escalabilidad

La filosofía básica del Cloud Computing es la de pagar por los recursos que utilizas, nada más. Si tú necesitas durante X tiempo un número mayor de recursos (memoria, disco, cpu, etc) puedes ampliar tus instancias de forma prácticamente instantanea y una vez finalizado volver a la normalidad. Esto es un gran avance respecto a un servidor dedicado, en el que desde un primer momento contratas una máquina física con unos recursos concretos, los cuales puedes estar desaprovechando (probablemente) o llegar un momento en el que se queden cortos y sea más laborioso la ampliación de piezas.

Precio y costes

Este punto va íntimamente relacionado con el de la escalabilidad. Es de suponer que siempre será más caro contratar un servidor dedicado que alojar un proyecto en la nube. Esto es debido a que mientras que en la nube conforme necesitas más recursos los vas contratando, en un servidor dedicado has de disponer desde un principio de unos recursos fijos, los uses o no. No obstante este punto puede variar según el proyecto, requerimientos, etc.

Administración de tú infraestructura

La mayoría de proveedores de hosting ofrecen la posibilidad de contratar un paquete completo de servidor dedicado + administración. Esto implica que es el proveedor el encargado de la puesta en marcha del servidor, los servicios y de brindarte soporte ante cualquier tipo de problema que encuentres. Por otro lado, la mayoría de proveedores de Cloud Computing no ofrecen servicio de administración, lo que implica que eres tú el encargado de mantener tus máquinas virtuales alojadas en la nube.

Alta disponibilidad

El Cloud Computing es la panacea de la alta disponibilidad, al no depender directamente del hardware las posibilidades de parada debido a fallos físicos se reducen casi al 99%, excepto casos especiales como lo sucedido estos días en Amazon, algo que, en caso de tener nuestras instancias virtuales replicadas en distintos centros de datos haría imposible la posibilidad de caída por fallos físicos. En cambio, en un servidor dedicado estás supeditado a cualquier problema físico: fallos de discos (para evitarlo siempre hay que contratar servidores dedicados con raid por hardware), fallos de fuentes de alimentación, memoria, etc. Los servidores con los componentes redundados suelen salir bastante más caros.

Rendimiento

En temas de rendimiento es probable que el servidor dedicado salga ganando. Sabes que no compartes tu infraestructura física con ningún otro cliente, dispones del 100% del hardware para ti, mientras que en la nube siempre tendrás una “porción del pastel” al igual que el resto de clientes alojados en la nube, esparcidos a lo largo de X número de servidores.

Seguridad y privacidad

Este punto estaría más enfocado al hecho de llevar aplicaciones a la nube en lugar de mantenerlas en equipos físicos (aplicaciones de ofimática, contabilidad, correo…). Nosotros no conocemos el nivel de seguridad de la nube y nuestros datos pueden estar al alcance de cualquiera en caso de un fallo de seguridad.

Espero que os hayan servidor de ayuda estos puntos para aclararos sobre los beneficios de cada opción. Al final, lo mejor es probarlo por ti mismo y seleccionar la mejor opción según nuestras necesidades.

Ya está disponible la plantilla EZ del sistema operativo CentOS 6 para sistemas de virtualización Virtuozzo Containers. La plantilla es compatible tanto para Virtuozzo Containers for Linux 4.6 como Virtuozzo Containers for Linux 4.0.

La plantilla está disponible tanto para 32 como 64 bits a través de los siguientes rpm:

centos-6-x86-ez-4.0.0-2.noarch.rpm
centos-6-x86_64-ez-4.0.0-2.noarch.rpm

Y las aplicaciones disponibles son las siguientes:

32-bit:

cyrus-imap-centos-6-x86-ez-4.0.0-1.noarch.rpm
devel-centos-6-x86-ez-4.0.0-1.noarch.rpm
jre-centos-6-x86-ez-4.0.0-1.noarch.rpm
jsdk-centos-6-x86-ez-4.0.0-1.noarch.rpm
mailman-centos-6-x86-ez-4.0.0-1.noarch.rpm
mod_perl-centos-6-x86-ez-4.0.0-1.noarch.rpm
mod_ssl-centos-6-x86-ez-4.0.0-1.noarch.rpm
mysql-centos-6-x86-ez-4.0.0-1.noarch.rpm
php-centos-6-x86-ez-4.0.0-1.noarch.rpm
postgresql-centos-6-x86-ez-4.0.0-1.noarch.rpm
spamassassin-centos-6-x86-ez-4.0.0-1.noarch.rpm
tomcat-centos-6-x86-ez-4.0.0-1.noarch.rpm
vsftpd-centos-6-x86-ez-4.0.0-1.noarch.rpm
webalizer-centos-6-x86-ez-4.0.0-1.noarch.rpm

64-bit:

cyrus-imap-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
devel-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
jre-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
jsdk-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
mailman-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
mod_perl-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
mod_ssl-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
mysql-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
php-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
postgresql-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
spamassassin-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
tomcat-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
vsftpd-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
webalizer-centos-6-x86_64-ez-4.0.0-1.noarch.rpm

Si no sabéis instalar plantillas de sistemas operativos o aplicaciones en Virtuozzo revisad este otro artículo: Instalar plantillas en Virtuozzo.

El otro día escribí un artículo en el que se explicaban las diferencias entre atime, noatime y relatime, podéis leerlo si queréis saber las diferencias entre cada una de estos atributos asignables a los sistemas de ficheros.

En esta entrada vamos a ver la forma correcta de modificar este atributo a una máquina virtual o contenedor en los sistemas de virtualización Virtuozzo y OpenVZ. En lugar de asignar los atributos a nivel de /etc/fstab debemos hacerlo mediante el comando

. En el siguiente ejemplo asignamos el atributo noatime al contenedor con ID 150, lo haremos en el nodo hardware:

# vzctl set 150 --noatime yes --save
Setting noatime mount flag for Container
Saved parameters for Container 150

Una vez realizado, podemos acceder a la máquina virtual y verificar que el cambio se ha realizado correctamente:

# mount
/dev/vzfs on / type vzfs (rw,noatime)