Archivo del sitio

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

[ 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

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: