Archivo de la categoría: Virtualizacion

[Debian] Virtualizando con Xen XCP

En mi blog “Phenobarbital con Soda! 2 – El hereje” he incorporado el primero (de una serie) de artículos sobre virtualización utillizando Xen XCP, la plataforma de computación en la nube de Xen, ahora estable en Debian Wheezy y lista para entornos de producción.

Hago la nota acá pues tengo muchos más suscriptores por este blog y me gustaría recibir más comentarios que vayan retroalimentando y mejorando la entrada.

Próximamente habrá una versión “copy & paste” en el wiki de phenobarbital.info.

 

Instalando y usando openvswitch en Debian GNU/Linux

Open VSwitch es un sistema de switch virtual, diseñado especificamente para habilitar automatización y despliegue de interfaces de red de manera programática, además soporta su distribución alrededor de múltiples servidores físicos, lo que lo hace ideal para la construcción de esquemas de redes virtuales para nubes.
OpenVSwitch es el esquema por defecto de gestión de redes de plataformas de virtualización con Citrix XenServer, openNebula y openStack y puede ser usado en KVM, Xen y Proxmox VE.

Open VSwitch

¿Por qué usar open VSwitch?

OpenVSwitch permite más capacidades que los módulos regulares del kernel Linux, aún cuando el Datapath está dentro del propio Kernel GNU/Linux, openVSwitch permite crear un “Soft Switch” en el hipervisor contando con características como QoS, LACP, etc; además, es el modo de gestión de redes virtuales en soluciones como OpenNebula, OpenStack y XenCenter (XCP).

Instalando open VSwitch

Para instalar openVSwitch en Debian Wheezy, realizaremos los siguientes pasos:

* Instalamos las dependencias:

apt-get install build-essential module-assistant

* Y los headers de nuestro kernel:

apt-get install linux-headers-`uname -r`

* removemos temporalmente los bridge-utils

apt-get remove --purge bridge-utils

* E instalamos el módulo para compilarlo en nuestro kernel:

apt-get install openvswitch-datapath-source

* Generamos el módulo para nuestro kernel:

module-assistant auto-install openvswitch-datapath

* Instalamos luego la compatibilidad con bridges linux

apt-get install openvswitch-brcompat openvswitch-common

* Completamos la instalación de openvswitch:

apt-get install openvswitch-switch

* Verificamos, que luego de instalado e iniciado, nos muestre la versión:

ovs-vsctl show
1dad3b56-0a78-4513-8480-be086ef042f7
ovs_version: "1.4.2"

Y Reiniciamos:

/etc/init.d/openvswitch-switch restart
[ ok ] ovs-brcompatd is not running.
[ ok ] Killing ovs-vswitchd (7353).
[ ok ] Killing ovsdb-server (7302).
[ ok ] Starting ovsdb-server.
[ ok ] Configuring Open vSwitch system IDs.
[ ok ] Starting ovs-vswitchd.

Con lo que ya tendremos openvswitch instalado en nuestro equipo.

Creando un bridge en Debian

Para crear un bridge contamos con tres formas, de la manera tradicional (en el archivo /etc/network/interfaces), con la herramienta tradicional bridge-utils o con los comandos propios de openvswitch.

Agregando una definición de bridge:

La definición de un bridge utilizando el archivo /etc/network/interfaces es igual a la forma tradicional, tomando en cuenta que todo bloque de definición debe empezar con la sentencia “allow-ovs” y el nombre de la interfaz, ejemplo:

auto br0
allow-ovs br0
iface br0 inet static

Además, cada puerto asociado a un bridge (por ejemplo) deben ser incorporados a ovs, ejemplo:

allow-hotplug eth0
allow-br0 eth0
iface eth0 inet manual

Donde “allow-${bridge}” representa el nombre del bridge padre.

Ejemplos:

* Un bridge autónomo:

auto br0
allow-ovs br0
iface br0 inet static
   address 172.16.20.1
   netmask 255.255.255.0
 # bridge info
   ovs_type OVSBridge
   ovs_ports eth0
   bridge-ports eth0
   bridge-maxwait 1

Fijese en la opción ovs_type, puede ser OVSBridge, OVSPort, OVSIntPort u OVSBond de acuerdo a lo que  deseamos construir, también fijese que podemos mezclar con opciones compatibles con kernel bridge sin problemas.

Luego de definido un bridge, podemos definir un puerto (interfaz añadida al bridge):

# eth0
allow-hotplug eth0
allow-br0 eth0
iface eth0 inet manual
   ovs_bridge br0
   ovs_type OVSPort

Al reiniciar las interfaces, podemos ver su incorporación a OVS:

ovs-vsctl show
1dad3b56-0a78-4513-8480-be086ef042f7
 Bridge "br0"
       Port "eth0"
               Interface "eth0"
       Port "br0"
               Interface "br0"
        type: internal
 ovs_version: "1.4.2"

Agregando una definición de bond

Construir un bond es semejante en forma a la construcción de un bridge, tomando en cuenta que debemos encender las interfaces esclavas y configurar la pertenencia del bond a un bridge.

Definimos el bond:

auto bond0
allow-br0 bond0
iface bond0 inet manual
   ovs_bridge br0
   ovs_type OVSBond
   ovs_bonds eth0 eth1
   ovs_options bond_mode=balance-tcp lacp=active
   bond-miimon 100

Definimos las esclavas del bond (para que estén activas cuando este se cree):

auto eth0
iface eth0 inet manual
  bond-master bond0
auto eth1
iface eth1 inet manual
  bond-master bond0

Y por último, el bridge que gestionará el bond:

auto br0
allow-ovs br0
iface br0 inet static
   address 172.16.20.1
   netmask 255.255.255.0
   ovs_type OVSBridge
   ovs_ports bond0

Usando los comandos OVS para construir un bridge

Podemos crear un bridge fácilmente utilizando el comando “ovs-vsctl” siguiendo los siguientes pasos:

ovs−vsctl add−br br0
ovs−vsctl add−port br0 eth0

Aunque, podemos hacer ambas operaciones en una sola línea:

ovs−vsctl add−br br0 −− add−port br0 eth0

Nota: El double dash (–) es un separador entre opciones y comandos.

Podemos ver la interfaz con el comando “ovs-vsctl show” o utilizar el comando tradicional “brctl show”

brctl show
bridge name                bridge id                       STP enabled                           interfaces
br0                               8000.f0def1919e43             no                                     eth0

Definiendo una VLAN en un bridge

Para crear un bridge asociado a una VLAN, agregamos una interfaz interna etiquetada con el número de la VLAN:

* Creamos el bridge:

ovs-vsctl add-br br0

* Incorporamos una interfaz interna, etiquetada con el número de la VLAN (ejemplo, VLAN10):

ovs-vsctl add-port br0 vlan10 tag=10 -- set interface vlan10 type=internal

* Configuramos la interfaz:

ifconfig vlan10 192.168.10.254 netmask 255.255.255.0

Y listo!.

QoS sobre una interfaz en openVSwitch

También podríamos crear una regla de QoS sobre el ancho de banda de las interfaces participantes en un bridge, por ejemplo; podríamos definir una regla para limitar el ancho de banda de la interfaz eth0 a 10Mbps:

* Limitamos la interfaz eth0 a un máximo de Kbps que puede enviar (10000=10Mbps).

ovs-vsctl set interface eth0 ingress_policing_rate=10000
ovs-vsctl set interface eth0 ingress_policing_burst=1000

* Podemos también hacerlo a través la opción qos de un puerto;

ovs-vsctl -- set port eth0 qos=@newqos -- --id=@newqos create qos type=linux-htb other-config:max-rate=5000000 queues=0=@q0 
-- --id=@q0 create queue other-config:max-rate=5000000

Conclusiones

Espero les haya servido esta guía como a mí, yo no soy muy dado al área de redes, pero desde que estoy experimentando con virtualización (Xen, XCP-XAPI, KVM) pues he aprendido mucho acerca del control y gestión automatizado de interfaces; espero les sea de provecho.

Happy Hacking!

[Linux] De las comparativas (benchmarks) y otras justificaciones

Introducción

En un comentario anterior, el compañero Piccoro, hace una remembranza de unas pruebas de rendimiento que hiciera hace ya mucho Sun Microsystems  (antes que la comprara Oracle Corp.) sobre sus conocidos equipos SunFire, estas pruebas de rendimiento (conocidas como las “SPECjAppServer2004″) realizadas en 2007, ahora no están al alcance del público (aunque pueden aún ser encontradas en mi dropbox) pero demuestran el rendimiento de una misma aplicación, optimizada en estos equipos para Oracle, postgreSQL y MySQL.

¿Qué descubrimos con esta prueba?, veamos!.

La prueba Java (antes que fuera de Oracle)

MySQL 5 fué instalado en un equipo con las siguientes características:

  • Sun Fire X4100 (2×285,4x2GB,2X73GB) (2)
  • Sun StorEdge 3320, 12x73GB, 1 RAID CONT
  • Single-Port PCI Ultra320 SCSI HBA

Costo de la Licencia: 0$
Costo de implantación : 59.260 US$
MySQL: 720 JOPS

PostgreSQL 8.2 fué instalado con estas características:

  • Server HP Integrity rx2660 1.6Ghz 18GB 4-core (2)
  • 12GB DDR2 memory pair
  • SAN Array 1000

Costo de la Licencia: PostgreSQL 8.2 (0 US$)
Costo: 70.701 US$
Puntaje: 778 JOPS

Y Oracle 10g fué instalado con las siguientes características (semejantes a PostgreSQL)

  • Server HP Integrity rx2660 1.6Ghz 18GB 4-core (2)
  • 12GB DDR2 memory pair
  • SAN Array 1000

Costo de implementación: 70.701 US$
Licencias: Oracle 10g Enterprise + Oracle App Server + Oracle Partition Option
Costo en Licencias: 120.000 US$
Puntaje: 874 JOPS

Las pruebas, aunque en el mismo hardware físico gana Oracle (por al menos unos 70 puntos), demuestran que necesitas gastar 200US$ por unidad adicional para poder implementar Oracle, es decir, que con el costo *únicamente* de las licencias Oracle podrías incorporar 2 nodos más al cluster postgreSQL; qué, manteniendo la proporción de crecimiento, implementar un único servidor Oracle a 874 JOPS cuesta lo mismo que implementar un cluster de 3 nodos postgreSQL (ejecutandose a un rendimiento de 2334 JOPS).-

¿Cierto o falso?, queda a criterio del lector, la EULA de Oracle prohibe terminantemente la realización de pruebas y publicación de resultados sin su autorización, so-pena de recibir acciones legales, pero como yo no hice el benchmark! ;)

pero revisemos otro benchmark.

Cuándo VMWare decidió no publicar “malos benchmarks”

En una aclaratoria en su blog, la gente de VMWare explica que la clausula de la EULA (End-User License Aggrement) donde se prohíbe terminantemente la publicación de benchmarks de su producto versus otros productos de virtualización, no es porque “ellos estén en contra de las pruebas”, sino que le “sugieren amablemente” a las empresas encargadas de hacerlas, a que optimicen su producto y sólo utilicen el hardware que a “ellos” les es más conveniente, ¿interesante, no?.

Hace ya algún tiempo, la gente de specs.org publicaron una comparativa entre VMware ESX, la solución de virtualización para datacenters, y Linux KVM sobre Red Hat 6.1, resumiendo la conclusión:

KVM: SPECvirt_sc2010 1820 @ 114 VMs

VMWare: SPECvirt_sc2010 2721 @ 168 VMs

114 máquinas virtuales versus 168 es bastante, ¿no?, 900 puntos de diferencia en cuánto a rendimiento, también, ¿verdad?, pero, veamos a los detalles:

Primero, el equipo “sugerido” por VMWare para la prueba:

CPU: Intel(R) Xeon(R) X7560
Velocidad: (MHz) 2266
Núcleos: 32 cores, 4 chips, 8 cores/chip, 2 threads/core

Y el equipo con Red Hat:

CPU: Intel Xeon E7-2870
Velocidad: (MHz) 2400
Núcleos: Cores 20 cores, 2 chips, 10 cores/chip, 2 threads/core

El último es un simple HP Proliant Generación 7 (a un costo de 16800US$), el primero es un equipo ensamblado “especificamente” para VMWare, por su partner Bull Novascale, el “Novascale Bullion” fué catalogado como “el equipo para datacenter x86 más rápido del mundo” en 2011 y tiene un costo de 25 mil dólares la unidad.

Si a eso le sumamos la licencia de VMWare ESXi (9200 dólares por cada 2 núcleos), la cosa quedaría *más o menos* así:

KVM: Red Hat Licencias (Server=6500$ + Virtualización=6700) = 13200$
Servidor: 16800$
Total: 30000 US$
Costo: 263 dólares por VM (máquina virtual)

VMWare: Licencia=9200$ x 16 cores = 147200US$
Servidor: 25000 US$
Total: 172200 US$
Costo:  1025 US$ por VM (máquina virtual)

Entonces, ¿dónde está el rendimiento y el abaratamiento de precios?, además, hagamos algo bastante “jocoso”, reemplacemos Red Hat por Debian Linux (que el valor de siu licencia es “0$” – se lee cero!-) y te darás cuenta que por el mismo precio de la implementación de VMWare en tu empresa podrías pagar 11 servidores Proliant con GNU/Linux, ¡En vez de un equipo, tendrías un datacenter!  donde podrías en promedio (y según las cifras de Debian) virtualizar 990 máquinas virtuales.

A mí, me enseñaron que 990 VMs > (se lee, “es mayor qué”) 168 VMs, ¿no creen?.

Saquen ustedes sus propias conclusiones.

Xen 4 y Debian: corrigiendo algunos detalles

Instalar Xen 4.x en Debian GNU/Linux es bastante sencillo (el metapaquete xen-linux-system), ahora bien, configurar para hacer funcionar otras cosas es otra tarea distinta; por ejemplo, encontrarán que 6 cosas no  funcionan “a la primera” en Debian y deberá corregirlas para disfrutar al máximo de Xen 4.x:

1.- Habilitando XenAPI y accediendo con virt-manager

Virt-manager es la herramienta gráfica para libvirt (librería para acceso a servicios de virtualización, integra KVM, Qemu, Xen, LXC, openVZ y hasta VMWare) diseñada por la gente de Red Hat y que raya en lo infantil por su facilidad de uso para gestionar sistemas virtualizados, sin embargo, notaremos que luego de instalarlo, no podremos acceder a nuestro sistema Xen.

Para acceder con virt-manager (luego de instalado virt-manager y libvirt-bin) es activar el acceso por la API de Xen:

Editamos:

archivo: /etc/xen/xend-config.sxp

Y habilitamos http-server (en el puerto 8000, es el que usa libvirt), descomentamos (y ponemos en “yes”):

(xend-http-server yes)

Nota: si desean acceder desde cualquier equipo con libvirt (y no solo desde localhost), agregan esta línea:

(xend-address ”)

Posteriormente, debemos agregar al usuario con el que vamos a acceder al dominio Xen al grupo libvirt (ojo: esto como medida de seguridad para no acceder con el usuario root):

adduser jesuslara libvirt

E instalamos los paquetes necesarios para virt-manager y para que este nos interrogue por nuestra contraseña:

aptitude install virt-goodies ssh-askpass ssh-askpass-gnome

Listo!, ya podremos conectarnos a nuestro Xen vía un tunel remoto SSH (accedemos a “Archivo > Nueva Conexión  y seleccionamos Xen y modo “Tunel SSh Remoto”), usando nuestro usuario y nuestra contraseña.

2.- Creando VMs, configurando virt-manager

Una cosa que debemos configurar antes de empezar a crear máquinas con virt-manager, es indicarle en qué forma creamos los discos de las máquinas virtuales, esto se hace en el menú “Detalles” de la conexión al servidor Xen:

En esta ventana hay una pestaña que dice “almacenamiento”, donde podrán indicar si se crean volúmenes LVM, archivos de imagen en disco, etc

He creado 3 tipos de almacenamiento, un grupo de volúmenes LVM (para las máquinas virtuales), un espacio en disco (en /srv/xen) para aquellas máquinas que crearé usando archivos .img (imágenes qcow exportables) y una carpeta especial, donde he copiado los ISO de todos los sistemas operativos que utilizaré, así los podré usar rápidamente cada vez que quiera crear una nueva VM.

Ya con esto (Y la red), podrán crear máquinas virtuales.

3.- Creando VMs con HVM (virtualización completa) en virt-manager

Cuando intentan crear una VM HVM (que requiera virtualización completa, ejemplo, un Windows) con virt-manager, este emitirá un error de que no encuentra qemu-dm, esto es debido a que Xen utiliza una forma modificada de KVM y el ejecutable (aunque instalado, se llama “xen-qemu-dm-4.0″) no se encuentra en el lugar que espera virt-manager, esto se resuelve fácilmente con un enlace simbólico:

ln -s /usr/lib64/xen-4.0 /usr/lib64/xen

Y listo!, ya pueden crear máquinas usando HVM, fijense en este equipo freeBSD:

4.- virt-manager y “xm new” no funciona

“xm create” es la forma “usual” como creamos VMs en Xen, sin embargo, esto tiene un inconveniente, la VM es “creada” cada vez que se inicia y “destruida” (léase mejor, retirada de la lista de dominios administrados) del gestor de dominios Xen cada vez que se apaga, debido a esto, la VM no puede ser gestionada vía la XenAPI o vía gestores externos basados en libvirt (como virt-manager).

Este es un error heredado de Xen 3.x, cuando ejecutamos “xm new” aparece el siguiente error:

xm new -f test.cfg

Unexpected error: <type ‘exceptions.ImportError’>
Please report to xen-devel@lists.xensource.com
Traceback (most recent call last):
File “/usr/lib/xen-4.0/bin/xm”, line 8, in <module>
main.main(sys.argv)
File “/usr/lib/xen-4.0/lib/python/xen/xm/main.py”, line 3620, in main
_, rc = _run_cmd(cmd, cmd_name, args)
File “/usr/lib/xen-4.0/lib/python/xen/xm/main.py”, line 3644, in _run_cmd
return True, cmd(args)
File “<string>”, line 1, in <lambda>
File “/usr/lib/xen-4.0/lib/python/xen/xm/main.py”, line 1449, in xm_importcommand
cmd = __import__(command, globals(), locals(), ‘xen.xm’)
File “/usr/lib/xen-4.0/lib/python/xen/xm/new.py”, line 26, in <module>
from xen.xm.xenapi_create import *
File “/usr/lib/xen-4.0/lib/python/xen/xm/xenapi_create.py”, line 22, in <module>
from xml.parsers.xmlproc import xmlproc, xmlval, xmldtd
ImportError: No module named xmlproc

Esto es debido a la ausencia del módulo xmlproc de python, sin embargo, cuando intentamos instalarlo ocurre esto:

apt-get install python-xml
Leyendo lista de paquetes… Hecho
Creando árbol de dependencias
Leyendo la información de estado… Hecho
El paquete python-xml no está disponible, pero algún otro paquete hace referencia
a él. Esto puede significar que el paquete falta, está obsoleto o sólo se
encuentra disponible desde alguna otra fuente
E: El paquete «python-xml» no tiene un candidato para la instalación

El paquete ya no existe (porque fué reemplazado por python-lxml) y porque xmlproc ya no está en esa librería, sin embargo, como XMLproc es utilizado simplemente para validar el DTD de los archivos XML generados por xenAPI (y eso no es un “error fatal” que afecte la creación de la VM administrada) entonces;  para hacerlo funcionar, simplemente abrimos el archivo:

archivo : /usr/lib/xen-4.0/lib/python/xen/xm/xenapi_create.py

Y editamos la línea 22, comentándola:

#from xml.parsers.xmlproc import xmlproc, xmlval, xmldtd

Cuando ejecutamos:

xm new -f test.cfg 
Using config file "./test.cfg".

Ahora veremos que la VM test está incorporada al administrador Xen permanentemente (permitiendo ser gestionada por la API vía xenapi o vía libvirt):

xm list
Name        ID  Mem    VCPUs    State Time(s)
Domain-0    0   2752   2        r----- 90.2
freebsd         512    1               0.0
test            256    1               0.0
winxp           1250   2               1358.4

Nótese que las VMs gestionadas por XenAPI no tienen ID si están apagadas, para encenderlas indicamos:

xm start test

Y veremos que la VM “test” se inicia, incluso podemos gestionarla vía libvirt (ej: virt-manager):

Nota: ¿y cómo editamos un domU administrado?, si contamos con el archivo cfg, entonces simplemente eliminamos el dominio:

xm delete test

Y lo volvemos a incorporar con xm new.

Si no contamos con el archivo cfg (porque tal vez lo creó otra herramienta) entonces debemos editar el dominio en “/var/lib/xend/domains/”, recuerde, sin embargo, que este archivo tiene la forma “SXP” (un parser a XML hecho en perl para sablotron, que permite persistencia de objetos en un pseudo-lenguaje de marcado), como esta:

(domain
(domid 3)
(vcpus_params ((cap 0) (weight 256)))
(PV_args ‘root=/dev/xvda2 ro ip=:127.0.255.255::::eth0:dhcp ‘)
(PV_bootloader )
(cpus (()))
(memory_sharing 0)
(superpages 0)
(VCPUs_live 1)
(actions_after_crash restart)
(uuid 6257207b-6831-ddcd-a21d-010a5fb77070)
(PV_ramdisk /boot/initrd.img-3.2.0-0.bpo.2-amd64)

5.- Mi VM Windows es lenta, ¿cómo hago?

Una de las razones por las cuáles la gente usa VMWare, es qué, como toda herramienta privativa, accede a información confidencial a la cual no acceden empresas dedicadas al software libre, esto es, VMWare “inyecta” drivers Windows WHQL para que el acceso a red, disco y video de la máquina virtual sea más rápido, sin embargo, desde 2011 eso es posible en Xen también!, ya que un joven hizo “ingeniería inversa” de los drivers Microsoft Windows para Hyper-V y existe una versión “libre” de los drivers para Windows, se llaman los Xen PV Drivers y al instalarlos en la VM con Windows, modificarán el acceso al “disco virtual” y a la “red virtual” de manera notable.

Para instalarlo, descargue la versión necesaria para la versión de Windows que instaló acá:

http://www.meadowcourt.org/downloads/

Antes de instalar, la tarjeta de red se ejecuta a 100Mbps, el acceso a disco en modo “IDE” y la tarjeta de video era cirrus;

Instale a la VM Windows, verá al instalar:

 

5.- Quiero cambiar de CDROM en virt-manager

Una de las cosas más frustrantes que te puedes encontrar, es que si intentas cambiar el CDROM (expulsar->desconectar en virt-manager) este te pedirá que reinicies la VM, esto debido a que el CDROM es tratado como “un disco más”, sin embargo, es posible cambiar de CDROM en una VM encendida; para ello:

1.- Expulsamos el CDROM en el sistema operativo

2.- Cambiamos a la cónsola de virt-manager (CTRL+ALT+2 en la ventana de la máquina virtual)

3.- Expulsamos (desconectamos) el CDROM en Virt-manager:

(qemu) eject hdc

4.- Montamos el nuevo disco, si es una imagen ISO, escribimos:

(qemu) change hdc /path/to/file.iso

Si es un CD en una unidad de CD-ROM, la ruta física a la unidad

(qemu) change hdc /dev/sr0

5.- Volvemos al sistema operativo y montamos la unidad de CDROM

Conclusiones

Espero que estos trucos les sirvan, a mí me han salvado un mundo en trabajo con virtualización Xen y como siempre, los publico acá por si alguien más los necesita.

Happy Hacking!

[Linux] LXC: La “virtualización” barata

¿Qué es LXC?

LinuX Containers, una tecnología de contenedores que permite crear jaulas aisladas, una jaula contenedora es un sistema GNU/Linux auto-contenido dentro de otro, al que se le pueden aplicar cuotas de disco, CPU, memoria y algunos límites y capacidades, asignarle una (o varias) interfaces de red e “iniciarlo” como si fuera un equipo independiente.

LXC es construido encima de una jaula (chroot) y proporciona un sistema virtual completo, con mecanismos de “aislamiento e individualización” (isolation) que son completamente nativos al kernel Linux.

A diferencia de una virtualización al estilo de Xen, una “virtualización” basada en contenedores solamente puedes levantar el sistema operativo del host (en este caso, GNU/Linux), sin embargo, se puede levantar diversas “versiones” de GNU/Linux, al estilo de openVZ, con LXC se pueden levantar contenedores “compatibles” en Linux basados en Fedora, CentOS o Ubuntu y a diferencia de openVZ,  no requieren un micro-kernel o un parche completo al kernel Linux, ya que se basa exclusivamente en una tecnología de espacios y grupos (CGROUPS) que es nativa del kernel Linux desde el 2.6.30 y cualquier equipo con un kernel 2.6.30 (o superior), CGROUPS habilitado y los scripts de LXC puede comenzar a crear contenedores.

Se conoce como una “virtualización barata” puesto que no se requiere mucho recurso para levantar un contenedor LXC, consumen mucho menos que una maquina completa Xen y un poco menos que openVZ puesto que LXC se basa en un “chroot aislado y mejorado”, se pueden levantar docenas de “mini-máquinas virtuales” en un simple host.

¿Para qué usaríamos LXC?

A diferencia de openVZ, LXC no requiere un kernel “parcheado” (incluso un kernel Xen puede levantar recursos LXC), sin embargo, LXC no es una tecnología muy “completa”, por ejemplo, a diferencia de openVZ, no se pueden limitar capacidades de manera granular y específica y el kernel “oficial” de Debian estable (Squeeze 6.02) no posee por ejemplo habilitado el control de memoria (cgroup.memory).
Aún asi, LXC es muy útil para iniciar servicios aislados que anteriormente utilizabas una jaula chroot (como DNS) o aquellos que por su bajo consumo de recursos podrían correr perfectamente sobre una jaula LXC, algunos ejemplos serían: DNS, DHCP, Kerberos, Entidad Certificadora, pero que ahora, teniendo su propia reserva de recursos y su propia IP, podrás correrlo de manera aislada y segura.

¿Qué necesitamos?

LXC corre muy bien en Debian Squeeze estable, incluso sobre el kernel Xen 2.6.32, sin embargo, las herramientas para crear “contenedores” están bastante “desfasadas”, yo me hice mi propio script bash que crea un contenedor LXC de Debian usando debootstrap, tengo ya algo más de año y medio con ese script y lo pongo a disposición de quien lo necesite.

Si deseas “experimentar”, tendrás que saber que los núcleos 3.01 y 3.02 fallaron en su configuración de CGROUPS namespaces para soportar claramente LXC (Debian bug) y si desean utilizarlo conjuntamente con Xen, tendrán que subir hasta la última versión en backports, o sea:

  • * linux-image-3.2.0-0.bpo.1-rt-amd64
  • * cgroups habilitado
  • * xen-linux-system-3.2.0-0.bpo.1-rt-amd64
  • * lxc 0.7.5-24

Sin embargo, luego de algunas pruebas, he notado que ambos (Xen 4.1 sobre Kernel 3.2) y LXC (versión 7.4 en adelante) pueden coexistir pacíficamente:

xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  2985     4     r—–    541.9
ldap                                         1   256     1     -b—-     24.1

Y en el mismo equipo, LXC:

lxc-ls
cache
vm1

LXC-Tools: creando contenedores

LXC incorpora algunas “plantillas” para crear contenedores, pero están bastante desatendidas (aún en Wheezy, se consiguen plantillas solamente para crear VMs en Debian Lenny), por lo que hemos creado una serie de scripts que permiten crear contenedores para Debian Squeeze o Wheezy sobre un servidor con CGROUPS y LXC < 0.7.4.

Con LXC > 7.4 lxc-create incorpora la posibilidad de crear contenedores Debian incluso sobre Debian Sid, del que hablaremos en el siguiente capítulo.

Hay que tomar en cuenta que las cosas no se quedan ahí, ya que podemos crear contenedores para cualquier versión de GNU/Linux Debian-Based utilizando debootstrap (Ubuntu, Canaima) y podemos crear Fedora o CentOS utilizando rpmstrap, pero a su vez, una template para openVZ/proxmox (con algunos cambios) es compatible con una VPS LXC, por lo que veremos algunos avances en los scripts de lxc-tools.

Instalando lxc-tools

Tome nota que para poder utilizar contenedores LXC debería cumplir algunas cosas:

* Montado los CGROUPS (tip: agregar esta línea en el archivo /etc/fstab “none /sys/fs/cgroup cgroup defaults 0 0″)
* Instalado paquete LXC
* La forma más fácil de configurar red, es a través de un bridge, debe existir uno configurado (vea: mi artículo sobre virtualización)
* La interfaz bridge debe estar activa (revisar: “brctl show”)

Instalamos las dependencias del script:

apt-get install lxc lsb-release

Descarguen lxc-tools desde su fuente en Gitorious:

git clone https://git.gitorious.org/lxc-tools/bash_version.git

Cambie el modo a ejecutable al script principal:

chmod +x lxc-tool

y ya estamos listos para utilizarlo!.

Usando lxc-tools

lxc-tools viene con un archivo de configuración que permite definir ciertas opciones del script como por ejemplo el tamaño del contenedor, la versión de GNU/Linux (default: Debian), la Suite (default: squeeze) y otras opciones como el grupo de volumen donde crear la VM (TODO: en próxima entrega crearé contenedores directamente en un directorio); sin embargo, el script tratará de auto-descubrir la mayoría de las opciones necesarias.

Crear una VM es tan fácil como ejecutar:

lxc-tool create -n nombre

Este hará las preguntas necesarias y las otras las tomará del archivo de configuración o las autodetectará.

Notas: lxc-tools son unos scripts que tuve más de un año desatendidos, por unas necesidades inmediatas, hice algunos cambios y estaré agregando otros (como la creación de VMs a partir de plantillas de proxmox u openvz), sin embargo, la template para Debian incorporada en LXC 0.7.4 es realmente superior!.

Usando LXC

El comando más básico que deben conocer es “lxc-checkconfig”, este permite verificar si la configuración de nuestro Kernel Linux corresponde a las necesidades de LXC:

lxc-checkconfig

Verán una salida semejante a esta:

Kernel config /proc/config.gz not found, looking in other places…
Found kernel config file /boot/config-3.2.0-1-amd64
— Namespaces —
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: enabled

— Control groups —
Cgroup: enabled
Cgroup namespace: required
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled

— Misc —
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled

Note : Before booting a new kernel, you can check its configuration
usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig

Si CGROUPS está activo y el kernel soporta LXC, al instalar LXC podremos comenzar a crear VMs.

* Creando una VM:

lxc-create -n nombre -t [debconf|ubuntu|debian]

Donde:

-n : nombre que le daremos al conenedor

-t : template de construcción (debconf, debian base o ubuntu)

* Iniciando una VM:

lxc-start -n nombre

* Deteniendo una VM:

lxc-stop -n nombre

* Listando las VMs activas y creadas:

lxc-ls

Si desean una guía completa de LXC, revisen acá http://lxc.teegra.net/

Conclusiones

LXC se levanta como una alternativa fácil (de gestionar, de trabajar, de configurar, de mantener) a otros sistemas de virtualización/contenedores) su incorporación al ecosistema LIBVIRT nos permite administrarlo fácilmente con cualquier herramienta diseñada para usar libvirt (ej. virt-manager) y su bajo consumo de recursos permite ser pensado para virtualizar en entornos donde otras tecnologías serían imposibles de lograr (ejemplo: ¿se imaginan virtualizar contenedores LXC dentro de una Tablet Android para paralelizar tareas?).

TODO: ¿sería posible crear contenedores Fedora/CentOS desde cero si incorporamos rpmstrap a la fórmula?, ¿será posible incorporar LXC a un sistema Dual-Core Nvidia-Tegra 2 de una tablet?

Prueben y opinen sobre LXC, y como siempre:

Happy Hacking!

[Linux] juntando varias las tecnologías de virtualización (I)…

Virtualización

Como lo dice la Wikipedia:

Virtualización se refiere a la abstracción de los recursos de una computadora, llamada Hypervisor o VMM (Virtual Machine Monitor)

Con la virtualización, podemos iniciar diversas máquinas “virtuales” sobre un único recurso físico.

¿Qué ventajas tiene esto?

Muchas, empezando por el ahorro de recursos, energía, la sobre-utilización óptima de hardware (hasta un 90% más que sobre hardware no-virtualizado).

Tecnologías de virtualización

Hay tecnologías de virtualización de diversos tipos, basadas en software (emulación o emulación asistida), en hardware y las para-virtualizaciones, encontrarás mucha información en la Wikipedia y otros artículos.

¿De qué se trata todo esto?

Se busca ahorrar el máximo de recursos, para ello, se unifican en un único equipo GNU/Linux Debian Squeeze,  las más populares plataformas de virtualización libres existentes, en este caso tendremos:

  1. Virtualización por contenedores (LXC)
  2. Tecnología de para-virtualización (Xen)
  3. Una tecnología de emulación (QEMU)
  4. Virtualización por software (VirtualBox)
  5. Virtualización completa (KVM / Xen HVM)

¿Por qué unificar?

Las tecnologías de para-virtualización y virtualización completa son útiles para gestionar recursos de sistemas operativos diversos, o para virtualizar versiones de GNU/Linux que requieren acceso a recursos de manera muy heterogénea, pero para máquinas virtuales basadas en GNU/Linux que consumen pocos recursos (un servidor DHCP, NTP, DNS, una entidad certificadora sencilla, etc) tener todo un sistema operativo virtualizado con disco, RAM y CPU es ineficiente y el uso de tecnologías de contenedores es lo mejor.

No se imaginan la cantidad de entidades públicas que hacen “magia” para administrar sus recursos de servidores de manera eficiente, en algunos casos terminan tomando un viejo CPU 586 para montar un DHCP, lo que incluye un equipo “más” para adminsitrar, más uso de energía eléctrica, más sobrecalentamiento del datacenter (con un mayor consumo de energía en enfriamiento) y otra cantidad más de desventajas.

Tecnologías de virtualización

LXC

Tecnología de “contenedores”, más que una “virtualización” es una “contextualización”, aislamiento en un contexto específico (CHROOT) de una versión de GNU/Linux imbuida (VPS) en el interior de otra.  (HOST)
Dentro de los contenedores reside otra versión de GNU/Linux, la cual posee su propia interfaz de red, se pueden aplicar cuotas de disco/CPU/RAM y se pueden detener, apagar y/o suspender.
Es un “chroot” mejorado puesto que las facilidades de administración y ejecución basadas en chroot (lxc-execute) pueden ser utilizadas para LXC, también las tecnologías de creación de espacios aislados (isolated) como debootstrap (Debian|Ubuntu), rpmstrap (Fedora,CentOS) pero con las capacidades de virtualización que incopora LXC.
OpenVZ es otra tecnología de contenedores existente, pero a diferencia de LXC, openVZ requiere todo un parche del Kernel y un subsistema propio para trabajar (además de al ser una versión libre de un sistema comercial, virtuozzo, no ha tenido mucho empuje).
LXC es nativa en el Kernel Linux a partir de la versión 2.6.32 y utiliza características nativas del Kernel Linux como los CGROUPS y los Namespaces.
También está soportada por Libvirt, de tal manera que cualquier plataforma de gestión que utilice libvirt, sera capaz de administrar VPS construidos con LXC.

Nota: LXC es compatible con las templates de OpenVZ y Proxmox.

Instalación de LXC

La instalación de LXC es bastante sencilla:

aptitude install lxc

Configuración de LXC

* crear el directorio de los contenedores y configuraciones:

mkdir /srv/lxc

* Configurar /etc/default/lxc para que inicie al arranque y utilice el directorio de configuraciones:

# Comment out to run the lxc init script
RUN=yes
# Directory containing the container configurations
CONF_DIR=/srv/lxc

* verificar que tenemos soporte para CGROUPS en el kernel

cat /proc/filesystems | grep cgroup
nodev    cgroup

Y

cat /proc/cgroups 
#subsys_name    hierarchy    num_cgroups    enabled
cpuset    0    1    1
ns    0    1    1
cpu    0    1    1
cpuacct    0    1    1
devices    0    1    1
freezer    0    1    1
net_cls    0    1    1

* Montar CGROUPS en el directorio /sys/fs/cgroup/
(Debian Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604635)

mount -t cgroup none /sys/fs/cgroup

Y verificamos que ha montado correctamente:

/sys/fs/cgroup/
├── cgroup.procs
├── cpuacct.stat
├── cpuacct.usage
├── cpuacct.usage_percpu
├── cpuset.cpu_exclusive
├── cpuset.cpus
├── cpuset.mem_exclusive
├── cpuset.mem_hardwall
├── cpuset.memory_migrate
├── cpuset.memory_pressure
├── cpuset.memory_pressure_enabled
├── cpuset.memory_spread_page
├── cpuset.memory_spread_slab
├── cpuset.mems
├── cpuset.sched_load_balance
├── cpuset.sched_relax_domain_level
├── cpu.shares
├── devices.allow
├── devices.deny
├── devices.list
├── net_cls.classid
├── notify_on_release
├── release_agent
└── tasks

Posteriormente, fijar el montaje en el /etc/fstab

none    /sys/fs/cgroup    cgroup   cpuset,cpu,memory,cpuacct,devices,freezer,net_cls    0 0

Y en las udev, para que pueda ser creado durante el proceso de arranque:

mkdir /lib/udev/devices/cgroup

* Montar las librerías de gestión de cgroups

aptitude install libcgroup1

– Y reiniciamos el equipo.

– luego, podemos verificar con lxc-checkconfig para determinar si está bien soportado CGROUPS y LXC:

lxc-checkconfig 
Kernel config /proc/config.gz not found, looking in other places...
Found kernel config file /boot/config-2.6.32-5-xen-amd64
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: enabled
--- Control groups ---
Cgroup: enabled
Cgroup namespace: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: missing
Cgroup cpuset: enabled
--- Misc ---
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled

Nota: tomen en cuenta que el soporte para gestionar memoria via CGROUPS está desactivada en kernel Linux inferiores a 2.6.35.

Xen

Gestor de máquinas virtuales de código abierto, diseñado para dar virtualización con aislamiento seguro y todas las características de un sistema operativo.
Xen utiliza para-virtualización, es este caso, tanto el host como el cliente sufren “modificaciones” a nivel de su kernel para poder ejecutarse e interactuar con un mínimo de penalty en el rendimiento.
Mediante técnicas de paravirtualización, un host puede ejecutar núcleos modificados de Linux, NetBSD y FreeBSD.
Virtualización Completa: Se incorpora a Xen la posibilidad de utilizar las tecnologías de virtualización asistida por Hardware (CPU) de Intel-VT y AMD-V, con lo cual se permite ejecutar clientes “no-modificados” sobre la máquina host, con esta técnica se puede ejecutar cualquier sistema operativo.
A partir del kernel 2.6.32, todo kernel Linux puede ser ejecutado “paravirtualizado” sobre un hypervisor, puesto que los “parches” de soporte para paravirtualización han sido incorporados al upstream del kernel.

Instalación de Xen

* paquetes requeridos:

aptitude install xen-tools xen-qemu-dm xen-utils \
xen-utils-common xenstore-utils xen-linux-system \
xen-hypervisor

*  Debemos reiniciar con el nuevo kernel Xen 4.0

Nota: GNU/Linux Debian coloca el Kernel Xen 4.0 de cuarto en la lista del grub (y no de primero), así que habrá que modificar las reglas del grub en /etc/default/grub).

Al iniciar, verificamos que estamos en el nuevo kernel:

uname -r
2.6.32-5-xen-amd64

Y las capacidades que soporta Xen:

xm info
host                   : lab.cantv.com.ve
release                : 2.6.32-5-xen-amd64
version                : #1 SMP Wed Jan 12 05:46:49 UTC 2011
machine                : x86_64
nr_cpus                : 2
nr_nodes               : 1
cores_per_socket       : 2
threads_per_core       : 1
cpu_mhz                : 1596
hw_caps                : bfebfbff:20100800:00000000:00000940:0000e3bd:00000000:00000001:00000000
virt_caps              : hvm
total_memory           : 4022
free_memory            : 900
node_to_cpu            : node0:0-1
node_to_memory         : node0:900
node_to_dma32_mem      : node0:834
max_node_id            : 0
xen_major              : 4
xen_minor              : 0
xen_extra              : .1
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : placeholder
cc_compiler            : gcc version 4.4.5 (Debian 4.4.5-10) 
cc_compile_by          : waldi
cc_compile_domain      : debian.org
cc_compile_date        : Wed Jan 12 14:04:06 UTC 2011
xend_config_format     : 4

Entre las que se cuenta, virt-caps: HVM (soporte a virtualización por Hardware para arquitecturas x86 y x86_64).

Configuración

Editamos el archivo /etc/xen/xend-config.sxp y habilitamos el demonio XML-RPC (que utilizar libvirt, virt-manager y otras herramientas para gestionar Xen).

(logfile /var/log/xen/xend.log)
(xend-unix-server yes)
(xend-tcp-xmlrpc-server yes)
(xend-unix-xmlrpc-server yes)
(xend-unix-path /var/lib/xend/xend-socket)
(xend-tcp-xmlrpc-server-address 'localhost') 
# use 0.0.0.0 para escuchar por todas las IP
(xend-tcp-xmlrpc-server-port 8006)
(xend-port            8000)

