Archivo de la etiqueta: Xen

AstriCon 2009: Asterisk Xenified

Tras la tempestad llega la calma. Por fin he podido tranquilizarme y publicar por 茅stos lares las transparencias para que pod谩is echarles un ojo y comentar si os molan o si apestan. 馃檪

La presentaci贸n define un escenario de aplicaci贸n de Asterisk sobre una plataforma Xen as铆 como los trucos necesarios para hacer que funcione lo mejor posible.

Enjoy! 馃檪


Curso: Virtualizaci贸n con Xen y KVM

Como cada verano 茅ste tambi茅n estamos inmersos en los cursillos de julio del E-Ghost 馃檪

A continuaci贸n pod茅is ver/descargar la presentaci贸n del curso que hemos dado Zefe y yo sobre virtualizaci贸n con Xen y KVM. La idea del curso es ofrecer una introducci贸n a las distintas t茅cnicas de virtualizaci贸n existentes, y su uso con Xen y KVM. Asimismo, se contemplan algunos frontends como Enomalism o ConVirt, 煤tiles a la hora de delegar tareas de administraci贸n, por ejemplo.

Hope you enjoy it! 馃槈

PD: Tambi茅n he dejado la presentaci贸n en SlideShare.

DAHDI 2.2 mejora el soporte en entornos virtualizados

Ya hemos comentado por aqu铆 que para que Zaptel/DAHDI funcionara correctamente en un entorno virtualizado como Xen era necesario hacer alguna peque帽a modificaci贸n en el fichero dahdi_dummy.c para deshabilitar el timming por RTC.

Durante el Amoocon Kevin Fleming me coment贸 que en la nueva versi贸n de DAHDI eso ya so ser铆a necesario y acabo de comprobar que es cierto. 馃檪

En DAHDI 2.2 se ha eliminado el RTC como fuente de tiempo para el subsistema DAHDI, ya que su funcionamiento era err谩tico en ocasiones. En su lugar se utiliza el timming del propio kernel. Vamos a verlo:

Tras compilar y cargar dahdi_dummy 2.2 SIN modificar vemos que carga correctamente:

[2548770.332063] dahdi: Telephony Interface Registered on major 196
[2548770.332075] dahdi: Version: 2.2.0-rc5
[2548771.512873] dahdi: Registered tone zone 0 (United States / North America)

Comprobemos la fuente de tiempo:

ast16:/usr/src/asterisk/dahdi-tools-2.2.0-rc3# cat /proc/dahdi/1
Span 1: DAHDI_DUMMY/1 "DAHDI_DUMMY/1 (source: Linux26) 1" (MASTER)

Y un dahdi_test para ver que todo va bien:

ast16:/usr/src/asterisk/dahdi-tools-2.2.0-rc3# dahdi_test
Opened pseudo dahdi interface, measuring accuracy...
99.996% 99.997% 99.998% 99.996% 99.999% 99.996% 100.000% 99.996%
99.999% 99.995% 99.999% 99.997% 99.997% 99.998% 99.999% 99.996%
100.000% 99.999% 99.995% 100.000% 99.614% 99.610% 99.614% 99.612%
99.616% 99.609% 99.614% 100.000% 99.997% 99.612% 99.613% 99.610%
99.614% 99.610% 99.614% 99.610% 99.614% 99.609% 100.000% 99.614%
99.610% 99.613% 99.611% 99.613% 99.610% 99.614% 99.609% 100.000%
99.614% 99.609% 99.614% 99.610% 99.614% 99.998% 99.610% 99.614%
99.611% 99.999% 99.614% 99.610% 99.614% 99.610% 99.613% 99.610%
99.613% 99.609% 99.614% 99.610% 100.000% 99.614% 99.610% ^C
--- Results after 71 passes ---
Best: 100.000 -- Worst: 99.609 -- Average: 99.758634, Difference: 99.998285

DAHDI 2.2 todav铆a est谩 en estado de release candidate, pero pronto se espera una versi贸n estable.

Pod茅is descargar dahdi-linux y dahdi-tools aqu铆.

PD: La foto se la tomo prestada a Elio. 馃槈

Running Asterisk in virtualized environments

Falta una hora para que de comienzo la charla que dar茅 en el Amoocon 2009. Me intento relajar viendo otras charlas, pero parece que no funciona, los nervios siguen ah铆, as铆 que escribo este post 馃檪

Todos los materiales expuestos durante los 2 d铆as estar谩n disponibles en la web del Amoocon con v铆deos incluidos tras las pertinentes labores de post-producci贸n, pero por si a alguno le interesa, ya he colgado todos los materiales de “Running Asterisk in virtualized environments” aqu铆.

En el fichero comprimido pod茅is encontrar lo siguiente:

  • Presentaci贸n en ODP y PDF.
  • Ficheros de configuraci贸n de Asterisk
  • Configuraci贸n de Xen
  • Configuraci贸n de KVM
  • Escenarios de SIPp utilizados
  • Resultados de las pruebas

Espero que os sirva!

Probando Windows 7 sobre Xen

脷ltimamente he vuelto a esa fase en la que mola probar toda distro que pasa por tus manos, solo por el hecho de experimentar y ver c贸mo es. 脡sta vez le ha tocado el turno al nuevo Windows 7, pero para darle un toque de color al asunto lo he instalado en mi servidor Xen. 馃檪

Tal y como me esperaba, la instalaci贸n ha sido sencilla y no he necesitado ninguna configuraci贸n especial en el servidor Xen, aparte de la t铆pica para una m谩quina virtual HVM (con Windows no podemos utilizar paravirtualizaci贸n).

En concreto he utilizado esta configuraci贸n:

kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory = 512
name = "Win7"
vif = [ 'type=ioemu, bridge=eth0' ]
acpi = "1"
# Install
#disk = [ 'phy:/dev/xenvol/win7,ioemu:hda,w', 'file:/root/ISOs/windows7_build7000.iso,hdc:cdrom,r' ]
# Run
disk = [ 'phy:/dev/xenvol/win7,ioemu:hda,w' ]
on_poweroff = 'destroy'
on_reboot聽聽 = 'restart'
on_crash聽聽聽 = 'restart'
device_model = '/usr/lib/xen/bin/qemu-dm'
boot="dc"
vnc=0
vnclisten="0.0.0.0"
vncpasswd=''
#serial='pty'
keymap = 'es'
usb=1
usbdevice='tablet'

Tras una instalaci贸n no demasiado larga he estado un rato enredando y la verdad es que me ha gustado m谩s que Vista, yseg煤n se esta comenando por todo Internet Windows 7 s铆 que parece ser el sucesor de Windows XP. Os dejo unas capturillas de pantalla en las que se puede ver que primero se ha accedido por VNC (para la instalaci贸n y configuraci贸n inicial) y posteriormente por RDesktop, que funciona mucho mejor que VNC al menos en entornos Windows sobre Xen.

Rendimiento en la virtualizaci贸n con Xen

Hace bastante que tengo montado un server con Xen en casa y a lo largo de este tiempo de experimentaci贸n he sacado algunas conclusiones acerca del rendimiento que me gustar铆a compartir. 馃檪

En Xen hay varios factores que pueden determinar el rendimiento tanto de las m谩quinas virtuales como del sistema completo:

El Kernel
Oficialmente solo se mantiene una versi贸n parcheada del kernel 2.6.18.8 para su uso como dom0. Algunas distros han ido portando hacia adelante estos parches de Xen y por ejemplo Debian Lenny dispone del kernel 2.6.26 para su uso como dom0. Aunque se pueden utilizar los Kernels empaquetados por las distintas distros, algunos usuarios han reportado problemas. Para obtener el mejor rendimiento posible y minimizar los problemas se recomienda utilizar el Kernel oficial (2.6.18.8) siempre que sea posible, al menos hasta que los parches de Xen para el dom0 sean incluidos en el mainline del Kernel (se espera que para la versi贸n 2.6.29).

Red
El rendimiento del sistema de red es otro de los factores que m谩s preocupan a los usuarios de sistemas virtualizados. A la hora de determinar un posible fallo de rendimiento en el rendimiento de red hay varios elementos que pueden estar involucrados: la tarjeta de red, el switch y el driver de la tarjeta de red.

Supongamos un sistema con 10 m谩quinas virtuales. Esto supone que (si utilizamos bridging en las interfaces de red) que habr谩 10 equipos transmitiendo datos y que el switch al que este conectado el servidor tendr谩 10 MACs en una de sus bocas.Algunos switches y tarjetas de red pueden no resultar adecuados para soportar una carga tan elevda de tr谩fico, por lo que no vale usar cualquier switch (no al menos ese Linksys de 8 puertos 馃槈 ).

La velocidad de transferencia es otro de los mayores problemas de la virtualizaci贸n. Esto se puede solucionar (si el entorno virtualizado es GNU/Linux) deshabilitando el checksum de los paquetes en transferencia. Al no existir como tal un medio ya que la comunicaci贸n es a nivel de Kernel, es seguro deshabilitar esta opci贸n. Para ello ejecutaremos lo siguiente en los domU:

# ethtool -K eth0 tx off

Y en el dom0:

# ethtool -K eth0 tx on

Disco Duro
Supongamos de nuevo que tenemos ese servidor con 10 m谩quinas virtuales. Utilizar particiones independientes para cada m谩quina virtual ofrece mayor rendimiento que utilizar ficheros individuales. Utilizar LVM y una partici贸n independiente para cada m谩quina virtual suele ser lo m谩s adecuado.

Adem谩s del esquema de particionado, el hecho de tener 10 m谩quinas virtuales encendidas supone demasiadas escrituras concurrentes en disco por lo que conviene utilizar un sistema RAID (0 o 5 por ejemplo) para que estos procesos de lectura/escritura聽 no comprometan el rendimiento del sistema virtualizado.

En el servidor que tengo en casa (procesador QuadCore, 4GB de RAM y 2 discos duros en RAID 0) con 14 m谩quinas virtuales arrancadas el rendimiento es muy bueno 馃檪

HowTo: Compilar Zaptel/DAHDI en un entorno Xen

A raiz del comentario de un usuario me he acordado de un post que ten铆a en mente pendiente desde hace tiempo: un peque帽o HowTo para compilar Zaptel o DAHDI en un equipo con Xen.

El problema que tenemos a la hora de compilar ztdummy o dahdi_dummy en Xen es la fuente de timming. En las versiones actuales de Zaptel y DAHDI el timming (cuando no tenemos tarjetas) se puede obtener de tres fuentes:

  1. El HPET.
  2. El RTC.
  3. El tick del sistema (opci贸n CONFIG_HZ)

En Xen (si usamos el kernel oficial 2.6.18 parcheado) no tenemos disponibles ni la primera ni la segunda opci贸n, pero Zaptel se cree que S脥 que tenemos acceso al RTC, y por tanto falla.

Para solucionarlo tenemos que editar el fichero ztdumy.c o dahdi_dumy.c y localizar la siguiente secci贸n:

/*
* NOTE: (only applies to kernel 2.6)
* If using an i386 architecture without a PC real-time clock,
* the #define USE_RTC should be commented out.
*/
#if defined(__i386__) || defined(__x86_64__)
#if LINUX_VERSION_CODE >= VERSION_CODE(2,6,15)
/* The symbol hrtimer_forward is only exported as of 2.6.22: */
#if defined(CONFIG_HIGH_RES_TIMERS) && LINUX_VERSION_CODE >= VERSION_CODE(2,6,22)
#define USE_HIGHRESTIMER
#else
#define USE_RTC
#endif
#else
#if 0
#define USE_RTC
#endif
#endif
#endif

Si os fij谩is el comentario ya nos indica lo que tenemos que hacer: comentar las l铆neas correspondientes para que no se defina el flag USE_RTC. Para ello modificamos el c贸digo anterior dej谩ndolo as铆:

/*
* NOTE: (only applies to kernel 2.6)
* If using an i386 architecture without a PC real-time clock,
* the #define USE_RTC should be commented out.
*/
#if defined(__i386__) || defined(__x86_64__)
#if LINUX_VERSION_CODE >= VERSION_CODE(2,6,15)
/* The symbol hrtimer_forward is only exported as of 2.6.22: */
#if defined(CONFIG_HIGH_RES_TIMERS) && LINUX_VERSION_CODE >= VERSION_CODE(2,6,22)
#define USE_HIGHRESTIMER
#else
//#define USE_RTC
#endif
#else
#if 0
//#define USE_RTC
#endif
#endif
#endif

De esta manera, Zaptel o DAHDI compilar谩n sin problemas en un entorno Xen y podremos utilizar el dummy driver necesario para MeetMe o el IAX trunking.

Problemas con DAHDI 2.1.0 y Xen

Hoy me dispon铆a a reinstalar uno de mis Asterisk de casa con las 煤ltimas versiones estables de la rama 1.6 de Asterisk y las 煤ltimas versiones estables de DAHDI.

En casa tengo un servidor con Xen y el kernel oficial, un 2.6.18 parcheado. Esta versi贸n no tiene soporte para HPET, por lo que se usar铆a el RTC, pero como en Xen tampoco funciona eso es necesario comentar las l铆neas en las que pone:

#define USE_RTC

al principio del fichero dahdi_dummy.c.

Tras hacer lo propio, me encuentro con el siguiente problema al compilar DAHDI:

CC [M]聽 /usr/src/asterisk/dahdi-linux-2.1.0/drivers/dahdi/dahdi_dummy.o
/usr/src/asterisk/dahdi-linux-2.1.0/drivers/dahdi/dahdi_dummy.c: In function 鈥榙ahdi_dummy_timer鈥:
/usr/src/asterisk/dahdi-linux-2.1.0/drivers/dahdi/dahdi_dummy.c:223: warning: implicit declaration of function 鈥榟rtimer_set_expires鈥

Mirando el c贸digo de dahdi_dummy, me encuentro lo siguiente:

/* use kernel system tick timer if PC architecture RTC is not available */
static void dahdi_dummy_timer(unsigned long param)
{
hrtimer_set_expires(timer, jiffies + 1);
add_timer(&timer);
...

Al parecer el error viene porque se est谩 utilizando una funci贸n del HPET cuando realmente deber铆a usarse el system tick. R谩pidamente me he dirigido al visor del repositorio de Subversion, para ver qu茅 hab铆a cambiado desde DAHDI 2.0.0, ya que esa versi贸n me funcionaba correctamente. Al acceder al visor me he encontrado con que hab铆a un nuevo tag: DAHDI 2.1.0.1! :-O Al mirar el ChangeLog veo que han solucionado justo el bug que hab铆a encontrado!

Por lo tanto, si est谩s tratando de instalar DAHDI 2.1.0 en Xen mejor que utilices DAHDI 2.1.0.1, ya que sino se producir谩n errores de timming. De momento no hay paquetes comprimidos de esta 煤ltima versi贸n, por lo que es necesario obtenerla del repositorio de Subversion:

svn co http://svn.digium.com/svn/dahdi/linux/tags/2.1.0.1 dahdi-linux-2.1.0.1
svn co http://svn.digium.com/svn/dahdi/tools/tags/2.1.0.1 dahdi-tools-2.1.0.1

Enjoy! 馃檪

Curso de virtualizaci贸n con Xen

Con todo el l铆o, al final este a帽o no he podido poner un post comentando los Cursillos de Verano del E-Ghost 馃檨

Uno de los cursos en los que me infiltrado 馃檪 es en el de Introducci贸n a la Virtualizaci贸n, en la que se ven OpenVZ y Xen. Zigor Egiguren (Cosmos) se ha encargado de la parte de OpenVZ y yo de la de Xen.

Por si alguno lo encuentra de inter茅s, aqu铆 os dejo la documentaci贸n que voy a utilizar el d铆a de hoy, la ten茅is descargable en http://www.slideshare.net/saghul

Virtualizaci贸n con Xen

Aunque ya son m谩s de las 12:00 PM, no he tenido tiempo de postear antes 馃檪

Hoy d铆a 26 de marzo se celebraba el primer Document Freedom Day, as铆 que pens茅 que ser铆a un buen d铆a para publicar este documento que redact茅 hace poco.

En 茅l se detalla la instalaci贸n de un sistema de virtualizaci贸n Xen, compil谩ndolo desde los fuentes, y utilizando kernels personalizados. Tambi茅n se detalla como montar domUs con soporte para Full Virtualization (HVM) o Paravirtualizaci贸n (PV).

Espero que os sirvan 馃檪

Pod茅is descargarlo de aqu铆 en ODT y aqu铆 en PDF. (Tambi茅n est谩n en la secci贸n de Documentos)

xen_logo.gif