En el día de hoy, vamos a ver como configurar nuestros XenServer para poder enviar correos electrónicos desde ellos mismos utilizando un smarthost.

Es útil configurar un cliente de correo como mailx para poder enviarnos notificaciones de nuestros scripts como por ejemplo los scripts que se ejecuten de forma automática utilizando cron.

Citrix XenServer, tiene un corazón CentOS, por ello podemos instalar paquetes rpm compilados para CentOs 5. Desde un mirror cualquiera como:

http://mirror.ovh.net/ftp.centos.org/5/os/x86_64/CentOS/

Descargamos el paquete rpm que necesitamos:  mailx-8.1.1-44.2.2.x86_64.rpm

Una vez descargado, lo instalamos:

root@xenserver01# rpm –Uvh mailx*

warning: mailx-8.1.1-44.2.2.i386.rpm: Header V3 DSA signature: NOKEY, key ID e8562897

Preparing…                ########################################### [100%]

1:mailx                  ########################################### [100%]

Configuramos los parámetros siguientes del fichero: /etc/ssmtp/ssmtp.conf

mailhub=<tu servidor de correo>

rewriteDomain=<tu dominio>

Ahora ya puedes enviar mails desde tus XenServer a tu correo electrónico con mailx

root@xenserver01# cat fichero | mailx –s “test” tudireccion@correo.com

Espero que como siempre, te haya sido de utilidad. Saludos

¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, hoy os presento Xen Cloud Plataform (XCP), ya desde la versión 1.0 la estoy utilizando y creo que ha llegado el momento de hablar un poco sobre este proyecto libre.  Para los que no lo conozcáis, deciros que es una solución open-source derivada de Citrix XenServer 5.6.FP1 totalmente funcional.

XCP es una versión empaquetada de GNU/Linux CentOS (kernel 2.6.32) con Xen 3.4.2 y XenAPI (XAPI).  Por lo tanto, los que ya estéis usando XenServer, vereis quela Xapi y sus comandos son los mismos y además  es compatible con XenCenter.

Hay mutiltud de herramientas de administración, tanto del uso tradicional del hipervisor como frontends de gestión de clouds, compatibles con XCP: http://wiki.xen.org/wiki/XenManagementTools

También nos ofrece, al igual que Citrix XenServer, soporte para HVM (si el servidor físico lo soporta),  paravirtualización de nuestros servidores GNU/Linux (PV) y soporte nativo de máquinas instaladas con Citrix XenServer.

Podéis ver una matriz de funcionalidades donde se compara Xen Cloud Plataform con las distintas versiones de licenciamento de Citrix XenServer:

http://wiki.xen.org/wiki/XCP/XenServer_Feature_Matrix

La instalación es idéntica a la que tenemos con Citrix XenServer, se basa en una imagen de cd .iso auto-arrancable que en unos pocos pasos permite tener el sistema completamente operativo.

Por supuesto trae consigo soporte para bootear sobre SAN, hbas, multipath, soporte para i-scsi y un largo etc. Que podeis ver en: http://xen.org/download/xcp/index.html

La última versión oficial disponible es la XCP 1.1 que recomiendo a todos los lectores, probarla, no deja indiferente

La página de descarga es: http://xen.org/download/xcp/index_1.1.0.html

Con esto, espero como siempre que os sea de utilidad. Saludos

¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, hoy veremos como pasar una maquina virtual de un entorno VMware ESX a Citrix XenServer.

El procedimiento es muy sencillo, nos basamos en el formato OVF, soportando tanto por VMware como Citrix XenServer. OVF es un estándar abierto para empaquetar máquinas virtuales. El inconveniente es que no es en caliente, ya que necesitamos que la máquina virtual este apagada en el entorno VMware.

Accedemos a nuestro entrono VMware con vShpere Client, nos situamos sobre la máquina virtual que queremos exportar y vamos a File -> Export -> Export OVF Template. Lo exportamos a nuestro disco local y lo optimizamos para Web (OVF).

Una vez finalizado el tiempo de exportación, ya tendremos nuestra máquina virtual lista para ser importada a nuestro entorno Citrix XenServer.

Entramos a nuestro entorno XenServer con XenCenter. Sobre el pool donde queremos que esté nuestra máquina virtual vamos a File -> Import.

Añadimos como Filename el fichero OVF de la máquina virtual VMware.

Seleccionamos el SR donde colocar los discos de la máquina virtual y la red. Pasados unos minutos, ya tendremos la máquina virtual en nuestro entorno XenServer. No hay que olvidarse, una vez levantada la máquina virtual, de instalar las XenTools para que esté totalmente optimizada para Citrix XenServer.

Con este método ya podéis exportar vuestras máquinas virtuales ya sean VMware ESX/Workstation, VirtualBox, etc. A vuestro entorno Citrix XenServer. Como siempre, espero que os haya sido de utilidad. Un saludo!

¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, después de unos días de vacaciones… hay que volver a la carga. En el último post sobre monitorización de XenServer con Nagios, faltaba ver la monitorización de storage y otros checkeos avanzados para tener bien controlada nuestra infraestructura.

1. Para monitorizar los SR de nuestro pool, primeramente hay que extraer la información que nos da la Xapi:

/usr/bin/xe sr-param-get uuid=<UUID-SR> param-name=physical-size

/usr/bin/xe sr-param-get uuid=<UUID-SR> param-name=physical-utilisation

Mediante estos datos, podemos establecer la lógica que queramos para que nos informe del estado del disco:

#/bin/bash

let total_alloc=`sudo /usr/bin/xe sr-param-get uuid=84ca4fbd-f150-1f62-c9e4-ee4a656558d5 param-name=physical-utilisation`

let total_bytes=`sudo /usr/bin/xe sr-param-get uuid=84ca4fbd-f150-1f62-c9e4-ee4a656558d5 param-name=physical-size`

let factor=1073741824

total_alloc_Gb=`expr $total_alloc \/ $factor`

total_bytes_Gb=`expr $total_bytes \/ $factor`

let free_space=`expr $total_bytes_Gb – $total_alloc_Gb`

total_percentage=`expr 100 \* $total_alloc_Gb \/ $total_bytes_Gb`

#echo $free_space

#echo $total_percentage

if [ $total_percentage -ge "90" ] ; then

echo “CRITICAL: Disc al $total_percentage%”

EXIT=2

else

if [ $total_percentage -ge "80" ] ; then

echo “WARNING: Disc al $total_percentage”

EXIT=1

else

echo “OK: Disc al $total_percentage%”

EXIT=0

fi

fi

exit $EXIT

 

2. Otro checkeo importante que nos puede ser muy útil es comprobar el estado de la XAPI en cada servidor:

#!/bin/bash

#Check que comprueba el estado de la XAPI

#contamos los procesos que hay de xapi

procs=`ps -elf | grep xapi | grep -v grep | wc -l`

#Verificamos que haya algun proc xapi y si no lo hay, critical

if [ -z "$procs" ] ; then

echo “Critical: No hay procesos de Xapi”

exit=1

else #Hay procesos, pues lanzamos una peticion para ver si respnde ok

#Vemos si es capaz de conectar con la Xapi y extramos el número de hosts del pool

test_xapi=`sudo xe host-list | grep name-label | wc -l`

#test_xapi=”1″ #Fuerza a warning

if [ $test_xapi -gt 0 ]; then

ok_test=$(sudo xe host-list name-label=`hostname` params=name-label –minimal)

echo “OK: XAPI respondiendo en $ok_test “

exit=0

else

new_test=$(sudo xe host-list name-label=`hostname` params=name-label –minimal)

echo “Warning: Hay procs de XAPI pero algo falla $new_test”

exit=1

fi

fi

#Salida con el codigo de error para Nagios

exit $exit

A grandes rasgos el checkeo comprueba primeramente que hay procesos de Xapi en la “GNU/Linux LAND” y si existen, ejecuta un xe-host-list. Si este falla retornará código de error ya que aunque haya procesos, la XAPI no responde.

3. Estado de los caminos del Multipath

Es importante tener bien monitorizados los caminos si usáis multipath para los que utilicéis una cabina de discos. Una forma de comprobar que están todos OK es filtrar por faulty en la salida de multipath –ll

#!/bin/bash

fault=`sudo /sbin/multipath -ll | grep faulty | wc -l`

if [ $fault -gt 0 ]; then

echo “Algun camino caído”

exit 1

else

echo “Todos los caminos: OK”

exit 0

fi

Con esto, espero haberos dado herramientas para que os programéis vuestros propios monitores, ya sea medianteXAPI o mediante comandos gnu/Linux y si me permitís, me encantaría saber que monitorizáis de vuestros XenServers. Un saludo.

¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, hoy voy a repasar el Webinar de Citrix de la semana pasada, “XenServer 6.0 Technical Master Class” con Lee Bushen y Steve Benton ya que fue muy constructivo y creo que puede ser de vuestro interés.

Podéis descargarlos el material desde:

https://citrix.sharefile.com/d/sa724d4cc19543f8b

En el primer cuarto de hora se pudo ver el funcionamiento interno de XenServer, donde se mostró de una forma muy gráfica [PAG 8 del pdf], los dos “pueblos” que componen este sistema. Por un lado “Xenville” donde vemos “xe”, la XAPI y la “XenServer Pool DB (state.db) y por otro lado la parte “Linux Land”, donde al final, todo lo que interpreta la XAPI, se transforma en ficheros de configuración GNU/LINUX.

Posteriormente se explicó algo que ya hemos hablado en este blog, como XenServer organiza el Storage con sus diferencias y modalidades. SR’s, PBD’s, VBD’s. Una parte muy interesante de esta sección fue cuando explicaron cómo se organizan internamente los snapshots, en función del tipo de almacenamiento que podemos utilizar, NFS y Storage Local, LVMD, iSCSI y FC.

Podemos complementar el PDF con la documentación oficial de Citrix sobre los snapshots: http://support.citrix.com/article/CTX122978

Del mismo modo que el storage, en parte de comunicaciones, se explicó desde el hardware hasta llegar a los dispositivos de red virtuales, el funcionamiento de los bridges y como XenServer utiliza el bonding.

Os dejo también una lista de comandos útiles de Linux y XenServer: https://citrix.sharefile.com/d/s53888bbff9b44949

Y la Network Throughput Guide: http://wiki.xen.org/wiki/Network_Throughput_Guide

En general el Webinar estuvo muy bien. Aplaudo la iniciativa de Citrix y de otras compañías que ofrecen este tipo de seminarios gratuitos para los fans de sus plataformas.

Con esto amigos, nos vemos la semana que viene con la monitorización del storage con Nagios. Aprovecho también para desearos unas felices fiestas a todos.

¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, hoy os traigo la continuación del post de la semana pasada sobre la monitorización de servidores Citrix XenServer con Nagios.

En el post anterior vimos como configurar Nagios para utilizar sus plugins sin necesidad de instalar nrpe y nos quedamos en la configuración de estos checkeos para monitorizar nuestros Hosts.

Empezamos con la monitorización básica del host.

1. Las CPU’s estén trabajando sin rebasar el 80% de su capacidad.
2. Que la memoria RAM no sobrepase el 80% de espacio ocupado.
3. Que la partición / no se quede sin espacio.
4. Que el Load Average no sobrepase la carga máxima por Cores.
5. Que el/los SR’s no se queden sin espacio.

1.- Para monitorizar la CPU. Recomiendo usar un checkeo personalizado ya que los valores que extraen los plugins originales de Nagios, no extaen la información del hipervisor. Por ejemplo podemos hacer un script como este:

2.- Para la memoria:

3.- Para el disco local /, vamos a utilizar el plugin de nagios. Simplemente definimos el comando en el servidor Nagios como:

Definimos el servicio

4.- Del mismo modo configuraremos el checkeo para el “load average”

Ya tenemos monitorizado nuestro Host. Como habrás visto, la programación de checkeos para Nagios es muy sencilla y lo puedes hacer con el lenguaje de programación que te sea más cómodo.

Esto es todo por hoy. La semana que viene veremos como monitorizar el storage,  nuestro pool y otros checkeos más avanzados. Espero como siempre que te haya parecido interesante. Saludos!!

¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, hoy os traigo el primero de varios posts donde veremos como monitorizar Citrix XenServer con Nagios.

Supongo que todos conocéis la herramienta Nagios para monitorizar vuestros servidores. Por si alguien se le escapa, Nagios «Nagios Ain’t Gonna Insist On Sainthood» es un sistema de monitorización de redes, servidores, etc de código abierto que vigila que todo esta funcionando correctamente.

Actualmente también existen otros sistemas abiertos también muy potentes como Zabbix, Zenoss, Pandora FMS… que seguramente también os va a permitir monitorizar vuestro entorno XenServer. En este post y en los siguientes, veremos como monitorizar un entrono XenServer completo.

Un snapshot de cómo funciona Nagios

Nagios puede usar NRPE, un daemon instalado en los Hosts para extraer la información de cada uno de los scripts que incluye el paquete “Nagios Plugins”. Directamente el servidor Nagios conecta con el servicio NRPE del Host y extrae los resultados del check_nrpe. O bien puede ejecutar comandos remotamente ubicados en el Host.

A modo de opción personal, prefiero utilizar los “Nagios Plugins” sin servicio NRPE. Es decir configurar el comando en el servidor Nagios para que ejecute los scripts remotamente por SSH. De este modo no hay que instalar software extra en los dom0.

Primeramente analicemos nuestro entorno de virtualización y sus elementos hardware:

1. Hosts (Dom0)

2. Storage

3. Comunicaciones

En este primer post sobre la monitorización, veremos los hosts y lo que nos puede ser más útil de monitorizar sobre ellos.

Monitorización de Hosts

En general, podemos monitorizar lo que queramos, pero principalmente tenemos que verificar que:

1. Las CPU’s estén trabajando sin rebasar el 80% de su capacidad.

2. Que el Load Average no sobrepase la carga máxima por Cores

3. Que la memoria RAM no sobrepase el 80% de espacio ocupado

4. Que la partición / no se quede sin espacio

5. Que responda a ping

6. Que el/los SR’s no se queden sin espacio

Si queremos ampliar la información de nuestra monitorización también podemos monitorizar:

7. Que la XAPI responda correctamente

8. Que no haya máquinas virtuales apagadas

9. Heartbeat

Los 5 primeros checks, se puede implementar directamente con los nagios plugins disponibles desde: http://sourceforge.net/projects/nagiosplug/files/nagiosplug/

Estos plugins hay que compilarlos primero. A modo de facilitar las cosas. Podéis descargaros desde mi github el paquete de plugins compilados. Funcionan tanto en XenServer 5.5 como XenServer 5.6 SP2 y XenServer 6.0. https://github.com/fsmsystems/stuff el paquete nagios_xs.tar.gz tienes que descargarlo como raw para que funcione.

Descomprimimos el fichero

[root@xensrv01]# tar –xvzf nagios_xs.tar.gz

Movemos el directorio a /usr/lib

[root@xensrv01]# mv nagios_fsm /usr/lib/nagios

Creamos el usuario Nagios

[root@xensrv01]# useradd nagios –d/usr/lib/nagios
[root@xensrv01]# chown –R nagios /usr/lib/nagios

Comprovamos que funciona ok:

[root@xensrv01]# su – nagios

[root@xensrv01]# ./plugins/check_disk /

DISK OK – free space: / 2057 MB

Ahora simplemente hay que permitir mediante claves SSH que el servidor Nagios acceda por ssh a nuestros servidores con el usuario nagios. En el howto de citrix explica muy bien como hacerlo mediante ssh-copy-id:

http://support.citrix.com/article/CTX127562

Esto es todo por hoy. Espero que te resulte útil e interesante este articulo. La semana que viene explicaré como configurar estos plugins para tu Host y con ello espero una vez más haberte ayudado en el mundo de la virtualización. 

¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, soy Ferran Serafini y hoy vengo con un tema sencillo y a la vez muy potente. Seguramente habrás visto en XenCenter que los interfaces de red te permiten configurar QoS. Vamos a ver hoy, como implementarlo en nuestro entorno de virtualización con XenServer.

El QoS (Quality of Service) nos puede ser muy útil en entornos donde tenemos grandes tráficos de red y a su vez estos, sean limitados, hayamos detectado problemas, o bien necesitamos restringir el ancho de banda sin dejar de dar servicio a ciertas máquinas virtuales, etc.

Mediante QoS, XenServer permite establecer a nivel de red qué máquinas virtuales van a estar restringidas y cuáles no.

En algoritmo de XenServer para  QoS de red, se asocia a cada dispositivo VIF (Virtual Interface), por lo tanto se aplica a cada interface de red de cada máquina virtual. De este modo es posible tener una máquina con un interfaz limitado a 300 KB/s y otro a 1000KB/s. El valor que podemos establecer es la tasa máxima de transferencia.

Desde la CLI podemos configurarlo mediante:

xe vif-param-set uuid=<uuid_vif> qos_algorithm_type=ratelimit

xe vif-param-set uuid=<uuid_vif> qos_algorithm_params:kbps=300

Esto es todo por hoy, espero como siempre, haberte aportado algo nuevo e interesante. ¿Utilizas QoS en tu entorno, si es así que política establesces, criticidad de la máquina, segmento de red, etc?

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo. Gracias.

Hola amigos, hoy vengo con una serie de buenas prácticas para mantener nuestros entornos XenServer lo más seguros posibles.

No soy ningún experto en seguridad, pero creo que lo podemos diferenciar en 3 niveles.

• Acceso a la administración
• Acceso a disco remoto
• Acceso a la red externa

Acceso a la administración (XAPI, SSH)

La XenAPI escucha por HTTP, puerto 80 es decir, texto plano y por HTTPS, puerto 443, cifrado por SSL. La interconexión entre XenCenter y XenAPI siempre se realiza por HTTPS con lo cual, nuestro acceso desde XenCenter siempre va a ser cifrado. El problema lo podemos tener en “plugins” de terceros que no implementen SSL para las peticiones hacia nuestros servidores.

Una buena práctica seria bloquear, en nuestros firewalls perimetrales, el acceso a nuestros servidores por el puerto 80 desde cualquier red y solo permitir HTTPS.

Es necesario también el acceso mediante SSH a nuestros servidores, pero solo desde la red administrativa/management. Un acceso por SSH por una contraseña insegura, expone a todo el entorno a un ataque.

Acceso a disco remoto (NFS, i-SCSI)

En el caso que estés utilizando un acceso a disco remoto vía ISCSI o NFS, es muy importante el aislamiento mediante interfaces dedicadas al propio storage. De este modo nunca expondremos el tráfico de disco (texto plano) a ninguna red de acceso.

Si usas NFS, los ficheros VHD de tu repositorio, están en texto plano así que sobretodo es importante que solo tengan acceso a estos recursos los servidores XenServer y administradores.

En el caso ISCSI, si tu cabina soporta CHAP para autentificar el “target” remoto, es la mejor opción. En ese caso solo van a tener acceso a esta LUN los servidores autentificados y asignados.

Acceso a la red externa

A menos que sea necesario, una máquina virtual no tiene por qué tener acceso a la red de administración del entorno XenServer.

Es una buena práctica establecer una interface física aislada para la administración y otra para hacerle llegar las demás redes (servicio) con el tráfico “taggeado” a nivel de switch. De este modo para la red de servicio, podemos crear un bridge por cada una de las vlans, aislando así cada uno de los entornos.

Eso es todo por hoy. Espero como siempre haberte aportado un nuevo granito de arena del mundo de la virtualización ¿Cómo securizas tu entorno XenServer?

Hola amigo, hoy vamos a ver un repaso de las posibilidades disponibles de almacenamiento que tenemos para Citrix XenServer.

Veremos sus pros y sus contras para determinar cual puede ser nuestra mejor opción.

Las opciones que tenemos para un SR son:

Veamos las propiedades de cada una de estas tecnologías.

Local Storage: Por defecto XenServer utiliza los discos locales para poder almacenar máquinas virtuales. Utiliza LVM implementando el formato VHD para los VDIs. VHD permite que los discos sean sparse y que el espacio se vaya reservando en función del crecimiento de los discos de las máquinas virtuales. En las versiones 5.6  y 6.0 se implementa también thin provisioning, para el uso de escritorios vdi con XenDesktop. Fundamentalmente la ventaja principal es que según el Host físico y el tipo de disco, ofrecen un rendimiento superior, sobretodo si se usa discos en estado sólido. El problema es que no pueden ser compartidos como recurso de cluster y las máquinas virtuales instaladas en un disco de un host en local, no serán accesibles por los otros hosts del Pool.

Rápido y optimización de espacio. Pero no puede ser compartido por otros hosts.

NFS: XenServer soporta NFS3 por TCP/IP y permite crear SRs implementando VHD por lo tanto también son óptimos en cuanto a la optimización de espacio. A diferencia del disco local NFS es montado como recurso compartido del Pool y cualquier host puede acceder los VDIs almacenados en este tipo de recurso. Lo bueno también del NFS es lo estándar que es en el mundo UNIX/Linux, que por lo tanto hay multitud de appliances que permiten su gestión simplificada y no hace falta obligatoriamente disponer de una cabina de discos para trabajar en un entorno cluster.

Optimiza el espacio de disco “sparse”, gestión simplificada. Hay que vigilar que no sobrepase el espacio que hemos asignado, pues las VM crecen.

iSCSI: La utilización de iSCSI en XenServer permite  una implementación de los discos compartidos muy eficiente a nivel de red a bajo coste. Para ello hemos de configurar nuestra cabina de disco para presentar las LUNs que posteriormente se utilizaran como SRs. Una vez configurado se presenta al sistema como LVM donde los diferentes VIDs tendran un volumen lógico asociado. Los VDIs no pueden ser “sparse” y siempre ocuparan el espacio que hayamos definido en la creación del disco. Parecido a los discos tick de VMware.

Muy óptimo a nivel de red y por lo tanto muy buen rendimiento de disco para las máquinas virtuales. Se desaprovecha espacio al no ser discos dinámicos y a su vez ofrece mejor control del disco usado/libre.

Fibre Channel: Funciona en XenServer de forma parecida que iSCSI y disco local,  los discos son VHD corriendo sobre volúmenes lógicos LVM. Hay que disponer de HBAs compatibles con XenServer como Qlogic, Emulex, etc.

Alto rendimiento y optimización de espacio. Hay que tener HBAs compatibles con XenServer.

StorageLink: Sin duda la mejor opción si dispones de un licenciamiento Enterprise o Premium y tu cabina es Citrix Ready o si usas NexentaStor como appliance. StorageLink se define como la capa de interoperabilidad nativa entre XenServer y nuestra cabina de discos. Por lo tanto nos permite realizar clones súper rápidos, snapshots, thin provisioning en la propia cabina desde XenCenter.

Pensado como la solución más avanzada, es la mejor opción si necesitas un entorno de muchas máquinas y funcionalidades extra más allá del alojamiento de VDIs

Conclusiones: Principalmente, en mi modesta opinión, depende del presupuesto destinado y a la dimensión del entorno. Si estas usando una infraestructura de 4-6 nodos con unas 40 VM, un storage iSCSI contra una cabina de discos, funciona perfectamente. Si tienes de 2-3 servidores y no tienes cabina de discos, con una buena maquina sirviendo NFS funcionaría perfectamente. Y si tienes de 50 a 100 Hosts, con XenDesktop, muchos templates y una buena cabina, sin duda StorageLink.

¿Qué tecnología de almacenamiento utilizas en tus entornos?

Eso es todo por hoy amigo, espero como siempre que haya podido aportarte un granito de arena a tus conocimientos sobre la virtualización de servidores con XenServer.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Hola, amigos soy Ferran Serafini y hoy vamos a montar un entorno Citrix XenServer con almacenamiento compartido con FreeNAS.

Como sabéis aparte de FreeNAS hay muchos appliances destinados a ofrecer almacenamiento compartido de forma fácil, pero por su robustez y fácil configuración, he elegido FreeNAS, es muy útil para montar entornos de desarrollo o bien por si no podemos optar a una cabina de discos por presupuesto, en tiempo récord.

También permite la exportación a través de NFS o CIFS, pero en este caso vamos a presentar los discos mediante el protocolo ISCSI.

Primero de todo, nos descargamos la iso de FreeNAS en aquí. La arrancamos en modo (live) y la instalamos. Es muy sencillo. Podemos ver los pasos de la instalación aquí

Ahora es el momento de acceder a su página de administración

Vamos a configurar una LUN para ser servida a través de ISCSI para luego añadirla a nuestros servidores XenServer en 7 pasos.

1. Configuración Base
2. Extender Dispositivo (“LUN”)
3. Configurar Iniciador
4. Configurar Portal
5. Configurar Destinos
6. Destino / Disco
7. Iniciar ISCSI

Configuración Base

Primeramente configuramos el Nombre Base en la parte global de la configuración de ISCSI.

Nombre Base -> iqn.2011-03.fsmlab.org.istgt

Extender Dispositivo (“LUN”)

Configuramos el disco que vamos a servir como LUN en Extender Dispositivo

Configurar Iniciador

Ahora configuramos el inciador, vamos a permitir acceso para todos.

Configurar Portal

Para permitir el acceso a una IP o bien a cualquier IP del servidor FreeNAS hay que definir como mínimo un portal. Por defecto:

Portal -> 0.0.0.0:3260

Configurar Destinos

Para poder servir esta LUN, tenemos que definir que destinos vamos a presentar dicha LUN. Configuramos el destino con el/los IQN de nuestros XenServer:

Para ver el IQN de un servidor hacemos:

cat /etc/iscsi/initiatorname.iscsi

Disco/Destino

Tenemos que establecer la relación entre el destino y el disco (Extensión).

Iniciar ISCSI

Ahora ya solo falta arrancar el servicio desde Servicios-> Control de Servicios -> ISCSI = ON

Ya tenemos la parte de disco compartido finalizada, solamente hay que añadir esta LUN a nuestro Pool.

Pues esto es todo por hoy, espero como siempre que te haya parecido interesante y haberte podido ayudar en tus pasos por el mundo de la virtualización. Un saludo

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Gracias por el apoyo.

Hola amigos, esta semana veremos en nuestra sección de Citrix XenServer como actuar en caso de caída de uno de nuestros hosts físicos y recuperar el estado normal de nuestras máquinas virtuales.

El entorno al que se puede aplicar este procedimiento es un pool clásico de dos o más hosts donde tenemos corriendo nuestras máquinas virtuales sobre un almacenamiento compartido y con un licenciamiento gratuito.

Como todo fallo, antes de actuar hemos de detectar la fuente del problema y el  alcance/impacto para poder tomar las medidas necesarias para solucionarlo. Podemos evaluar la situación de un entorno XenServer caído mediante el siguiente esquema, similar al que nos plantea Citrix:

El master del pool está caído

Es  la situación más grave, veréis que se pierde totalmente el control del Pool. No se pueden listar ni realizar operaciones sobre las máquinas virtuales, se desconecta el XenCenter…  De todos modos, las máquinas virtuales siguen corriendo con normalidad en todos los Hosts, excepto las del servidor/es afectado/s.

El host con el rol de master es el que gestiona la base de datos del pool. En el momento que el master no es accesible, todos los demás hosts pierden el acceso a dicha información y asumen que están corriendo en modo de emergencia.

Desgraciadamente, no siempre cambia a ese modo automáticamente y cuando haces una consulta a la XAPI, se queda esperando si hacer nada, sin dar el error de que se encuentra en estado de emergencia.

“En mi laboratorio de pruebas, no se ha cambiado a modo de emergencia ningún host al dar botonazo al host master”. De todos modos, tanto si el siguiente comando nos devuelve “true” como “false”, procederemos igual.

#xe host-is-in-emergency-mode

Si el Host que teníamos como Master no es posible que vuelva a funcionar de nuevo, por ejemplo por un fallo de hardware, hay que transferir el rol de master a otro miembro del pool. Para ello ejecutamos el siguiente comando en un host que esté funcionando correctamente.

[root@xsrv03]# xe pool-emergency-transition-to-master

Host agent will restart and transition to master in 10 seconds…

Ahora si ejecutamos por ejemplo:

[root@xsrv03]# xe host-list

Ya veremos que la XAPI nos devuelve los hosts del pool. Ya tenemos control sobre el pool. Verificamos que el host que le hemos traspasado el rol de master, lo ha asumido correctamente:

[root@xsrv03]# xe pool-list

uuid ( RO)                : f9e97ade-85db-0191-403a-b56b93d364c7

name-label ( RW): PRODXEN

name-description ( RW): .: Production Cluster :.

master ( RO): cede8d8c-c750-4067-a6b9-eb55744e44fc

default-SR ( RW): e6532b42-d048-2ef4-9b6c-688632108e34

[root@xsrv03]#  xe host-list uuid=cede8d8c-c750-4067-a6b9-eb55744e44fc

name-label ( RW): xsrv03

Una vez recuperado el control del pool, tenemos que forzar al nuevo master a restablecer las conexiones con el resto de hosts. Este comando nos devolverá el listado de UUIDs de los hosts slaves que contiene el pool.

[root@r xsrv03]# xe pool-recover-slaves

e212ac38-c349-490a-9902-06b9355700cd

Ahora el pool puede volver a trabajar con normalidad, si disponemos de N+1, solamente  tendremos que levantar las VMs caídas en del host “master” en los otros hosts disponibles. Si las máquinas virtuales no se dejan volver arrancar porqué según la XAPI están corriendo sobre el host caído, sigue leyendo

A partir de aquí el resto de situaciones de caídas de Host, son menos aparatosas. Si detectamos un host caído y no podemos volver a levantar las máquinas virtuales en otro Host, tenemos el comando:

#xe vm-reset-powerstate vm=<NameLabel de la VM> force=true

Este comando avanzado forzará el estado de apagado la máquina virtual que especifiquemos. Pero ojo, solo ejecútalo si estas 100% seguro que esta máquina virtual no está corriendo en ningún otro host ya que este, libera el bloqueo que establece XenServer a nivel de base de datos, para que no se pueda levantar la VM en cualquier otro host del pool por duplicado. En ese caso, tendríamos corrupción de discos en la máquina virtual. Como es un comando “peligroso” hay que ejecutarlo siempre con el flag force=true o –force

Tenemos también la opción para un host en concreto:

#xe vm-reset-powerstate resident-on=<UUID Host caido> force=true

Hasta aquí por hoy, espero que como siempre, haya podido enseñarte algo útil para administrar tu entorno XenServer.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Hola amigos, hoy veremos en nuestra sección de Citrix XenServer, como funcionan los Pools y como gestionarlos mediante CLI.

Un Pool se define como dos o más maquinas Citrix XenServer que componen una misma entidad, de modo que pueden compartir recursos como máquinas virtuales, almacenamiento, etc. de forma centralizada.

Cuando se usa un Pool con almacenamiento compartido las máquinas virtuales se pueden mover en caliente (XenMotions) entre los hosts que componen el Pool, compartir templates, repositorios de ISOS, SR’s… Aporta también una agregación de recursos ya que si un Host ya no puede asumir más carga de maquinas virtuales, la  siguiente máquina virtual, será levantada en otro Host.

Esta Entidad es capaz de gestionar todas las máquinas virtuales en  conjunto indepen-dientemente de donde estén corriendo, es decir que en caso de caída de un host físico, las maquinas virtuales se pueden volver arrancar en otro host, siempre que tengamos almacena-miento compartido.

Veremos más adelante que si el Host caído es el denominado Master del pool, tendremos un problema un poco más serio.

Requisitos para crear un pool

1. Los hosts tienen que ser homogéneos, no se pueden mezclar CPUs AMD con CPUs INTEL.
2. Las CPUs tienen que ser del mismo modelo y soportar los mismos flags. Hay trucos para romper esta regla, pero no es recomendable de ningún modo, excepto en el caso que sea el flag “stepping”.
3. Tener una IP estática.
4. No ser miembro de otro pool, ni tener almacenamiento compartido.
5. Relojes sincronizados por NTP.

Integrando un Host a nuestro Pool por CLI

Entramos en la máquina que queremos añadir al Pool y ejecutamos:

#xe pool-join master-address=IP_Servidor_master master-username=root master-password=password.

Si ejecutamos xe pool-list veremos las propiedades básicas de nuestro pool:

# xe pool-list

• uuid ( RO) :  UUID del Pool
• name-label ( RW): nombre del Pool
• name-description ( RW):  Descripción (si hemos puesto alguna)
• master ( RO): UUID del host que esta designado como Master
• default-SR ( RW): El SR por defecto del Pool

Ahora ya podemos migrar nuestras maquinas entre hosts mediante xe vm-migrate:

#xe vm-migrate vm=Nombre de la VM host=Nombre del Host live=true

Quitando un Host de nuestro Pool

Tal vez nos interese quitar un Host del Pool, para ello podemos utilizar el siguiente comando:

# xe pool-eject host-uuid=UUID del host

Con esto me despido hasta la semana que viene, donde veremos cómo solucionar problemas relacionados con los pools ante caídas de hosts, cómo mover los roles de master y otras opciones para que cada día te sientas mejor usando Citrix XenServer.

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Gracias por el apoyo.

Esta semana, en nuestra sección de Citrix XenServer, veremos más trucos sobre la gestión de discos que ya empezamos la semana pasada. Espero que, como siempre, te resulte interesante.

VBDs a fondo

Vimos que Citrix XenServer es capaz de abstaer el sistema físico de almacenamiento ya sea, SAN, I-SCSI, Storage Link, NFS, etc. De manera que las máquinas virtuales siempre tendrán asociados VBDs y estos hacen de “enlace” con nuestros discos virtuales VDIs.

Eso es muy importante ya que por ejemplo el core de Citrix XenServer utiliza aplicaciones como Pygrub, un grub hecho en python para arrancar los domU (máquinas virtuales) con su propio Kernel. Este, necesita parametros para saber que disco tiene que utilizar para arrancar el sistema. Este parámetro en cuestión es el parámetro “bootable”.

Es común el error: “No bootable device.” Cuando por ejemplo borramos un snapshot que tenia ese parámetro puesto automáticamente.

Sabiendo cual de los VBD->VDI contiene el Kernel de nuestra máquina virtual, simplemente tendríamos que establecer dicho VDB como “bootable” para que el domU arrancara sin problemas:

#xe vbd-param-set uuid=<UUID VBD> bootable=true

Tambien el VDB establece que tipo de disco se presenta (CDRom/Disk), modo (lectura/escritura), dispositivo de la maquina virtual (xvda/ hda) y un largo etc. Os invito a que veais los diferentes parametros en una máquina virtual vuestra con:

# xe vbd-list vm-name-label=<Nombre VM> params=all

Los VBDs tienen tambien comandos extra de gestión como:

• vbd-eject/vbd-insert: Expulsa/inserta un VDI
• vbd-plug/vbd-unplug: Conecta/desconecta un VBD
• xe vbd-create: Como parametro los siguientes flags -> bootable=     device=       mode=         type=         unpluggable=  vdi-uuid=     vm-uuid=
• vbd-destroy: Elimina un VBD por UUID

No olvidemos que el principal objetivo del VBD es el enlace con el VDI. Así que ya podemos saber que VDIs tiene una máquina virtual mediante:

# xe vbd-list vm-name-label=<Nombre VM> params=vdi-name-label

VDIs a fondo

Existen tres típos en función del típo de SR (Storage Repository) que tengamos montado:

• File based VHD: Utiliza thin provisioning y no soporta almacenamiento compartido, solamente es posible usar este típo en SRs de discos locales EXT  o como recurso SR por NFS.

• LVM: La opcón predeterminada de Xenserver. Puede ser por SAN, I-SCSI o SAS. Básicamente los VDIs son representados como volumenes LVM.

• LUN por VDI: Mapeo directo de Luns contra una máquina virtual. Para eso es necesario usar pluguins especificos (NetApp, EqualLogic o StorageLink)

Podemos ver todos los parametros del VDI con:

#xe vdi-list uuid=<UUID-VDI> params=all

También tienen un montón de opciones, espacio virtual, utilización física, sr donde está alojado el vdi, y un largo etc.

Algunos comandos extra para las gestión de VDIs

• vdi-clone: Clona el VDI y lo almacena con un nuevo UUID, nuevo nombre, etc. En el mismo SR
• vdi-copy: Copia el VDI en otro SR
• vdi-import: Importa un VDI desde un fichero exportado con vm-export
• vdi-resize: Reasigna el espacio virtual del disco

Con esto, me despido por hoy, espero que haya podido enseñarte algo nuevo sobre la gestión de discos y como funcionan en XenServer y animarte a que lo veas con tus propias máquinas virtuales.

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Gracias por el apoyo.

Hola amigos. Soy Ferran Serafini y aquí vuelvo hoy como cada miércoles para aprender algo nuevo sobre Citrix XenServer.

La semana pasada Citrix presentó la nueva versión oficial de XenServer 6. Hace unos meses ya vimos las novedades que incluía ya en su versión beta 2. Os dejo un video tutorial en el que podréis ver la instalación de XenServer 6 paso a paso y las novedades más relevantes que escribió nuestro compañero Adolfo Muñoz, aquí

Hoy vamos a ver cómo funcionan los discos en XenServer. Veremos primeramente un poco de teoría para entender como XAPI abstrae y presenta los recursos de discos a nuestras máquinas virtuales.

En XenServer los discos desde la maquina virtual hasta el Host tienen el siguiente conjunto de clases. Esta “jerarquía” viene dada por la XAPI:

VDI: (Imagen de Disco Virtual) Un objeto VDI es la representación de un disco virtual. Los VDIs tienen la propiedad de poderse redimensionar y clonar.

VDB: (Dispositivo de bloque virtual) Este objeto representa la unión entre una máquina virtual y un VDI. Cuando una máquina virtual inicia,  primeramente se consulta sus objetos VBD para determinar que discos virtuales VDIs tiene asociados.  Los métodos de la clase VBD permiten la conexión y desconexión en caliente de un dispositivo de disco VDI.

SR: (Repositorio de almacenamiento) Es el contenedor donde residen los VDIs encapsulando las propiedades de un almacenamiento físico.

PBD: (dispositivo de bloque físico) Representa la unión entre el host físico y un objeto SR. Este presenta una capa de abstracción física del modo en que se conecta físicamente el disco, NFS, I-scsi, etc a los objetos SR.

Sabiendo esto, para consultar que discos tiene una maquina virtual, ya sabemos que no hemos de ir a buscar un VDI directamente (como nos presenta XenCenter). Es importante ya que los que estéis muy acostumbrados al XenCenter podéis pensar que la maquina virtual va conectada directamente al VDI, y como habéis visto, no es así, la maquina virtual tiene conectados los VDB.

Por lo tanto para consultar que discos tiene una maquina virtual utilizaremos el comando:

# xe vbd-list vm-name-label=Nombre VM

Un ejemplo:

# xe vbd-list vm-name-label=vMachine01

uuid ( RO)             : ad2519f4-1764-8c57-5a2c-614b812aefc7

vm-uuid ( RO): 8b0a9e82-064c-ecae-4e46-b8b50d6d6974

vm-name-label ( RO): vMachine01

vdi-uuid ( RO): f28ab1b1-e6f4-453f-8d1a-73cbb5c26d14

empty ( RO): false

device ( RO): xvdb

uuid ( RO)             : 6ac1c235-8c1e-7af5-e272-9cc4865e0e90

vm-uuid ( RO): 8b0a9e82-064c-ecae-4e46-b8b50d6d6974

vm-name-label ( RO): vMachine01

vdi-uuid ( RO): 8b0a9e82-064c-ecae-4e46-b8b50d6d6974

empty ( RO): false

device ( RO): xvda

Vemos aquí que nuestra maquina virtual vMachine01 tiene dos VDIs conectados, identificados por vdi-uuid: f28ab1b1-e6f4-453f-8d1a-73cbb5c26d14 i 8b0a9e82-064c-ecae-4e46-b8b50d6d6974

Bueno amigo, esto es todo por hoy. Te espero la semana que viene con más trucos y explicaciones para tener bien controlados tus entornos Citrix XenServer.

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Gracias por el apoyo.