Archivo del sitio

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 KVM: La forma más rápida de montar una imagen de disco

En alguna oportunidad, necesitamos montar una imagen de disco (formato qcow) de KVM o de HVM (Xen) para poder acceder a los archivos contenidos allí dentro, pero la cosa no era tarea fácil (calcular el offset del sector de la geometría de la partición, hacer el losetup, etc); la forma más rápida es usando kpartx.

Kpartx es una aplicación cónsola (parte de los multipath-tools por cierto) que permite crear automáticamente los device mappings (dispositivos en /dev) de cualquier dispositivo de bloque.

Instalando kpartx

Aunque lo podemos instalar junto con los multipath-tools, lo podemos instalar de manera independiente:

aptitude install kpartx

Usando kpartx con KVM/HVM

Hemos creado una máquina virtual con KVM/HVM, la misma está en un archivo de imagen ó en un dispositvo LVM, para mapear todas las particiones de dicha imagen KVM como dispositivos de bloque, simplemente ejecutamos:

kpartx -a /dev/mapper/vgVM-maquina1

Siendo /dev/mapper/vgVM-maquina1 el volumen lógico donde está la máquina virtual, si está en un archivo en disco, sería:

kpartx -a /srv/kvm/maquina1/disk1.img

Esto nos agregará una serie de dispositivos de bloque llamados igual qué el volumen original pero agregando las particiones lógicas, ejemplo:

/dev/mapper/vgVM-maquina1p1 (primera partición)

/dev/mapper/vgVM-maquina1p2 (segunda partición)

/dev/mapper/vgVM-maquina1p3 (tercera partición)

Y así suscesivamente.

Montando la partición

Para montar simplemente utilizamos el comando mount:

mount -o rw /dev/mapper/vgVM-maquina1p1 /mnt

En nuestro caso, hicimos el montaje en /mnt.

Borrando el mapa de particiones de la imagen

Si ya hicimos uso de la partición y deseamos eliminar el “mapa” de dichas particiones en nuestra lista de dispositivos de bloque, simplemente ejecutamos:

kpartx -d /dev/mapper/vgVM-maquina1

Y se eliminarán todas las referencias (mapping) de particiones de la imagen (NOTA: no se borrarán las particiones).

Otros usos de Kpartx

Si queremos ver qué particiones posee una imagen KVM/HVM (solo listarlas, no las agrega al listado de particiones disponibles):

kpart -l /dev/mapper/vgVM-maquina1

Si durante el proceso de una imagen KVM ya agregada con *-a* decidimos crear una nueva partición, podemos ejecutar simplemente:

kpartx -u

Y se actualizarán todos los identificadores de dispositivos de bloque de todas las imagenes listadas.

El bug “Intel SYSRET fault” y la importancia de las comunidades

La más reciente aparición de un intel sysret bug en el sub-sistema de llamadas que los CPUs Intel ejecutan a 64 bits nos demuestra las ventajas de la colaboración y de los proyectos de software libre, ¿aún siguen teniendo dudas?.-

El error

El bug afecta una serie de llamadas que sistemas de 64 bits con chips Intel realizan al CPU, un script podría causar un fallo de segmentación que podría aprovechar un atacante para escalar privilegios en el equipo atacado, es más, el ataque podría afectar a varios sistemas de virtualización (salvo KVM) pues si el usuario tiene privilegios administrativos en una VM (invitado) podría usar el bug para acceder cómo administrador (a través de los propios anillos de seguridad del O.S) al sistema operativo host.

El bug afecta a todas las versiones de 64 bits de Microsoft Windows (incluyendo Windows 2008 y Windows 7), a todas las versiones derivadas de freeBSD (incluyendo Darwin, Debian KfreeBSD y Mac OSX) y netBSD.

Además, el bug afecta a esos sistemas virtualizados ejecutados sobre virtualizadores como Xen o VMWare (con su microkernel basado en linux 2.4) ya que el Xen no puede determinar (por el fallo del CPU) si la instrucción con privilegios escalados viene del dom0 (host) o del invitado (guest).

¿Cómo afecta a Linux?

El bug, aunque la gente no lo crea, no afecta a Linux, este bug (en su versión de escalada de privilegios en un sistema no-virtualizado 64bits) fué notificado y cerrada la brecha tan atrás como 2006, núcleos linux desde la versión 2.6.21 ya tienen un parche de seguridad para prevenir esa escalada de privilegios local.

Lo más interesante, es que Intel hasta el momento, para escaladas locales, sólo ha liberado microcodes correctivos para sistemas Linux corriendo cómo hipervisores.-

Y ¿por qué resuena ahora?

Pues porque un hacker a descubierto una nueva versión del error que además, permite qué desde esos sistemas (guest) Windows, FreeBSD o netBSD afecten a un sistema virtualizado, es decir, Xen está comprometido con el fallo, siempre y cuándo los sistemas que estés corriendo, sean sistemas “con el error”.

En resumen:

* El error NO afecta a Linux nativos
* El error NO afecta a Xen, si sólo se usa para virtualizar GNU/Linux
* El error SOLO afecta a Xen, si el atacante tiene privilegios administrativos en una VM comprometida y ejecuta el ataque para irrumpir en el sistema host (dom0), si confías en las máquinas 64 bits virtualizadas, obvie el error.
* SOLO afecta si las máquinas virtuales (VM) son a 64 bits en modo hipervirtualizado (Xen)
* Como KVM comparte el parche Linux CVE-2006-0744, NO se ve afectado

Notas curiosas

Aunque desde 2006 se había notificado el fallo, no es sino hasta el 1 de mayo de 2012, cuando al descubrirse que afecta también a entornos virtualizados, que Intel en conjunto con desarrolladores deciden cerrar la brecha y notifica a los diversos fabricantes y desarrolladores de sistemas operativos.
El proyecto Debian fué notificado del fallo en Xen el 2 de mayo de 2012 en el bug-tracking system, la brecha en el mainstream fué cerrada el mismo día (¡hell yeah!, the bazaar collaboration strikes back!), el bug para wheezy fué cerrado hace 2 semanas y el parche para Debian Security (squeeze estable), hace unos 5 días; en comparación, Microsoft fué notificado el día 1 de mayo y lanzó la actualización con la correción a través de Windows Update el día de hoy (18 de Junio), ¿alguna diferencia de tiempo?.
Aprovechando los parches liberados por Debian y Suse, el proyecto Xen cerró el bug en su código principal el 13 de Junio de 2012 (mucho antes que Microsoft, por cierto).
Desconozco si mac OSX “mountain lion” (recientemen liberado y afectado por el bug) realizará un parche de seguridad prontamente, aún no se han pronunciado.
Red Hat se ve comprometido (al igual que centOS) ya que utilizan una versión “vieja” de linux (2.6.18) y de Xen (3.2), creo que ya notificaron parches de seguridad para dichos sistemas estables.
No se nombra en el “release” del security pack de Microsoft a Windows XP 64 bits ni a Windows 2000 64 bits, al parecer, dicho bug se mantendrá abierto a menos que Microsoft decida realizar un “out-of-support service pack” para dichos sistemas.
El bug se debe a una implementación errónea por parte de Intel, de la directiva amd64 (como la instrucción SYSRET), es decir, si corres una plataforma virtualizada sobre hardware AMD, no tienes de qué preocuparte.

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.

[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! …

[ Weyu / Xen ] Los trucos de la doñita para Xen

He creado dentro del Wiki un apartado que recopila trucos, detalles de configuración y resolución de problemas básicos (y no tan básicos) usando la virtualización con Xen.

Trucos simples desde como migrar una VM de máquina o las combinaciones alternativas de la consola hvc0, hasta crear bonding y bridging para optimizar el uso de los recursos de red de nuestra institución, además de un apartado de resolución de problemas comunes, han sido incorporados acá.

Se incorporarán más a medida que vaya madurando el wiki y vaya obteniendo “feedback e ideas” de los contribuyentes.

Espero los ayude tanto como a mí.

El enlace acá: http://phenobarbital.gnu.org.ve/doku.php/weyu:xen:faq

[Xen] Moviendo máquinas virtuales entre hosts

La utilidad de mover una máquina virtual (VM) entre dos servidores con Xen permite contar con copias de seguridad, servidores stand-by, copias físicas en disco (para almacenarlas de manera segura) o para crear copias de servicios para redundancia.

Como parte del proyecto Weyuü y gracias al apoyo incondicional del proyecto GNU, los manuales (howto) estarán de ahora en adelante en el wiki de proyecto GNU phenobarbital.gnu.org.ve y por ende por acá solo colocaré la referencia y espacio para comentarios (mientras no pueda activar el plugin de comentarios en el Wiki).

Es mi primer artículo colaborativo en el wiki de GNU, espero encontrar algún plugin para wordpress que me permita vía RSS “colocar” las nuevas páginas acá.

Mientras, podrán encontrar el enlace al wiki-manual acá: Migrando con Xen.

Exportando dispositivos PCI a una VM con Xen y Debian Lenny

Por lo general en un entorno virtualizado, el hypervisor se encarga de gestionar el acceso a los recursos de hardware de las distintas máquinas virtuales; sin embargo, en algunas ocasiones deseamos que una VM (máquina virtual) tenga acceso *directamente* a un dispositivo físico (PCI-USB) de nuestra máquina.

Usando PCI-back

PCI back es un módulo del kernel Xen que nos permite “ocultar” un dispositivo al dom0 (máquina base) para ser “expuesto” o “exportado” a alguna de las máquinas o VM (de manera exclusiva).

PCI-Back no es un módulo que se encuentre activo (al menos en la versión de kernel que tengo de Xen para Debian Lenny), pero activarlo es bastante fácil.

Habilitando PCIback en Debian Lenny

Para habilitar PCIback bastará con agregar este módulo a la lista de módulos gestionados por el initramfs:

echo pciback >> /etc/initramfs-tools/modules

Luego, creamos un nuevo initrd, esta vez con pciback habilitado, de manera que podamos obviamente, arrancar sin PCIback:

mkinitramfs -o /boot/initrd.img-`uname -r`-pciback `uname -r`

Esto, generó un initrd llamado:

initrd.img-2.6.26-2-xen-amd64-pciback

y edito el menu.lst (en grub2 sería el grub.cfg o editar las reglas correspondientes):
de:

module /boot/vmlinuz-2.6.26-2-xen-amd64 root=/dev/sda1 ro console=tty0
module /boot/initrd.img-2.6.26-2-xen-amd64

a:

module /boot/vmlinuz-2.6.26-2-xen-amd64 root=/dev/sda1 ro console=tty0
module /boot/initrd.img-2.6.26-2-xen-amd64-pciback

Al reiniciar el dom0, ya tendremos habilitado PCIback.

Y reiniciamos el dom0.

Exportando una tarjeta de red en exclusiva para un VM

En mi caso, tengo una infraestructura para un servidor de correo, como la planteada en la figura:

No hemos creado un bridge con la eth1, ya que disponemos de una sola IP asignada por el ISP a través de un Frame Relay y no se compartirá dicha interfaz, para optimizar el rendimiento (un 35% mejor) y otras razones, la eth1 se “ocultará” y será entregada a la dom1 (que será un servidor de correo, con dos interfaces, una pública y otra privada).

Creando nuestro archivo pcibind:

Vamos a crear un archivo PCIbind, que se ejecutará al inicio, con este, podremos configurar qué dispositivos PCI se ocultarán, además podemos “apagar” la configuración en cualquier momento (a diferencia de usar pciback.hidden() en el grub, que requiere reiniciar el equipo dom0).

El archivo tiene la siguiente forma:

#!/bin/bash
# /etc/init.d/pcibind  <graham@vpac.org> Nov 2008. Rev: 20081202
#
# description: Bind a device to the PCI Backend's list

case "$1" in
 start) cat /etc/pcibind.conf 2>/dev/null |
 awk '{if ($1 !~ /#/) if($NF > 1) print $0}' |
 while read PCI ; do
 SLOT=`echo "$PCI" | awk '{print $1}'`
 DRVR=`echo "$PCI" | awk '{print $2}'`
 echo -n $SLOT > /sys/bus/pci/drivers/$DRVR/unbind
 echo -n $SLOT > /sys/bus/pci/drivers/pciback/new_slot
 echo -n $SLOT > /sys/bus/pci/drivers/pciback/bind
 done                                                   ;;
 stop ) cat /etc/pcibind.conf 2>/dev/null |
 awk '{if ($1 !~ /#/) if($NF > 1) print $0}' |
 while read PCI ; do
 SLOT=`echo "$PCI" | awk '{print $1}'`
 DRVR=`echo "$PCI" | awk '{print $2}'`
 echo -n $SLOT > /sys/bus/pci/drivers/pciback/unbind
 echo -n $SLOT > /sys/bus/pci/drivers/pciback/remove_slot
 echo -n $SLOT > /sys/bus/pci/drivers/$DRVR/bind
 done                                                   ;;
 * ) echo "Usage: $0 {start|stop}"; exit 2                  ;;
esac
exit 0

El archivo va en /etc/init.d/pcibind y busca un archivo de configuración en /etc/pcibind.conf.

Luego de creado, le damos privilegios a root sobre el archivo, lo hacemos ejecutable y lo agregamos a rc.d

chmod 0750 /etc/init.d/pcibind
update-rc.d pcibind defaults

Con esto, ya tenemos pcibind listo para “ocultar” los dispositivos PCI que le indiquemos.

Descubriendo las NIC Ethernet

Cuando ejecutamos:

ifconfig -a

Vemos la información de la eth1:

eth1      Link encap:Ethernet  HWaddr 00:ab:fe:85:25:55  
 inet6 addr: fe80::218:feff:fe83:2450/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:10779 errors:0 dropped:0 overruns:0 frame:0
 TX packets:56975 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000 
 RX bytes:698027 (681.6 KiB)  TX bytes:3653233 (3.4 MiB)
 Interrupt:26

Nos interesa la MAC Address de la tarjeta de red; ahora descubriremos su PCI-id y el módulo del kernel que la gestiona:

para ello ejecutamos:

lspci -v

Y en su salida encontraremos algo como esto:

03:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703 Gigabit Ethernet (rev 10)
 Subsystem: Compaq Computer Corporation NC7771 Gigabit Server Adapter (PCI-X, 10,100,1000-T)
 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 29
 Memory at fdde0000 (64-bit, non-prefetchable) [size=64K]
 [virtual] Expansion ROM at c4210000 [disabled] [size=64K]
 Capabilities: [40] PCI-X non-bridge device
 Capabilities: [48] Power Management version 2
 Capabilities: [50] Vital Product Data <?>
 Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3 Enable-
 Kernel driver in use: tg3
 Kernel modules: tg3

Si desean, pueden ejecutar primero con lspci -v | grep Ethernet

03:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703  Gigabit Ethernet (rev 10)

El primer valor (en negrillas) es el PCI-id

Con esto descubrimos que la tarjeta eth1 es una Broadcom, PCI-id: 03:02.0 y la gestiona el módulo del kernel tg3.

Ocultando la tarjeta al dom0

Para ocultar cualquier dispositivo PCI, simplemente lo agregamos como un línea en el archivo /etc/pcibind.conf:

# /etc/pcibind.conf
# SLOT        DRIVER

0000:03:02.0  tg3  # MAC=00:ab:fe:85:25:55

Hemos puesto el PCI-id (slot PCI), el módulo del kernel (tg3) y como comentario recordatorio, la mac-address de la tarjeta.

Al ejecutar

/etc/init.d/pcibind start

Veremos que el dispositivo eth1 “desaparece” y ya no es accedido por el equipo local.

Si deseamos “reaparecerlo” (la VM que lo tenga asignado debe estar apagada) simplemente ejecutamos:

/etc/init.d/pcibind stop

Asignado el recurso PCI a una VM

Para asignar el recurso a una VM debemos editar el archivo /etc/network/interfaces (antes que nada) para que la máquina al reiniciar pueda hacer uso de la tarjeta NIC, simplemente agregamos:

hwaddress ether 00:AB:FE:85:25:55

Quedando:

iface eth1 inet static
address 200.105.240.254
netmask 255.255.255.248
gateway 200.105.240.249
dns-search cantv.net
dns-nameservers 200.44.32.12
hwaddress ether 00:AB:FE:85:25:55

Apagamos la VM luego de agregar esa opción en el /etc/network/interfaces

Luego, en el archivo de configuración de la VM en Xen (/etc/xen/vmcorreo.cfg) agregamos la siguiente opción:

pci = [ “03:02.0″ ]

Que representa el dispositivo (o los dispositivos) PCI que vamos a asignar a la VM:

Quedando:

#
#  Networking
#
vif         = [ 'ip=172.16.80.20,mac=00:16:3E:CF:3F:AA,bridge=brlocal' ]
pci         = [ "03:02.0" ]

Cuando iniciemos la VM (xm create vmcorreo.cfg) veremos que tendremos 2 interfaces de red, una virtual (eth0) que sale por el bridge del dom0, y una eth1, que será físicamente nuestra interfaz a Internet.

Como nota adicional, recuerden instalar todos los módulos en su domU:

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

Sobre todo si tienen una NIC u otro hardware PCI que requiera módulos especiales del kernel para ser detectado.

Seguir

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

Únete a otros 3.227 seguidores

A %d blogueros les gusta esto: