Vuelvo a repetirme sobre la importancia de crear nuestras máquinas virtuales en KVM con los drivers virtio, tanto en linux como mas aún en Windows (sobre todo para tareas con mucho I/O como BBDD).
La mayoría de las distros de linux desde el kernel 2.6 ya soportan estos drivers, pero es importante indicarle que los use a la hora de instalar el guest.
Lo hacemos a la hora de instalar el guest con ‘virt-install’ indicándole la opción ‘–os-variant=’ a nuestra distro (por ej: ubuntulucid, consultar el man)… o en su defecto:
--os-variant=virtio26
Si hacemos un ‘lspci’ en nuestra máquina virtual, debemos ver un que los interfaces de red y de los discos son ‘virtio’:
00:03.0 Ethernet controller: Qumranet, Inc. Virtio network device
00:04.0 SCSI storage controller: Qumranet, Inc. Virtio block device
y nuestro disco duro aparecerá como ‘/dev/vda’ en vez de ‘/dev/sda’.
La diferencia es abismal. Si hacemos un ‘iperf’ en el guest en modo servidor:
# iperf -s
y otro en el host apuntando a la ip del guest:
# iperf -c 192.168.x.x -i2
Las tasas son superiores al gigabit, de host a guest y de gigabit de guest a guest (ojo, también depende de la calidad del servidor que estéis usando como host).
Y si los drivers virtio para un guest linux son muy importantes, para los guest windows, son vitales!. Sobre todo si se nos ha ocurrido la mala idea de virtualizar un sql server por ej y queremos que se menee.
Eso en el próximo post.
Para que las VM’s Linux apaguen correctamente hay que instalar el demonio ‘acpid’:
# aptitude install acpid
Ahora ya puedes hacer desde consola para que apague correctamente un:
# virsh shutdown guest
Supongamos que queremos cambiar el nombre a un guest de ‘winxp’ a ‘windozer’. Hacemos:
1- Primero hacemos un volcado del archivo xml de ese guest guardando ya el nuevo xml como queramos que se llame:
# virsh dumpxml winxp > windozer.xml
2- Editamos el nuevo xml y ponemos al principio en el tag
3- Desgraciadamente tenemos que apagar la máquina. Así que ya podemos aprovechar para cambiar el nombre de host dentro del guest si también era necesario:
# virsh shutdown winxp
Una vez apagado el guest ya podemos cambiar el nombre del disco (normalmente está en /var/lib/libvirt/images/), en mi caso de winxp.img a windozer.img y editamos nuevamente el nuevo xml y cambiamos el nombre en el tag donde se defina ese disco.
4- Hacemos un undefine del nombre del guest antiguo para que lo borre de /etc/libvirt/qemu. Este ‘undefine’ no nos borrará el disco que acabamos de renombrar en /var/lib/libvirt/images/:
# virsh undefine winxp
5- Ahora hacemos un define de nuestro nuevo archivo xml para que lo coloque en /etc/libvirt/qemu:
# virsh define windozer.xml
6- Por último ya podemos arrancar el nuevo guest:
# virsh start windozer
Últimamente estoy haciendo pruebas de virtualizar Asterisk sobre KVM. La verdad es que estoy sorprendido por el que el rendimiento es mucho mejor de lo que esperaba (mejor incluso que las pruebas que hice hace un año con VMware).
Un problema que tenía era usar una fuente de timing fiable para asterisk (para poder uasr MOH, iax trunking y MeetMe), ya que al ser una máquina virtual no podía usar el dahdy_dummy.
Como ya hay algo escrito sobre esto, os recomiendo que leáis este Post de saghul para entender de que va el tema:
href=”http://saghul.net/blog/2009/12/15/asterisk-1-6-y-las-nuevas-fuentes-de-timing
En el cual comenta que la mas fiable para usar en mi caso sería la nueva fuente (de la 1.6.2 en adelante) res_timing_timerfd.
Para poder usarla debemos cumplir estos requisitos:
asterisk > 1.6.2
kernel > 2.6.27
glibc > 2.8
y comprobar que tememos el módulo cargado:
ompruebo que lo tengo cargado:
*CLI> module show like timing
Module
Description Use Count
res_timing_timerfd.so Timerfd Timing Interface 1
res_timing_dahdi.so DAHDI Timing Interface 0
res_timing_pthread.so pthread Timing Interface 0
3 modules loaded
Si no está cargado nos aseguramos que lo tenemos en /usr/lib/asterisk/modules
Pues bien, ahora tan solo tenemos que indicarle a asterisk que use el timing interno descomentando la siguiente línea en el archivo asterisk.conf:
internal_timing = yes
Como instalar y configurar AstManProxy
AstManProxy es un servidor proxy para el Asterisk Manager Interface (AMI). La razón para usarlo es que el AMI no ha sido diseñado para recibir numerosas peticiones simultáneas desde diferntes sitios y puede causar problemas de rendimiento a nuestro sistema Asterisk.
AstManProxy también sirve para interactuar con el AMI. De esta forma no tenemos que abrir un socket y lanzar los comandos al AMI. Nos permite tener un poco mas de control sobre los formatos de entrada y salida ya que nos permite usar los formatos HTTP, XML, CSV y Standard.
Además un servidor proxy como AstManProxy sirve como un método para unificar todas esas peticiones que pueden venir desde diferentes servicios de nuestra empresa en una sola conexión.
La pena del asunto, que parece que el proyecto está abandonado.
Úsalo solo si es necesario y bajo tu propio criterio, ya que en un proyecto me fue bien utilizarlo (aun sigue dando servicio) y en otro se caía constantemente con un pedazo ‘segfault’. Así que para ello haremos un script que compruebe si el servicio está caido para que lo levante.
Para descargarlo, lo hacemos por svn:
# svn co http://svncommunity.digium.com/svn/astmanproxy/trunk/ 1.21
# cd 1.21
read more…
