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] 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:

[ 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

A %d blogueros les gusta esto: