Archivo del sitio

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

Virtualización

Como lo dice la Wikipedia:

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

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

¿Qué ventajas tiene esto?

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

Tecnologías de virtualización

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

¿De qué se trata todo esto?

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

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

¿Por qué unificar?

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

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

Tecnologías de virtualización

LXC

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

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

Instalación de LXC

La instalación de LXC es bastante sencilla:

aptitude install lxc

Configuración de LXC

* crear el directorio de los contenedores y configuraciones:

mkdir /srv/lxc

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

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

* verificar que tenemos soporte para CGROUPS en el kernel

cat /proc/filesystems | grep cgroup
nodev    cgroup

Y

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

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

mount -t cgroup none /sys/fs/cgroup

Y verificamos que ha montado correctamente:

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

Posteriormente, fijar el montaje en el /etc/fstab

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

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

mkdir /lib/udev/devices/cgroup

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

aptitude install libcgroup1

– Y reiniciamos el equipo.

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

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

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

Xen

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

Instalación de Xen

* paquetes requeridos:

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

*  Debemos reiniciar con el nuevo kernel Xen 4.0

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

Al iniciar, verificamos que estamos en el nuevo kernel:

uname -r
2.6.32-5-xen-amd64

Y las capacidades que soporta Xen:

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

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

Configuración

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

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

* Si deseamos que Xen gestione el bridge, descomentamos

(network-script network-bridge)

* Y reiniciamos el demonio xend

/etc/init.d/xend restart

* Verificamos el demonio TCP:

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

Y el socket Unix:

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

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

KVM

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

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

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

Y hay módulos especificos para Intel y AMD:

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

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

Instalación de KVM

Paquetes requeridos:

aptitude install kvm qemu-kvm

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

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

QEMU

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

Instalación de Qemu

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

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

VirtualBox

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

Instalación

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

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

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

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

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

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

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

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

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

Y verificamos su funcionamiento con:

vboxmanage list systemproperties

Y responde:

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

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

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

Conclusiones

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

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

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

Voy a describirles mi equipo actual:

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

En estos momentos le tengo instalado:

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

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

La consola contiene:

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

He acá otras pruebas:

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

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

Actualización:

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

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

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

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

Mi Hardware:

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

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

El Xen de Debian Squeeze trae estas opciones activas:

xm info

host                   : lexotanil

release                : 2.6.32-5-xen-amd64

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

machine                : x86_64

nr_cpus                : 2

nr_nodes               : 1

cores_per_socket       : 2

threads_per_core       : 1

cpu_mhz                : 1596

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

virt_caps              : hvm

total_memory           : 4022

free_memory            : 636

node_to_cpu            : node0:0-1

node_to_memory         : node0:636

node_to_dma32_mem      : node0:636

max_node_id            : 0

xen_major              : 4

xen_minor              : 0

xen_extra              : .1-rc3

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

xen_scheduler          : credit

xen_pagesize           : 4096

platform_params        : virt_start=0xffff800000000000

xen_changeset          : unavailable

xen_commandline        : 

cc_compiler            : gcc version 4.4.4 (Debian 4.4.4-5) 

cc_compile_by          : waldi

cc_compile_domain      : debian.org

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

xend_config_format     : 4

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

¿Qué ganamos con esto?

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

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

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

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

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

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

1024×768 a 32 bits

y 1280×1024 a 16 bits

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

Acá un par de pantallazos:

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

El paseo de “Bienvenida”, mostrando las animaciones …

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

Futuro

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

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

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

¡Adiós Excusas de migración! …

[ 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.

Proyecto: Colección “Dame luz!”

Siempre me ha gustado colaborar, por algo estoy en la comunidad de software y conocimiento libre (porque no todo es software), por lo general cada vez que hago algo voy tomando nota y llevando bitácoras, a veces acumulo muchas y por el trabajo y diferentes obligaciones nunca las publico; ahora vamos a cambiar eso!.

“Dame Luz!”  siempre ha sido una expresión interesante cuando la gente está perdida y necesita orientación.

Prólogo

Hoy fué un día interesante, estaba escribiendo algunas cosas, más que todo para la documentación en mi trabajo cuando varios amigos a la vez se conectaron a preguntarme cosas; me llamó la atención particularmente cuando a uno le dije: “epale, por que no usas net sam provision, yo dejé de usar smbldap-tools hace tiempo” y fué como un balde de agua fría para él!, dijo que no sabía nada al respecto y recordé obviamente lo que me habia costado a mí, encontrar información …

Esa fué la chispa que movió la iniciativa …

¿De qué se trata la colección?

Voy a iniciar un proceso de “regularización” de mis bitacoras, la gente en Flickr se inventa los “Proyectos 365” (cada día, una foto) y yo inventaré un Proyecto 52 técnico; cada semana prepararé y tendré listo un HOWTO, paper técnico, una bitacora de trabajo, un artículo netamente técnico y orientado en alguno de estos 5 aspectos (que llamaré colecciones):

  1. OpenLDAP
  2. Servicios
  3. Virtualización con Xen y openVZ
  4. Bases de datos (postgreSQL, mySQL, MariaDB, BerkeleyDB)
  5. Programación (PHP, Python)

La idea general es regularizar esas bitácoras que tengo por ahí, ordenarlas y colocarlas acá para referencia de todas esas personas como mi amigo, que desconocían ciertas características de esas aplicaciones y que por mi trabajo, debo estar haciendo eso todos los días.

¿Por qué no un Wiki?

Inicialmente usaré esta plataforma mientras pueda planificar de forma ordenada como inyectarlas en Wikia (un sitio libre para tener wikis), Weyúu (que significa “Luz” en dialecto Maquiritare/Yekuana) es donde residirán los artículos, pero ya la gente lee y está pendiente de este blog así que la plataforma Wikia será usada como lugar para ordenar todo. No me gusta mucho wikia por su gran cantidad de publicidad (que a un artículo técnico le salga en la base un banner de pokemon no lo hace muy serio) pero es con lo más que cuento mientras pueda costear los dólares de un servidor para una plataforma como esta.

¿De qué consta la colección “Luz|Weyú”?

La colección tendrá un ciclo “ordenado” de artículos, que ya tengo listos y preparados, eso no significa para nada que la gente no puede comentar acá para solicitar un nuevo artículo o que les hable de algún problema técnico; la idea es hacer crecer naturalmente esta iniciativa.

Tampoco será muy rígida en las entregas; formalmente entregaré una semanal, pero puede que alguna otra sea entregada antes por solicitud de la gente o porque decida adelantar su publicación, descuiden, hay más de 52 artículos planificados.

En la Colección “OpenLDAP” se encuentran listos:

  • Árboles y Bosques LDAP: diseñando tu DIT (Directory Information Tree)
  • Extendiendo openLDAP: Creando tu propio ObjectClass
  • Extendiendo openLDAP: módulos y backends
  • Extendiendo openLDAP: Scripting, automatización y monitoreo
  • Overlays y Constraints en openLDAP
  • Extrayendo toda la información (incluyendo passwords) de un Active Directory a openLDAP

En la colección “Virtualización” están listos:

  • Bridges y Bonding de manera práctica con Xen
  • Aprovechando al máximo un DL 380 HP con openVZ
  • Creando personalizaciones (Roles) de VMs con Xen y Debian Lenny

En la colección “Servicios” tenemos:

  • Conectando openLDAP y Samba sin usar smbldap-tools
  • Automatizando Samba: Scripting
  • Implementando alias, listas, buzones compartidos y públicos con Postfix y Dovecot

En la colección “Bases de datos” tenemos:

  • Presentando a mariaDB: primeras pruebsa de migración desde mySQL
  • Integración Heterogénea: ETL para postgreSQL con Apatar
  • Implementación geográfica básica: postgreSQL y mySQL

Hay varias ideas por ahí rondando (como presentar Continuent Tungsten), pero aún están en prueba de concepto.

Por mis obligaciones he escrito muy poco de programación, aunque los HOWTO en prueba de concepto que están más cerca son:

  • Plataforma de envío de mensajes SMS usando GSM y Python

(de mi necesidad de que los NAGIOS envíen mensajes de texto a los jefes de informática)

Y, ¿Cuándo empiezo?

La fecha que escogí para publicar será todos los viernes uno, de acuerdo a los comentarios de la gente, adelantaré algunos o publicaré otros en otras fechas, esta lista se estará actualizando constantemente, agregando nuevos temas (sin salirse claro está de los 5 aspectos definidos, ya que son mis áreas donde poseo experiencia).

Espero poder contribuir con el avance y éxito de la utilización de software libre en Venezuela y espero contar con el apoyo de las personas que me siguen.

ACTUALIZACION

He logrado gracias al grandisimo apoyo de Octavio Rossell de Proyecto GNU/CNSL un espacio para un Wiki Colaborativo (sin tener que usar Wikia, que me llena de publicidad innecesaria) con el cual podré contar con un wiki para los manuales.

La dirección es: Phenobarbital con Wiki!

Un detalle sobre Xen y Debian Lenny

Estuve haciendo pruebas de levantar sobre GNU/Linux Debian Lenny el Xen que “oficialmente” viene para Dom0; el kernel 2.6.26-1 (traido desde Fedora por cierto) y luego de instalarlo y hacer un “update” de todos los paquetes se me presentó el siguiente error:


[2009-01-20 15:28:55 2595] INFO (SrvDaemon:219) Xend exited with status 1.
[2009-01-20 15:29:48 2625] INFO (SrvDaemon:331) Xend Daemon started
[2009-01-20 15:29:48 2625] INFO (SrvDaemon:335) Xend changeset: unavailable.
[2009-01-20 15:29:48 2625] INFO (SrvDaemon:342) Xend version: Unknown.
[2009-01-20 15:29:48 2625] ERROR (SrvDaemon:353) Exception starting xend (no element found: line 1, column 0)
Traceback (most recent call last):
File "/usr/lib/xen-3.2-1/lib/python/xen/xend/server/SrvDaemon.py", line 345, in run
servers = SrvServer.create()
File "/usr/lib/xen-3.2-1/lib/python/xen/xend/server/SrvServer.py", line 251, in create
root.putChild('xend', SrvRoot())
File "/usr/lib/xen-3.2-1/lib/python/xen/xend/server/SrvRoot.py", line 40, in __init__
self.get(name)
File "/usr/lib/xen-3.2-1/lib/python/xen/web/SrvDir.py", line 82, in get
val = val.getobj()
File "/usr/lib/xen-3.2-1/lib/python/xen/web/SrvDir.py", line 52, in getobj
self.obj = klassobj()
File "/usr/lib/xen-3.2-1/lib/python/xen/xend/server/SrvNode.py", line 30, in __init__
self.xn = XendNode.instance()
File "/usr/lib/xen-3.2-1/lib/python/xen/xend/XendNode.py", line 709, in instance
inst = XendNode()
File "/usr/lib/xen-3.2-1/lib/python/xen/xend/XendNode.py", line 60, in __init__
saved_host = self.state_store.load_state('host')
File "/usr/lib/xen-3.2-1/lib/python/xen/xend/XendStateStore.py", line 104, in load_state
dom = minidom.parse(xml_path)
File "/usr/lib/python2.5/xml/dom/minidom.py", line 1915, in parse
return expatbuilder.parse(file)
File "/usr/lib/python2.5/xml/dom/expatbuilder.py", line 924, in parse
result = builder.parseFile(fp)
File "/usr/lib/python2.5/xml/dom/expatbuilder.py", line 211, in parseFile
parser.Parse("", True)
ExpatError: no element found: line 1, column 0
[2009-01-20 15:29:48 2624] INFO (SrvDaemon:219) Xend exited with status 1.

Entonces este fallo imposibilitaba el inicio del Xen Daemon.

La solución

La solución es sencilla y realmente ni merece un post; lo que pasa es que a veces se me olvida y pues de repente a alguien más le sirve.

Simplemente deben eliminar el contenido de la carpeta /var/lib/xend/ con el comando:

rm -fR /var/lib/xend/*

Y listo!, inicien de nuevo el xen (/etc/init.d/xend start); descuiden, las carpetas serán creadas de nuevo al iniciarse el demonio.

A %d blogueros les gusta esto: