Hola queridos lectores, hoy en nuestra sección de XenServer veremos cómo acceder a la consola principal de nuestras máquinas virtuales GNU/Linux, sin necesidad de utilizar XenCenter o VNC.

Una forma común para acceder a la consola de los DomU en Xen, es mediante la consola terminal directa de la máquina, es por así decir la tty0 de una máquina virtual GNU/Linux. Esta consola es puramente de texto y solo funciona en máquinas virtuales GNU/Linux para-virtualizadas.

Es muy útil en caso de problemas. Para utilizarla, nos conectamos a nuestro Host (Dom0) por ssh y ejecutamos:

Este comando nos devolverá el dom-id de la máquina virtual, necesario para conectarnos a la consola.

Verificamos que este DomU está en este host que nos hemos conectado

Vemos que en este Host tenemos corriendo el dom-id 1, si no fuera así, podemos ver en que host está corriendo la máquina virtual con:

xe vm-list name-label=>Máquina Virtual> params=resident-on

xe host-list uuid=26196fe8-c0ce-49c0-a88f-559cce3e3a52 params=name-label

Nos conectamos a la consola:

Veremos que nos aparece la pantalla de login típica de GNU/Linux.

Con esto me despido por hoy, espero como siempre que te haya parecido interesante y haberte ayudado en tu día a día con XenServer. 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 queridos lectores, hoy en nuestra sección de XenServer vamos a ver una forma de utilizar RDM (Raw Device Mapping) en XenServer sin utilizar Advanced Storage Link.

Para los que también usamos VMware, en XenServer se echa de menos la opción de presentar una LUN de disco a una máquina virtual en concreto, lo que en terminología VMware se denomina RDM. Yo personalmente siempre prefiero utilizar discos pequeños (VDI) para las máquinas virtuales (Sistema Operativo) y para grandes volúmenes, por ejemplo +100GB, presentar por RDM.

La forma que os presento hoy es válida sólo para los que utilizáis ISCSI en vuestro entorno, o para los que tengáis esta opción independientemente si los SR los tenéis presentados por HBA.

Durante este y próximos posts, veremos como configurar nuestro entorno ISCSI para tenerlo mínimamente securizado y 100% funcional.

Básicamente consiste en presentar a la máquina virtual un interfaz de la red iscsi y desde la cabina de discos, asignar directamente la/s LUN/s a la máquina virtual.

La mayoría de sistemas operativos ya disponen de soporte para iscsi, de modo que no es complicado presentar estas LUNs directamente a la máquina virtual. Por ejemplo en GNU/Linux podemos configurar el cliente iscsi siguiendo estos pasos:

Instalamos open-iscsi:

aptitude install open-iscsi

Descubrimos los targets que dispone la cabina:

iscsiadm -m discovery -t sendtargets -p 192.168.15.129
192.168.15.129:3260,1 iqn.2008-07.es.ubuntest1:hardy64-mini-iso
192.168.15.129:3260,1 iqn.2008-07.es.ubuntest1:sda
192.168.15.129:3260,1 iqn.2008-07.es.ubuntest1:sdb

Login a un target

iscsiadm -m node -l -T “iqn.2008-07.es.ubuntest1:sda” -p 192.168.15.129

Autoconfiguramos el login al arrancar el servicio open-iscsi

iscsiadm -m node -T “iqn.2008-07.es.ubuntest1:sda” -p 192.168.15.129 -o update -n node.conn[0].startup -v automatic /etc/init.d/open-iscsi restart

Con esto, me despido por hoy espero que te haya parecido interesante y que haya podido ayudarte en tu día a día con XenServer. 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, ¿Cómo estamos? Hoy en nuestra sección de XenServer vamos a ver un tutorial para instalar XenCloud Plataform 1.1 en una máquina virtual VirtualBox.

Aunque este Domain0 será una máquina virtual, nos va permitir realizar pruebas a modo de laboratorio para nuestros entornos. Gracias a esta técnica podemos virtualizar pequeños Pools de máquinas para hacer todo tipo de pruebas en low cost.

¿Que necesitamos?

• Una máquina con procesadores de 64 bits
• VirtualBox (tanto para Windows como GNU/Linux)
• La ISO de XCP la podemos descargar desde http://xen.org/download/xcp

Creamos nuestra máquina virtual:

1. NEW-> NAME (xcp01) ->OS TYPE (Linux) -> Version (RedHat 64-bit)
2. Seleccionamos 2 GB de RAM
3. Creamos un Nuevo disco VDI dinámico de 20 GB
4. Create
5. Editamos los parámetros (Settings)
6. Ponemos al adaptador de red en modo bridged
7. Añandimos la iso de XCP en Storage IDE Controller
8. Arrancamos nuestro xcp virtual

Seguimos el asistente de instalación de XCP, seleccionemos el keymap, aceptamos la licencia, etc.

Nos va aparecer el Error de System Hardware debido a que VirtualBox no le esta presentando las extensiones VT de virtualización (aunque estén marcadas) a nuestra máquina virtual, por lo tanto no podremos virtualizar Windows o máquinas en HVM. Aceptamos y continuamos con el asistente.

En el paso Virtual Machine Storage, seleccionamos el disco de 20 GB y activamos el thin provisioning. Posteriormente, configuramos el password de root, la red, dns, zona horaria, ntp, etc.. Instalamos.

En unos pocos minutos ya tendremos nuestro xcp totalmente operativo y listo para hacer todo tipo de pruebas.

Con esto, me despido por hoy, espero como siempre, haber podido ayudarte en tu día a día con tu entorno XenServer. 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, hace tiempo que no repasamos los updates de XenServer 5.6 SP2, es importante que los que mantengáis ésta versión, eventualmente miréis los Hotfix públicos que publica Citrix en: http://support.citrix.com/product/xens/v5.6sp2/

El 29 de marzo se presentó un Hotfix que a su vez, nos pone al día de algunos los Hotfix anteriores. Se trata del CTX132914: http://support.citrix.com/article/CTX132914

Este soluciona problemas con el hypervisor y además incluye los siguientes hotfix:

• CTX130294- Hotfix XS56ESP2002

• CTX131108- Hotfix XS56ESP2005

• CTX131303- Hotfix XS56ESP2006

Otro Hotfix importante, sobre todo para los que utilicéis HA es el CTX130845, disponible en http://support.citrix.com/article/CTX130845

Este Hotfix soluciona un problema detectado en el entornos HA, que al eliminar un snapshot, deja la máquina virtual sin funcionar correctamente.

Como siempre, recordarte como instalar los hotfix por CLI:

1. Descargamos el hotfix y lo descomprimimos

wget https://support.citrix.com/servlet/KbServlet/download/30490-102-681593/XS56ESP2013.zip

2. Lo instalamos

xe patch-upload file-name=”nombre del hotfix”

Este nos imprimirá por pantalla el uuid del hotfix

3. Aplicamos el hotfix sobre el pool

xe patch-pool-apply uuid=”uuid del hotfix”

4. Reinicio

También, podemos utilizar XenCenter y aplicar el Update directamente desde el asistente que incluye para actualizar.

Con esto me despido por, hoy. Como siempre espero que haya podido ayudarte en tu día a día con XenServer. 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 en nuestra sección de XenServer, veremos unos comandos que no están en las guías en PDF de Citrix, son comandos que os serán necesarios en casos extremos…

Cómo ya hemos comentado en otros Posts, XenServer tiene un Core GNU/Linux + Xen y al final muchas de las operaciones que realiza la XAPI se traduce en comandos propiamente de GNU/Linux. Los que estéis familiarizados con otros entornos Xen, como por ejemplo el de Debian o Novell SuSE, conoceréis el concepto domU (máquina virtual) y lo que significar hacer un xm destroy a una máquina virtual.

Realmente cuando mediante XenCenter o mediante CLI hacemos un force shutdown no llega a ser un destroy de un DomU, es decir que puede que el DomU no se apague. Cuando tenemos este problema tan simple: Una máquina virtual no se apaga, ni por la CLI, ni matando tareas, etc. Tenemos estos comandos.

list_domains

Este comando nos lista algo como:

id | uuid | state

0 | 18b2dc18-232d-47c4-8b72-12393a9e990d | R

1 | 6834673a-d883-b45d-f402-512d55a6c3a5 | B

• El id 0 corresponde a el Dom0 (Host anfitrión)

• El id 1 es una máquina virtual. Si ejecutamos: xe vm-list uuid=6834673a-d883-b45d-f402-512d55a6c3a5 vamos a ver que máquina virtual está corriendo.

Como veis nos muestra las máquinas virtuales que corren sobre este servidor (no sobre el pool). Gracias a este comando obtenemos el ID y el estado de una máquina virtual.

/opt/xensource/debug/destroy_domain

Esta es la forma más bestia de parar una máquina virtual que conozco (aparte de apagar el Host desde la ILO xD). Si ejecutamos:

/opt/xensource/debug/destroy_domain -domid 1

La máquina con ID 1 tiene que morir en unos segundos. Es un comando a bajo nivel, así que muchas veces, si tienes XenCenter a mano, verás que para él, la máquina sigue “running” ya que no ha notificado a la xapi la caída de este domU.

Con esto me despido por hoy, espero que como siempre te haya podido ayudar en tu entorno XenServer.

¿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 en nuestra sección de XenServer veremos cómo utilizar los comandos de HA utilizado la CLI.

Como ya sabéis, la CLI es donde reside gran parte del potencial de XenServer, hay funciones que siempre son más rápidas y más precisas utilizando la CLI que utilizando consolas gráficas como XenCenter. En este caso, vamos a ver cómo podemos utilizar la CLI para administrar las políticas de HA de nuestro clúster XenServer.

Cómo ya vimos anteriormente en el artículo ¿Cómo configurar High Avaliability en XenServer? a cada máquina virtual, se le asigna su prioridad de reinicio (Restart Priority) que puede ser (Do Not Restart, Restart if Possible, Restart y Restart First). Estos se traducen como:

Citrix recomienda solo utilizar la prioridad 0  para las máquinas virtuales que tengan StorageLink, para los casos normales hay que utilizar a partir de la prioridad 1  o más.

Vamos a activar HA para nuestra máquina virtual.

root@xenserver# xe vm-param-set uuid=<uuid_mv> ha-restart-priority=1  ha-always-run=true

Activamos también el Heart Beat para nuestro SR principal

root@xenserver# xe pool-ha-enable heartbeat-sr-uuids=<uuid del SR>

Es posible que nuestro entorno no pueda soportar todas nuestra máquinas virtuales protegidas con HA.  XenServer es capaz de calcular el estado:

root@xenserver# xe pool-ha-compute-max-host-failures-to-tolerate

Si el commando anterior nos retorna 0, tendremos que racionalizar las máquinas protegidas. Si por el contrario nos devuelve 2 y solo necesitamos una política de N+1, pues podemos configurarlo con:

root@xenserver# xe pool-param-set ha-host-failures-to-tolerate=1 uuid=<uuid del pool>

Para desactivar HA de una máquina, solamente tenemos que reconfigurar el parámetro ha-always-run a false

Esto es todo por hoy, espero como siempre que te haya parecido interesante y animarte a probar XenServer en tu entorno. 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, en el post de hoy veremos que son la vApps y para que se utilizan.

Esta nueva funcionalidad, añadida en la versión 6.0 de XenServer se define como un grupo lógico, de una o más máquinas virtuales, que pueden ser gestionadas como una entidad agrupada. De este modo podemos arrancar/parar/exportar… un conjunto entero de máquinas virtuales como si de una sola se tratara.

Las máquinas virtuales de una vApp no residen necesariamente en un único host, sinó que se utilizan las mismas reglas de distribución que tenga el Pool.

Esta funcionalidad también permite al administrador asignar un orden de arranque de las máquinas virtuales que forman el vApp y un tiempo de espera (delay) para que arranque dicha máquina virtual. De este modo en caso de por ejemplo una caída del entorno (corte eléctrico, error hardware, etc) las máquinas virtuales del vApp se levantarían en el orden establecido, por ejemplo primero los backends de base de datos, las aplicaciones y luego los frontends web, etc.

Vamos a crear nuestra vApp de prueba

Utiliando XenCenter, seleccionamos una máquina virtual para nuestra nueva vApp y con el botón derecho, “Assign to vApp -> New vApp”.  Le damos un nombre y seleccionamos las máquinas que queramos añadir al vApp. Una vez seleccionadas todas las máquinas, configuramos la “VM Startup Sequence”

Básicamente tenemos dos opciones por máquina virtual, establecer el orden secuencial de arranque y el tiempo que dejamos que el sistema espero hasta arrancar la siguiente máquina virtual. No existen unos valores estandares para el delay, puedes tunearlos en función de lo que tarde tu entorno en arrancar las máquinas virtuales. Para los que hayáis configurado clusters de Xen con HeartBeat, esta parte me recueda mucho a la configuración de Constraints, cierto?

Mediante Xapi, tenemos la entidad “appilance” que utilizaremos para gestionar las vApps desde consola como si fueran una sola máquina virtual:

root@xenserver:# xe appliance-list

uuid ( RO)                  : 25261ede-8732-7897-abbd-dc9a248756f2

name-label ( RW): TestvApp

name-description ( RW):

VMs (SRO): 03a34fb2-d191-8253-83d4-b28431f6275e; f06214bd-2854-67f1-e0c2-6d2a20440431; ae76136c-96f4-dc7a-849d-47f50245d798; a93dc68e-066c-809e-0f6f-836efe8c7c8d; 896b9860-0fa3-b95a-45d1-866c6200b865; 78d6f04a-bb0e-ac2f-1220-bd2d98b90069; b5f5110c-c951-94b2-1000-929d764eccd8

allowed-operations (SRO): start; clean_shutdown; hard_shutdown; shutdown

current-operations (SRO):

Bueno, esto es todo por hoy, espero que como siempre te haya parecido interesante y te haya podido ayudar para tu dia a dia con XenServer. 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.

Hoy, en la sección de XenServer continuaremos con la configuración de nuestro Disaster Recovery utilizando las herramientas que incluye XenServer.

La semana pasada vimos como exportar los metadatos de nuestras máquinas virtuales a un Storage Repository y hoy continuaremos con la automatización de esta tarea y veremos cómo podemos exportarla a un fichero local.

Para poder automatizar el proceso de exportación es necesario disponer de como mínimo un XenServer 5.0. A partir de esta versión, podemos seguir los siguientes pasos.

Abrimos la xsconsole de un servidor de nuestro pool y accedemos a la sección “Backup, Restore and Update” y entramos en “Schedule Virtual Machine Metadata”

Seleccionamos la periodicidad que queremos aplicar a nuestro pool (por ejemplo: “Weekly”)

En este momento ya tendremos automatizado el backup de nuestros metadatos, ahora veremos como guardar los metadatos de las máquinas virtuales en ficheros “planos” para su posterior importación en el entorno de Disaster Recovery.

El comando siguiente, nos va a generar N ficheros metadata.bck1, metadata.bck2… metadata.bckN en función del número de máquinas virtuales que tengamos:

[root@xenserver]# xe vm-export filename=metadata.bck –multiple metadata=true

Con esto, me despido por hoy. Espero como siempre, haber podido explicarte algo nuevo que sea útil para tu entorno XenServer. 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.

Hoy en nuestra sección de XenServer veremos como replicar los metadatos de nuestro Pool, necesario para tener un Disaster Recovery completo.

Un repaso rápido

A nivel de arquitectura, XenServer, diferencia lo que por un lado son los metadatos, de los VDI donde puramente, hay los datos en crudo de cada disco de una máquina virtual. Estos metadatos, como puede ser los uuids, name-labels, configuración, networks… etc. Se almacenan en una base de datos, accesible por todos los hosts del Pool.

Como ves, es casi tan importante hacer backup de los metadatos, como de los discos en si. Por esto es necesario que tu solución de disaster recovery tenga una copia de los metadatos del pool.

Como funciona

Desde las nuevas versiones, a partir de la 5.0, la base de datos ha dejado de ser exportada como un fichero XML a ser exportada como un VDI en el Storage Repository. Además, a partir de la versión 5.0,  puede automatizarse los cambios de este VDI para ser exportados a nuestro entorno de Disater Recovery.

Este cambio es muy importante porque si sincronizamos todo el Storage Repository, implícitamente, tendremos todos los metadatos. Si necesidad de mantener otro sistema para la exportación de los XML y otro para los VDIs.

Exportando metadatos

Para exportar nuestos metadatos es tan sencillo como entrar en la xsconsole, seleccionar Backup, Restore and Update, Backup Virtual Machine Metadata

Seleccionamos el SR donde queremos almacenar el VDI y en unos minutos tendremos el VDI Pool Metadata Backup. Con esto, me despido hasta la semana que viene. Como siempre, un placer queridos lectores. 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.

Hoy en nuestra sección de XenServer veremos que nos trae la nueva versión de Citrix XenServer 6.02 .

Respecto a la versión XenServer 6.0, la nueva versión XenServer 6.02 aporta:

• Emergency Network Reset: Es un mecanismo que permite recuperar o restablecer la configuración de red a nivel de Host. Según Citrix es útil también para cuando queramos configurar la red de un host desde cero y ayuda a recuperar la configuración si el host se queda con una configuración de red inconsistente.
• Enhanced Guest OS Support:  Soporte para CentOS 5.7 (32/64-bit), CentOS 6.0 (32/64-bit), Red Hat Enterprise Linux 5.7 (32/64-bit), Oracle Enterprise Linux 5.7 (32/64-bit). Puedes consultar hasta donde llega este soporte en http://support.citrix.com/article/CTX131973
• Windows XenServer Tools Improvements: Los clientes Windows pueden hacer uso de cualquier framework .Net 3.5 o .Net 4.0

Mejoras en curso:

1. Rotación por hora de los logs para reducir el espacio en disco de los Dom0 (CP-3137)
2. Mejoras de NFS (NFS stability (XOP-60))
3. Mejoras en el rendimiento de las VLANS cuando se utiliza OVS (CA-68226)
4. Mejoras de las capacidades de procesamiento en los Dom0 (CA-70552)
5. Mejoras de rendimiento de red en las máquinas virtuales para UDP (CA-72746)
6. La capacidad de respuesta de xapi  durante el apagado de las máquinas virtuales grandes (SCTX-507)

Hotfix incluidos respecto a XenServer 6.0:

1. Hotfix XS60E001
2. Hotfix XS60E002
3. Hotfix XS60E003
4. Hotfix XS60E004

Los siguientes componentes se han actualizado desde el lanzamiento de XenServer 6.0:

• Microsoft System Center Integration Pack v6.0.2
• Workload Balancing v6.0.2
• Web Self Service 1.1.1 Virtual Appliance.

Para los que quieran actualizar, ya desde la versión 5.6, se pueda hacer mediante Rolling Pool Update Wizard como si fuera un hotfix normal.

Puedes ver más información sobre esta nueva versión en: http://support.citrix.com/article/CTX131974

Con esto, espero que como siempre, haberte aportado mi granito de arena en tu día a día con XenServer. Saldudos

¿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.