El Blog de la Virtualización de Servidores y del Cloud Computing en español » XenServer

Tunning de CPUs en XenServer

Ferran Serafini — Wed, 08 Feb 2012 09:10:00 +0000

Hola amigos, soy Ferran Serafini y hoy en nuestra sección de XenServer, veremos como optimizar el rendimiento de las CPUs de nuestras máquinas afinando la configuración de nuestras máquinas virtuales para que se ajusten a nuestros requerimientos.

Primeramente comentar que por defecto, XenServer divide los recursos físicos de CPU utilizando un algoritmo de equilibrio por partes iguales. Es decir que cada máquina virtual obtiene su parte de recursos de CPU de manera equitativa.

Lo que vamos hacer hoy es modificar esta configuración que viene por defecto y asignaremos a las máquinas virtuales los valores que más nos convengan.

Tenemos 3 opciones:

vCPU pinning: Esta opción otorga CPUs físicas a las vCPU de las máquinas virtuales. Podemos mapear por ejemplo las CPUs físicas 1, 2, 3 a la máquina virtual con el siguiente comando.

[root@xenserver ~]# xe vm-param-set uuid= VCPUs-params:mask=1,2,3

vCPU Priority: Ajustando este parametro modificamos el peso que tiene una máquina virtual sobre el tiempo de CPU que comparte con las otras máquinas virtuales. Por lo tanto podemos asignar más o menos tiempo de CPU en función del rendimiento que queramos asignar.

[root@xenserver ~]# xe vm-param-set uuid= VCPUs-params:weight=512

Con el comando anterior, asignamos un peso de 512 a nuestra máquina virtual. Nos va permitir que esta máquina virtual tenga el doble de tiempo de CPU de cualquier otra que tenga un peso de 256 cuando el Host XenServer tenga todos los recursos en uso. Sin duda es la forma más razonable de “tuning de CPU” ya que es la menos posesiva/agresiva.

CPU cap: Esta opción nos permite fijar la cantidad máxima de uso de CPU que puede utilizar una máquina virtual.

[root@xenserver ~]# xe vm-param-set uuid= VCPUs-params:cap=70

En este ejemplo hemos configurado nuestra máquina virtual para que solo pueda utilizar el 80% de una CPU física. Si queremos que solo pueda utilizar 4 CPUs pondríamos el valor 400.

Esta forma es útil sobre todo para máquinas de test que no queremos que nunca llegue a penalizar el rendimiento de las otras máquinas virtuales.

Con esto me despido por hoy, espero como siempre que te haya parecido interesante. 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.

Cómo enviar mails desde XenServer

Ferran Serafini — Wed, 01 Feb 2012 08:00:56 +0000

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=

rewriteDomain=

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.

Xen Cloud Plataform – XCP 1.1

Ferran Serafini — Wed, 25 Jan 2012 08:42:07 +0000

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.

¿Cómo migrar máquinas virtuales de VMware a XenServer?

Ferran Serafini — Wed, 18 Jan 2012 08:30:32 +0000

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.

¿Cómo monitorizar XenServer con Nagios?: Parte III

Ferran Serafini — Wed, 11 Jan 2012 08:30:33 +0000

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.

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= param-name=physical-size

/usr/bin/xe sr-param-get uuid= 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

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.

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.

Repasando XenServer 6.0 Technical Master Class

Ferran Serafini — Wed, 21 Dec 2011 08:30:04 +0000

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.

¿Cómo monitorizar XenServer con Nagios?: Parte II

Ferran Serafini — Wed, 14 Dec 2011 08:30:47 +0000

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.

Las CPU’s estén trabajando sin rebasar el 80% de su capacidad.
Que la memoria RAM no sobrepase el 80% de espacio ocupado.
Que la partición / no se quede sin espacio.
Que el Load Average no sobrepase la carga máxima por Cores.
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:

#!/bin/bash

CRITICAL_CPU=’95′

WARNING_CPU=’80′

#Porcentage de CPU en uso

#cpu_stat=$(sudo xentop -bi2 | grep Domain-0 | awk ‘{ print $4 }’ | tail -1 | cut -d ‘.’ -f1)

cpu_stat=’80′

#Evaluamos estado

if [ $cpu_stat -ge $CRITICAL_CPU ] ; then

echo “CRITICAL:CPU%= $cpu_stat”

exit 2

elif [ $cpu_stat -ge $WARNING_CPU ] ; then

echo “WARNING: CPU%= $cpu_stat”

exit 1

else

echo “OK:CPU%= $cpu_stat”

exit 0

fi

2.- Para la memoria:

#!/bin/bash

CRITICAL_MEM=’10′

WARNING_MEM=’20′

#Estados de memoria libre y total

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

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

#Calculo del porcentage

percent_libre=$(echo “scale=2; ($mem_free / $mem_total)*100 ” | bc | cut -d”.” -f1)

#Evaluamos estado

if [ $percent_libre -lt $CRITICAL_MEM ] ; then

echo “CRITICAL:MEM%=$percent_libre”

exit 2

elif [ $percent_libre -lt $WARNING_MEM ] ; then

echo “WARNING:MEM%=$percent_libre”

exit 1

else

echo “OK:MEM%=$percent_libre”

exit 0

fi

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

define command{

command_name check_by_ssh_disk

command_line $USER1$/check_by_ssh -t 20 -H $HOSTADDRESS$ -C “/usr/lib/nagios/plugins/check_disk -w $ARG1$ -c $ARG2$ $ARG3$”

}

Definimos el servicio

define service{

use                             generic-service

hostgroup_name                  xen

service_description             Estado disco /

is_volatile                     0

check_period                    24×7

max_check_attempts              3

normal_check_interval           5

retry_check_interval            1

contact_groups                  admins

notification_interval           120

notification_period             24×7

notification_options            w,u,c,r

check_command                   check_by_ssh_disk!10%!5%!/

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

define command{

command_name check_by_ssh_load

command_line $USER1$/check_by_ssh -t 20 -H $HOSTADDRESS$ -C “/usr/lib/nagios/plugins/check_load -w $ARG1$ -c $ARG2$”

}

define service{

use                             generic-service

hostgroup_name                  xen

service_description             Load

is_volatile                     0

check_period                    24×7

max_check_attempts              3

normal_check_interval           5

retry_check_interval            1

contact_groups                  admins

notification_interval           120

notification_period             24×7

notification_options            w,u,c,r

check_command                   check_by_ssh_load!15,10,5!30,25,20!

}

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.

¿Cómo monitorizar Citrix XenServer con Nagios?

Ferran Serafini — Wed, 07 Dec 2011 08:30:10 +0000

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:

Hosts (Dom0)
Storage
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:

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

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

Que la XAPI responda correctamente
Que no haya máquinas virtuales apagadas
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.

QoS en Citrix XenServer

Ferran Serafini — Wed, 30 Nov 2011 08:16:45 +0000

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= qos_algorithm_type=ratelimit

xe vif-param-set uuid= 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.

Seguridad en XenServer

Ferran Serafini — Wed, 23 Nov 2011 08:30:20 +0000

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?