* Si deseamos que Xen gestione el bridge, descomentamos

(network-script network-bridge)

* Y reiniciamos el demonio xend

/etc/init.d/xend restart

* Verificamos el demonio TCP:

lsof -i tcp
COMMAND    PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
xend      1462        root   32u  IPv4   7423      0t0  TCP localhost:8006 (LISTEN)

Y el socket Unix:

file /var/lib/xend/xend-socket
/var/lib/xend/xend-socket: socket

Con estas modificaciones, ya podemos configurar xen-tools para la creación de máquinas virtuales.

KVM

KVM es una solución para implementar virtualización completa (virtualización asistida por hardware) sobre arquitecturas x86. ha estado presente en el kernel Linux desde la versión 2.6.20
Permite ejecutar maquinas virtuales utilizando imágenes de disco, con Sistemas operativos sin modificar, requiere que soporte virtualización por CPU, tecnologías de AMD-V e Intel-VT.
Intel > E6300, L7000 y T5600
KVM utiliza como “front-end” (panel de administración) una versión modificada de QEMU, aunque recientemente ha incorporado su propio set de librerías.

El módulo del kernel que gestiona la virtualización se llama KVM:

modinfo kvm
filename:       /lib/modules/2.6.32-5-xen-amd64/kernel/arch/x86/kvm/kvm.ko
license:        GPL
author:         Qumranet

Y hay módulos especificos para Intel y AMD:

modinfo kvm_intel
filename:       /lib/modules/2.6.32-5-xen-amd64/kernel/arch/x86/kvm/kvm-intel.ko
license:        GPL
author:         Qumranet
depends:        kvm

NOTA: tome en cuenta que por medidas de seguridad, XEN deshabilita KVM para poder habilitar sus caracteristicas de HVM (basadas en KVM).

Instalación de KVM

Paquetes requeridos:

aptitude install kvm qemu-kvm

* Si su CPU no soporta KVM, verá un mensaje semejante a este:

Your system does not have the CPU extensions required to use KVM. Not doing anything. … failed!

QEMU

Qemu no es una tecnología de virtualización, pero si de emulación de otros sistemas e incluso arquitecturas, permite emular arquitecturas como MIPSEL, ARM, PPC y otras.

Instalación de Qemu

aptitude install qemu grub-firmware-qemu \
etherboot-qemu qemu-system qemu-user qemu-utils \
qemuctl seabios vgabios xen-qemu-dm-4.0

Notas:
* Xen requiere de xen-qemu-dm-4.0 para activar sus capacidades de virtualización completa
* seabios incorpora emulación para diversos tipos de BIOS

VirtualBox

Popular herramienta de virtualización (muy utilizada en Escritorio, aunque puede correr en modo consola mediante la herramienta vboxmanage), desarrollada por Sun Microsystem (actual parte de Oracle Corp) en la cual, se hace uso de la técnica de “virtualización por Sistema Operativo”, esto es, una forma de emulación o “virtualización de nivel 2″, utilizando para ello un “microkernel” para la ejecución de sistemas invitados “no modificados”, su modo, comportamiento y rendimiento es semejante al de VMWare ESX, sin embargo, VMWare ESX levanta su propio Linux 2.4 (basado en Red Hat) y luego su propio microkernel (vmkernel), en cambio, VirtualBox aprovecha el S.O. Linux subyacente e incorpora un módulo de kernel (vboxdrv) para levantar su propio “microkernel”.
Existe una versión GPLv2 llamada VirtualBox OSE edition y es capaz de virtualizar Linux, MS Windows, Sun Solaris, freeBSD y otros.

Instalación

nota: Se requieren los headers del kernel, en nuestro caso:

aptitude install linux-headers-2.6-xen-amd64 \
linux-headers-2.6.32-5-common-xen build-essential fakeroot

Luego de instalado, instalamos virtualbox-OSE (Open Source Edition):

aptitude install virtualbox-ose virtualbox-ose-dkms virtualbox-guest-additions

Nota: con los guest-additions, se incorporan drivers “modificados” para diversos sistemas operativos, que incluyen tarjetas de sonido, video acelerado y otras opciones.

Luego de construido el módulo, este aparece en nuestro kernel:

modinfo vboxdrv
filename:       /lib/modules/2.6.32-5-xen-amd64/updates/dkms/vboxdrv.ko
version:        3.2.10_OSE (0x00140001)
license:        GPL
description:    Oracle VM VirtualBox Support Driver
author:         Oracle Corporation

Y se indica que cargue al arranque en /etc/default/virtualbox-ose

# Set this to 1 if you would like the virtualbox-ose 
# modules to be loaded by the init script.
LOAD_VBOXDRV_MODULE=1

Y verificamos su funcionamiento con:

vboxmanage list systemproperties

Y responde:

Oracle VM VirtualBox Command Line Management Interface Version 3.2.10_OSE
(C) 2005-2010 Oracle Corporation
All rights reserved.

Minimum guest RAM size:          4 Megabytes
Maximum guest RAM size:          16384 Megabytes
Minimum video RAM size:          1 Megabytes
Maximum video RAM size:          256 Megabytes
Minimum guest CPU count:         1
Maximum guest CPU count:         32
Maximum VDI size:                2097151 Megabytes
Maximum Network Adapter count:   8
Maximum Serial Port count:       2
Maximum Parallel Port count:     2
Maximum Boot Position:           4
Maximum IDE Controllers:         1
Maximum IDE Port count:          2
Maximum Devices per IDE Port:    2
Maximum SATA Controllers:        1
Maximum SATA Port count:         30
Maximum Devices per SATA Port:   1
Maximum SCSI Controllers:        1
Maximum SCSI Port count:         16
Maximum Devices per SCSI Port:   1
Maximum SAS Controllers:         1
Maximum SAS Port count:          8
Maximum Devices per SAS Port:    1
Maximum Floppy Controllers:      1
Maximum Floppy Port count:       1
Maximum Devices per Floppy Port: 2
Default machine folder:          /root/.VirtualBox/Machines
Default hard disk folder:        /root/.VirtualBox/HardDisks
VRDP authentication library:     VRDPAuth
Webservice auth. library:        VRDPAuth
Log history count:               3

Así, podemos contar con XEN, KVM(hvm), QEMU, VirtualBox y LXC en el mismo equipo!.

Conclusiones

Combinando diversos modos de virtualización se puede contar con una rápida implementación en sistemas en desarrollo, el aprovechamiento máximo de las plataformas de desarrollo y la posibilidad (a través de libvirt) de gestionar diversos tipos de virtualización en un mismo equipo, mejorando nuestra administración y simplificando procesos.

En una próxima entrega hablaremos de la creación y gestión de diversas máquinas virtuales en los diversos métodos y el uso de LIBVIRT para la gestión de todos ellos.

Stress-Test Linux: ¿Puedes hacer tanto con tu equipo en MS Windows?

Voy a describirles mi equipo actual:

  • Portátil X61s Tablet PC con Microprocesador Intel Core 2 Duo L7500
  • 4 Gb de RAM
  • 1.6Ghz de velocidad

En estos momentos le tengo instalado:

  • GNU/Linux Debian Squeeze (6.0)
  • Kernel 2.6.37-rc2 con parche de Mike Galbraith (Cgroups per TTY task)
  • Mejora de Lennart Poettering (Cgroups per User – userspace script)
  • Parches de realtime

No es un equipo con tarjetas NVIDIA ni mucho menos un Intel Core7 (quisiera yo) o un Opteron Barcelona y fijense lo que he estado logrando:

La consola contiene:

  • Compilación del kernel Linux (Debian-Way) del último parche (v10) + otras mejoras
  • Una consola KVM corriendo la instalación de Ubuntu 10.04
  • Chromium Browser (con mi correo y mi blog cargado)
  • Gnome con compiz (véase los 8 escritorios activos)
  • mplayer sonando radioGNU! (con los trance de BreadMaker!)
  • Xchat (conectado a freenode y radionu)

He acá otras pruebas:

¿Puedes hacer tantas cosas en un equipo tan básico usando MS Windows?

Cambiate ya a Software Libre! … ven, te esperamos!

Actualización:

He iniciado *otra* máquina virtual KVM (un MS Windows 2003 advanced Server), he acá la prueba:

[Xen] VT-d (VGA) Passthrough y el rendimiento de las VM en Xen

Luego de que en el nucleo Xen 3.25 de la última versión de GNU/Linux Debian Lenny (5.0.5) se incorporara PCI Back para que las VM pudieran adquirir acceso directo a tarjetas de red, dispositivos PCI y USB, se discutió para la versión 4 (y aprovechando las extensiones paravirt_ops del kernel Linux > 2.6.30) la incorporación de VT-d (VGA) Passthrough, esto es, la posibilidad de incorporar a la VM la capacidad de acceder a la aceleración de video nativa del hardware (video AGP, PCI o PCI-e).

Como el Kernel Xen de Debian Squeeze incopora tanto Xen 4.0 como las opciones paravirt_ops y HVM (Qmeu-KVM extensions for Xen), pues me decidí a probar a ver si en Debian Squeeze y Xen podríamos usar VGA Passthrough para correr máquinas Windows (XP, 2003, 7) y que aprovechen la full-aceleración nativa del video.

Mi Hardware:

Mi portatil es una Lenovo Thinkpad X61 Tablet PC, con 4 Gb de RAM y una tarjeta de video Intel G965 con 256 MB de Video:

lspci -v -s 00:02.0
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) (prog-if 00 [VGA controller])
Subsystem: Lenovo T61
Flags: bus master, fast devsel, latency 0, IRQ 749
Memory at f8000000 (64-bit, non-prefetchable) [size=1M]
Memory at e0000000 (64-bit, prefetchable) [size=256M]
I/O ports at 1800 [size=8]
Expansion ROM at <unassigned> [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 3
Kernel driver in use: i915

El Xen de Debian Squeeze trae estas opciones activas:

xm info

host                   : lexotanil

release                : 2.6.32-5-xen-amd64

version                : #1 SMP Sat Jul 24 04:03:11 UTC 2010

machine                : x86_64

nr_cpus                : 2

nr_nodes               : 1

cores_per_socket       : 2

threads_per_core       : 1

cpu_mhz                : 1596

hw_caps                : bfebfbff:20100800:00000000:00000940:0000e3bd:00000000:00000001:00000000

virt_caps              : hvm

total_memory           : 4022

free_memory            : 636

node_to_cpu            : node0:0-1

node_to_memory         : node0:636

node_to_dma32_mem      : node0:636

max_node_id            : 0

xen_major              : 4

xen_minor              : 0

xen_extra              : .1-rc3

xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 

xen_scheduler          : credit

xen_pagesize           : 4096

platform_params        : virt_start=0xffff800000000000

xen_changeset          : unavailable

xen_commandline        : 

cc_compiler            : gcc version 4.4.4 (Debian 4.4.4-5) 

cc_compile_by          : waldi

cc_compile_domain      : debian.org

cc_compile_date        : Wed Jun 30 14:32:51 UTC 2010

xend_config_format     : 4

Entre las capacidades de virtualización completa resalta HVM, por lo que podemos levantar sistemas operativos no-linux (BSD, macOSX, Windows, etc).

¿Qué ganamos con esto?

Imaginen las posibilidades, una máquina con Xen, permite a un usuario correr una VM MS Windows en un entorno “no privilegiado”, sin embargo, el acceso a recursos PCI y VGA le permitirá al usuario acceder como si estuviera en una máquina nativa, con la seguridad de estar encima de un entorno Xen, podemos lograr cosas como:

  • Si a la máquina le cae un virus, eliminamos la máquina virtual y restauramos de alguna copia
  • Podemos jugar de manera full y nativa los juegos de Windows, ya que la aceleración 3D directX encontrará los drivers “oficiales” del hardware.

Por ahora, solo aquellos CPUs que soporten VT-d e iommu podrán ejecutar VGA Passthrough; pero esto representa una ventaja enorme tanto de KVM y de Xen como herramientas de virtualización.

Por ahora, muestro un Windows XP corriendo desde una VM de Xen, mi configuración es:

  • Xen System de GNU/Linux Debian (4.0)
  • Soporte iommu, VT-d y HVM activado
  • Tarjeta de video Intel 965 y CPU Core 2 Duo L7500
  • VM para Xen de Windows XP, con 1Gb de RAM asignado, 64 MB de Video y 2 CPUs en modo compartido (no tengo más!).

Con esta configuración, logré correr la VM en dos combinaciones de resolución:

1024×768 a 32 bits

y 1280×1024 a 16 bits

Hacen falta más pruebas, benchmarks, etc (e instalar programas en la VM) para demostrar el rendimiento de la VM Xen.

Acá un par de pantallazos:

Windows XP corriendo a *casi* full pantalla en una VM Xen, desde un entorno openBox.

El paseo de “Bienvenida”, mostrando las animaciones …

Un MS Windows 2003 Adv. Server corriendo a 1280×1024 dentro de un gnome con compiz!

Futuro

La idea es clara, para aprovechar al máximo el hardware de nuestros equipos, la virtualización es algo necesario y para poder correr cosas como aplicaciones gráficas, juegos y otras aplicaciones de alta demanda gráfica pues VGA Passthrough promete ser la “solución definitiva” para la migración efectiva de todos esos exigentes usuarios.

¿Imaginan tener un equipo de esos Quad-Core, con 3 sistemas operativos en HVM corriendo en paralelo?

Imaginenlo, un MacOS X para el diseñador entusiasta que usa Photoshop, al lado un Windows donde tiene cargado su juego favorito y todo eso sobre el confiable y robusto Linux de siempre.

¡Adiós Excusas de migración! …

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.235 seguidores

A %d blogueros les gusta esto: