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

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.

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.

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.

Emergencias en Citrix XenServer

Ferran Serafini — Wed, 26 Oct 2011 07:30:55 +0000

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

¿Cómo instalar Citrix XenServer 6?

Ferran Serafini — Wed, 05 Oct 2011 07:28:51 +0000

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.

Introducción a XAPI y la gestión de máquinas virtuales

Ferran Serafini — Wed, 21 Sep 2011 07:04:07 +0000

Hola amigos, hoy vengo con más comandos prácticos y nuevos trucos para XenServer.

Hoy os mostraré una breve introducción a la api de XenServer (XAPI) y realizaremos operaciones básicas con las maquinas virtuales.

La API de XenServer – XAPI

XenServer utiliza XAPI para gestionar todas las operaciones. XenCenter, consola (CLI) o xsconsole interactúan directamente con XAPI.

Xapi trabaja como webservice así que los que dominéis python, perl, java, etc… Tenéis a vuestra disposición infinidad de opciones para “tunear” vuestros entornos de administración, tareas automatizadas…

Podéis consultar más a fondo como funciona en su documentación oficial:

http://www.xen.org/files/XenCloud/ocamldoc/apidoc.html

Operaciones con maquinas virtuales

Podemos ver mediante el comando xe vm + TAB todas las opciones que podemos realizar desde la CLI.

Las operaciones básicas como parar, arrancar, reiniciar o migrar de servidor dom0 son:

xe vm-shutdown
xe vm-start
xe vm-reboot
xe vm-migrate

Seguido del UUID de la maquina o más sencillo, por el name-label (nombre de la maquina virtual).

Los comandos de parada vm-shutdown y vm-reboot tienen también un parámetro que podemos necesitarlo en caso que la maquina virtual no reaccione a la orden de apagado normal. El parámetro es force=true es literalmente como desenchufar el “cable virtual” de la fuente de alimentación de la máquina virtual.

xe vm-shutdown name-label=vserver01 force=true

Para migrar una maquina virtual de servidor domain0 se utiliza xe vm-migrate. Como requisito, debes disponer de almacenamiento compartido y tener las xentools instaladas en las maquinas virtuales. Simplemente hay que especificar el nombre de la maquina virtual (name-label o UUID) y el host de destino.

xe vm-migrate name-label=vserver01 host=xensrv02

Otro comando muy interesante es xe vm-export. Este nos permite exportar una maquina virtual apagada a un fichero.

xe vm-export vm=vserv01 filename=/nfs/vms/server.xva

Una vez exportado, tenemos una copia exacta de la maquina que puede importada al mismo o a otro entorno XenServer mediante xe vm-import

Por defecto vm-import genera una nueva MAC, si nos interesa importar la maquina con la misma MAC que la maquina original, el parámetro preserve=true nos mantendrá intacta la configuración original.

Con esto amigo, me despido por hoy, espero sobretodo haberte contado algo de tu interés y no olvides que puedes comentar abajo cualquier duda o sugerencia.

Espero verte la semana que viene donde expondré más a fondo la gestión de snapshots, su exportación para que te puedas hacer un backup de tus máquinas personalizado y otras cosas para que veas en XenServer una solución viable a tu entorno de virtualización.

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

Disponible XenServer Self Service Manager Beta

Adolfo Muñoz Moratalla — Wed, 20 Jul 2011 07:52:08 +0000

Queridos lectores,

Citrix anuncia una nueva característica dentro de su proyecto Boston de XenServer. Esta nueva característica se llama Self Service Manager.

Hay disponible una beta para todos los usuarios para poder testearla. Es una gran herramienta enfocada al cloud y autoservicios en la nube.

Mediante la misma los usuarios, aunque no tengan experiencia, podrán iniciar sesión y administrar sus propios recursos.

Paso a detallaros algunas de sus características:

Multi-plataforma (ESX, XenServer, OpenStack)
Multi-Tenant
Catálogos personalizables
Administración de cuotas
Portal de Autoservicio
Chargeback reporting
Importación de entornos existentes
Escalabilidad
Control granular basado en roles

También os dejo unos enlaces de youtube para que podáis aprender a trabajar con ellos:

Configuración del appliance: http://www.youtube.com/watch?v=dsrtYe9zZM0

Administración de usuairos: http://www.youtube.com/watch?v=TEwNiyxwWhE

Administración de catálogos: http://www.youtube.com/watch?v=Cid3aR3axyw

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

¿Cómo instalar el nuevo hotfix XS56ESP2001 para XenServer 5.6 SP2?

Adolfo Muñoz Moratalla — Wed, 29 Jun 2011 06:51:22 +0000

Queridos lectores,

Hace unos días Citrix publicaba este nuevo hotfix. Desde su portal oficial recomiendan encarecidamente aplicarlo sobre la versión 5.6 SP2.

A continuación, como siempre hago cuando sale una nueva actualización, os recuerdo como poder hacer la instalación del parche en modo CLI.

1.- Descargamos el hotfix y descomprimimos

wget http://support.citrix.com/servlet/KbServlet/download/27597-102-658199/XS56ESP2001.zip

2.- Instalamos el hotfix

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

3.- Imprimirá lo siguiente por pantalla

65066756-1d29-422e-8f6d-fa6fb4459551

4.- Aplicamos el parche sobre XenServer

xe patch-pool-apply uuid= 65066756-1d29-422e-8f6d-fa6fb4459551

5.- Verificamos

xe patch-list

6.- Reiniciaremos para que tenga efecto el parche

Nada mas queridos lectores, espero que sea de utilidad.

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

¿Cómo cambiar el IP y Mascara de la interfaz de administración en XenServer?

Adolfo Muñoz Moratalla — Wed, 15 Jun 2011 08:30:31 +0000

Queridos lectores,

En el post de hoy, os enseñaré a modificar la ip y máscara de la interfaz de administración en un servidor Citrix XenServer, y que además, esta dentro de un pool. Para ello podremos hacerlo de dos formas, desde la consola fisica de XenServer y desde CLI.

Sea un método u otro recomiendo hacerlo in situ, mas que nada por si hay fallo o perdida de conectividad.

1.- Realizamos un backup de metadata y de las VM con el proposito de tener todo asegurado.

2.- Desactivamos la alta disponibilidad si la tuviéramos. Esto lo podemos hacer desde XenCenter

3.- Modificamos la ip y máscara:

Método A:

Accedemos a cualquier servidor del pool dentro de su consola física xsconsole. Si lo estuviéramos haciendo remotamente teclearíamos xsconsole en cualquier consola ssh.

Seleccionamos: Network and Management Interface > Cofigure Management Interface. Seguidamente asignamos la configuración de la interfaz de administración

Si viéramos que aplicando cambios que queda congelada la pantalla podemos teclear CTRL + Z, nos aparecerá una consola linux y ejecutaremos xe-toolstack-restart. Posteriormente podremos retornar a xsconsole con el comando fg%1

Método B:

Todo el método B es posible hacerlo mediante el siguiente comando:

xe pif-reconfigure-ip uuid=”UUID of host management PIF” IP=”New IP” gateway=”GatewayIP” netmask=”Subnet Mask” DNS=”DNS Lookup IPs” mode=”dhcp,none,static”

4.- Ejecutamos xe-toolstack-restart para guardar cambios de forma segura. Comprobaremos con xe host-is-in-emergency-mode si el servidor está en modo de emergencia.

5.- Ejecutaremos 3 y 4 en todos los servers del pool.

6.- Mediante cualquiera de los métodos del paso 3 modificamos la IP en el pool master

7.- Ejecutamos xe-toolstack-restart en el pool master

8.- En todos los miembros del pool menos en el pool master ejecutamos xe pool-emergency-reset-master master-address=IP_OF_THE_MASTER

9.- Verificamos el correcto funcionamiento del pool.

10.- Habilitamos alta disponibilidad si lo hubiéramos deshabilitado.

Como veis con estos sencillos pasos habremos cambiado la ip y mascara de nuestro pool de xenservers. No olvidéis realizar backups por si las moscas.

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