Welcome to Delicate template
Header
Just another WordPress site
Header

Existe un método rápido para localizar el Master de un Pool de XenServer?

De echo, existen, como mínimo, tres métodos para ello.

Vamos a empezar, del mas difícil, pero mas «molón» al mas sencillo.

Método 1: Using CLI: XE commands

xe pool-list params=uuid,master

Ello nos mostrara la lista de host, con su UUID y el UUID del Master. Tras ello, ejecutamos:

xe host-list uuid=UUID_Master

Substituimos UUID_Master, con el UUID suministrado el anterior comando. Ello nos mostrara el host master del actual pool de XenServer.

Método 2: Using CLI: Cat file

El servidor master actual se almacena en un fichero dentro de los host de XenServer. Este es llamado Pool.conf. Así que un sencillo «cat» sobre el fichero, nos mostrará el nombre del Master del Pool de XenServer

cat /etc/xensource/pool.conf

Método 3: Using XenCenter

El método mas sencillo. El primer host aparecido, bajo el nombre del Pool de XenServer… es el servidor maestro de XenServer.

Pues eso es todo, ¿se os ocurre algún método mas?

 

XenServer permite el “tunning” del Dom0 de cara a mejorar la escalabilidad del entorno cuando es necesario, poniendo de este modo el rendimiento de nuestro hypervisor al máximo.

Cabe indicar, que no siempre estas recomendaciones son aplicables y que habrá que ver cada entorno, para saber si es o no es aplicable. De echo, normalmente estas recomendaciones no serán aplicables ya que la configuración por defecto de XenServer es en la mayoría de casos suficiente.

Pero si tenéis problemas de rendimiento a pesar de tener suficiente CPU y memoria, ello puede estar ocasionado por un cuello de botella es nuestro dominio de control y los siguientes ajustes podrían solventar en algunos casos dicha perdida de rendimiento.

Cuando un host XenServer arranca, el hypervisor carga una pequeña VM invisible para los usuarios; incluso para los administradores en algunos casos. Esta VM es conocida como Dominio de Control o Dom0.  Dom0 se ejecuta en la pila de gestión y proporciona servicios básicos al resto de las VMs, como el acceso físico a los dispositivos.

No existe un número determinado de VMs en las cuales podamos asegurar que la vcpu0 de dom0 se colapse, ocasionando un cuello de botella. Dependerá también en gran medida del tipo de VMs que estemos rodando, pudiendo ser necesario realizar cambios en dom0 a partir de 60-70 vms o no siendo necesario realizar incluso con 100 vms rodando. Por ello, es importante no tener una referencia numérica en este aspecto, y revisar los contadores y el estado de nuestro Dom0 para asegurar un correcto tunning. En el 99% de los casos, no serán necesarias modificaciones en Dom0.

Si durante el uso de nuestro host, observamos problemas de rendimiento, y mediante xentop comprobamos un uso excesivo (llegando al 100% constante) de recursos, se recomienda, en estos casos, el tuning de dom0, ampliando memoria o asignando vcpus, según corresponda.

Ya hemos hablado de ampliar el número de vcpus de nuestro dominio de control, pero también la memoria se puede ver afectada en estos problemas de cuello de botella. Sobretodo en entornos con mas de 50 Vms corriendo por host. En estos, se recomienda la ampliación de memoria hasta 2’96GiB, y decimos 2’96GB y no 4 ya que mas de 2’96GiB queda fuera de soporte, además de ser arriesgado.

Si quieres saber mas, continua leyendo aquí

Veamos la versión actual de python en XS6.2

[root@xenserver62 ~]# python -V

Python 2.4.3

Vamos a utilizar YUM en primer momento, para instalar todos los paquetes necesarios para la instalación de Python3.

NOTA: Si al realizar un yum update aparece un error referente al repositorio de Citrix 6.2

* Deshabilitar el repositorio Citrix.Repo

* Habilitar el repositorio CentOS-base Repo

Sobre esto hable hace tiempo en el siguiente link: http://blogs.itpro.es/cristiansan/2012/05/23/xenserver-trick-linux-repository/

Instalando Requerimientos

Habilitados los repositorios. Procedemos a instalar Make y el compilador GCC.

Install Make.

# sudo yum install make

Install GCC

# sudo yum install gcc

Descargamos e instalamos Python3

Para ello, desde nuestra linea de comandos, ejecutamos:

wget http://www.python.org/ftp/python/3.3.2/Python-3.3.2.tgz

tar xf Python-3.3.2.tgz

cd Python-3.3.2/

./configure –prefix=/usr/local

make && make altinstall

ahora ya podemos ejecutar python3.3 sin problemas.

[root@xenserver62 bin]# python3.3
Python 3.3.2 (default, Jul 10 2013, 16:22:51)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux
Type «help», «copyright», «credits» or «license» for more information.
>>>

NOTA: Si ejecutamos python seguimos en versión 2.4.3

NOTA: No se recomienda el cambio del link symbolico, pues muchos programas realizados en Python apuntan a «python» como enlace de Python2. Modificar-lo puede suponer un problema para scripts que necesiten de python2.

TRICK: Para simpliciar las cosas, podemos crear un link simbólico “py” para ejecutar python3.

 # ln /usr/local/bin/python3.3 /usr/bin/py

De este modo, al ejecutar py, estaremos ejecutando python 3.3

[root@xenserver62 bin]# py -V
Python 3.3.2
[root@xenserver62 bin]# py
Python 3.3.2 (default, Jul 10 2013, 16:22:51)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux
Type «help», «copyright», «credits» or «license» for more information.
>>>

Y con esto, y un biscocho,  ya tenemos Python 3 en nuestro querido XenServer 6.2. 😉

Hace poco conocí  “GeekTool”, una herramienta que viene a ser un conky para OSX.

De echo, hacia tiempo que buscaba una herramienta de este tipo, pues algo que me gustaba de mis escritorios Linux era poder monitorizar mi maquina entre otras tareas y mostrar dicha información en tiempo real en mi escritorio, sin necesidad de utilizar consolas adicionales.

Así pues, descubierto este, nos pusimos manos a la obra, instalamos GeekTool y utilizamos unos .glets desarrollados por la comunidad y realizamos modificaciones en otros para disponer de un wallpaper con vida que nos muestra datos interesantes en pantalla.

Inicialmente, incluí un bonito reloj, un resumen de uso del sistema y el top de procesos por consumo de memoria/cpu en mi sistema OSX.

Reloj

Si buscáis en google por GeekTool, veréis escritorios que son autenticas maravillas. De echo, este no es el fondo del artículo.

Posteriormente, añadí  un lector RSS para detectar nuevos artículos de algunos de mis blogs, y de aquí y haciendo pruebas empezarón a surgir dudas… ¿podre utilizar esto para monitorizar mis hypervisores y mostrar la inforamción en pantalla?

Rss

Como algunos saben, tengo debilidad por XenServer, así que mi objetivo de monitorización, en cuanto a hypervisor, era claro; aunque con un poco de mañana, el resto de hypervisores seguro que tambien encajarán aquí.

Monitorizando XenServer vía GeekTool

Aquí es dónde viene lo divertido. Echas las primeras pruebas, el objetivo era poder ver datos de mi XenServer  que utilizo como laboratorio en casa.

Y como podemos hacer esto… … … … tras unos minutos de estruje neuronal…. ¿Por qué no usar SSH? Probemos.

Realizar un NAT en nuestro router para redirigir el tráfico SSH de la IP Publicahacia mi IP interna de XenServer.

Por supuesto, es importante, probar que funciona correctamente el acceso 😉

ALARM:  Es momento de solucionar un posible dolor de cabeza.

Sabemos que para abrir una conexión SSH, deberemos realizar:

# ssh root@IP_Publica

Ello nos solicitara la contraseña. Y este punto puede suponer un problema. Seria interesante, que nuestro host confie en nuestra máquina y posiblite la conexión con validación por key para conectar y ejecutar tareas sin necesidad de solicitar contraseña (y sin que nos obligue a incluirla en nuestros scripts).

La solución …, si no recuerdo mal, algo escribí por aquí, que podría ayudarnos…

http://blogs.itpro.es/cristiansan/2011/10/01/ssh-key-maclinux-to-xenserver-without-pass/

Solventando el problema de SSH, es necesario crear el script que queremos. Vamos a empezar con una prueba sencilla. Muy muy sencilla, no voy a explicar como funciona GeekTool (hay fabulosos manuales en internet), ni a realizar complejos scrips de monitorización para nuestro host (probablemente en futuros artículos).

El foco de este, es simplemente, enseñar que podemos hacer con un poco de imaginación…

Vamos a empezar por un comando simple: Listar las VMs y su estado y situar-las en nuestro Wallpaper.

Creando el GLET

Para mostrar un listado de VM en nuestro host de XenServer, podemos ejecutar:

# xe vm-list

Podriamos filtrar un poco mas, y mostrar solo las que esten ejecución..

# xe vm-list power-state=running

 Pero el primero nos vale…

Para ello, necesitaramos saber como ejecutar comandos de forma remota en XenServer. Utilizando SSH y la opción de autovalidación comentada anteriormente, es una opción.

# ssh root@IP_SERVER “Commands”

Una vez tengamos la línea de comando a ejecutar, podemos guardarla en un script o ejecutar-la directamente desde SSH. Mi script básico para GeekTool, es el siguiente:

udate=date +"%D %H:%M"
echo Last Update:  ${udate};
echo #
ssh root@IP_PUBLICA «xe vm-list params=name-label,power-state»

La priemra linea guarda en la variable $udate, la fecha en formato MM\DD\AA HH:MM.

Posteriormente, ecribimos la fecha en patalla precedido del texto «Last Update:» (Ello nos servira para saber cuando fue actualizada la información del host por última vez.)

Finalmente, dejamos un espació en blanco, y realizamos la conexión via SSH con nuestro host, donde ejecutamos el comando para listar las VMs de nuestro host y seleccionamos unicamente los campos de Name-Label y Estado (Power-State) para mostrar en pantalla.

Verificamos el resultado desde nuestro CLI (ejecutamos el comando desde el terminal de OSX para verificar su correcta aplicación) y echo esto, utilizamos GeekTool para configurar nuestro nuevo script de Monitorización.

Se incluye el codigo en nuestro «shell» de GeekTool y especificamos als opciones tales como fuente, color, fondo y tiempo de refresco del script (en mi caso lo estableci cada 30 min).

Echo, esto solo queda vestir-lo un poco para que quede wapo. Aquí ya entra la vena artística de cada uno… a mi no se me dan muy bien estas cosas.

Como ejemplo, os dejo una captura de esta primera versión de mi escritorio dónde podemos ver…

Fecha; Logo de CTXDOM, Logo de Apple con estado de nuestro OSX, Logo de monitorización con el top process de mi equipo, el RSS de Citrix Blogs y los logos del panda de Xen con la información mostrada por el Script escrito anteriormente y mi dirección IP publica.

Modif

¿Mola eh? … ahora os toca a vosotros… Que la fuerza os acompañe!

Resource

Página oficial GeekTool: http://projects.tynsoe.org/en/geektool/

 

En algunos entornos (laboratorios, servidores StandAlone, etc) disponer de una maquina para almacenar los repositorios ISO que compartimos en nuestro XenServer puede suponer un gasto de recursos adicionales que nos podriamos ahorrar.

En este breve artículo os enseñamos como crear vuestro propio repositorio local en XenServer que permita almacenar y utilizar ISO.

Tened en cuenta que utilizar un SR local hace que este repositorio no este disponible para el resto de host que componen un pool. Si dispones de un pool y quieres que estas ISO estén disponibles para todos los host, recuerda utilizar un recurso compartido como almacen.

Los pasos aquí indicados te ayudarán a crear un SR de ISOs Local y las propias ISO solo estarán disponibles únicamente sobre la máquina que almacena dichas imágenes.

Quieres saber como… continua leyendo aquí

Algunas veces existen quejas referentes al performance de red en entornos virtuales y su mal performance de red en relación a una maquina física. Articulos independientes muestran que el performance con xenserver, vmware e hyper-v es parecido al físico y ya no es una excusa para no virtualizar. Eso si, para ello, es necesario realizar ciertas acciones y aplicar todas las buenas practicas posibles en cada uno de los entornos siempre que sea posible.

Una de las mejoras realizables para mejorar el performance de red, es el relacionado con los paramétros de checksum y off-load (TCP Segmentation offload, Generic Segmentation offload y UDP Fragmentation Offload – Todas ellas explicadas en los recursos adicionales al final del artículo).

Para su configuración, podemos hacer uso de la herramienta ethtool-K, el cual nos permitirá realizar cambios sobre las tarjetas, sin que los cambios sean “permanentes”. Estos serán reseteados tras un reinicio.

Para ver los parámetros actuales podemos consultar-los de la siguiente forma:

ethtool –K “Interface”

Por ejemplo, podemos deshabilitar el tcp-offload de la Eth0 de la siguiente manera:

ethtool -K eth0 tso off

Para información ampliada sobre ethtool podemos consultar el manual en línea (man) de ethtool o desde http://linux.die.net/man/8/ethtool

Para establecer los cambios de forma permanente, deberemos utilizar nuestra herramienta en línea de comandos XE. Para ello, realizaremos:

xe pif-param-set uuid=<UUID of PIF> other-config:ethtool-tx=”off”

xe vif-param-set uuid=<UUID of VIF> other-config:ethtool-tso=”off”

La sintaxis genérica seria:

   xe [vif/pif]-param-set uuid=<uuid pif/vif> other-Config:KEY=”off”/”on”

dónde KEY:

ethtool-tx : TX Checksum

         ethtool-rx: RX Checksum

         ethtool-tso: Tcp Segmentation offload

ethtool-ufo:  UDP Fragmentation offload

ethtool-gso: Generic Segmentation offload

NOTA: no se recomienda la desactivación del TSO en los VIF. Las buenas practicas aconsejan desactivar la misma desde la propia VM, tal y como indica el http://support.microsoft.com/kb/904946/  y http://support.microsoft.com/kb/951037

NOTA: Ojo al aplicar en entornos productivos. Testear antes.

Resources:

TSO: http://www.linuxfoundation.org/collaborate/workgroups/networking/tso

GSO: http://www.linuxfoundation.org/collaborate/workgroups/networking/gso

UFO: http://www.linuxfoundation.org/collaborate/workgroups/networking/ufo