Los controladores para-virtualizados aumentan el rendimiento de los huéspedes totalmente para-
virtualizados. Con los controladores para-virtualizados la latencia de E/S disminuye y el rendimiento
aumenta los niveles a casi bare-metal. Es recomendable utilizar controladores para-virtualizados para
huéspedes completamente virtualizados ejecutando tareas pesadas de E/S y aplicaciones como las BBDD.
Estos son cargados automáticamente en distros nuevas de Ubuntu, RHEL y CentOS, así como en teoría cualquier distro con un kernel superior a 2.6.27. Así que no habría que hacer nada para poder usar aplicaciones con mucha I/O como las BBDD sobre Ubuntu, tan solo indicar con el parametro ‘os-variant’ la distro que usamos o en su defecto (si no la encontramos), ‘virtio26′
Para usar BBDD en windows hay que instalar estos drivers que mejoran en mucho la velocidad la la red y escritura a disco.
Las versiones de windows que soportan estos drivers son:
• Windows XP (solo 32 bits)
• Windows Server 2003 (versiones de 32 y de 64 bits)
• Windows Server 2008 (versiones de 32 y de 64 bits)
• Windows Vista/7 (versiones de 32 y de 64 bits)
La última iso de estos drivers se puede encontrar aqui:
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
En concreto me bajo las versiones:
- virtio-win-1.1.16.iso
- virtio-win-1.1.16.vfd
Para hacer una instalación de Windows con estos drivers por ej en un Windows XP haremos así:
virt-install -c qemu:///system --virt-type kvm --name winxp --vcpus 1 --ram 1024 --os-variant winxp \ --disk /var/lib/libvirt/images/guests/winxp.img,size=30,sparse=false,bus=virtio \ --disk /var/lib/libvirt/images/isos/windows/virtio-win-1.1.16.vfd,device=floppy \ --cdrom /var/lib/libvirt/images/isos/windows/virtio-win-1.1.16.iso \ --cdrom /var/lib//libvirt/images/isos/windows/winxp.iso \ --network bridge:br0,model=virtio \ --vnc
Y en la instalación nos instalará estos drivers.
Mas fuentes sobre el tema:
http://cloud.ubuntu.com/2011/03/fast-win7-kvm-virtiodisk-net-install/
http://www.todosconsoftwarelibre.es/instalacion-de-windows-7-sobre-kvm-en-ubuntu-server-10-04-1/
http://bderzhavets.wordpress.com/2011/01/20/virtio-install-windows-7-kvm-x64x86-on-ubuntu-10-04-1-server-via-dnjl-ppa/
http://blog.allanglesit.com/2011/03/kvm-guests-install-virtio-drivers-for-windows-guests/
http://kahdev.wordpress.com/2011/05/30/using-virtio-drivers-in-a-kvm-windows-guest-vm/
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
