Les traigo una noticia muy importante para aquellos que estan cerca de los entornos de virtualización con Linux, en este caso les hablare de el soporte del kernel Linux para correr en maquinas virtuales Xen DomU y Dom0 sobre el hypervisor Xen.
Desde hace ya algunos años es posible correr un kernel Linux vanila en maquinas virtuales Xen DomU sobre el hypervisor Xen, en un principio con unos parches al kernel Linux (XenLinux), después se integraron los parches en el kernel oficial Linux desde la versión 2.6.27 con PVOPS, el soporte que se incluyo fueron los drivers Xen Bus, network driver además de I/O driver entre otros componentes, esto permite correr el kernel Linux vanilla en hardware fisico como en maquinas virtuales Xen DomU.
El soporte para correr Linux en modo dominio de adminitración o Domain-0 se mantenia por separado, en parches para el ahora algo viejo kernel 2.6.18 o en kernels algo modernos que solo algunas distribuciones lo soportaban no oficialmente, sin embargo, seguian siendo esfuerzos separados.
Ahora todo ha cambiado ya que Linus Torvalds ha aceptado integrar en la rama oficial 2.6.39+ el soporte PVOPS de forma oficial para que Linux corra de forma nativa en entornos fisicos, virtualizados como Xen Domain-0 o DomU y otras alternativas como KVM, estos esfuerzos benefician tanto a la comunidad, equipos de desarrollo y a todos aquellos que estan ya usando Xen para virtualizar sistemas Linux.
Para más información les recomiendo el articulo publicado en los blogs de Oracle: Linux mainline contains all the Xen code bits for Dom0 and DomU, además les recomiendo leer la pagina del wikiXen paravirt_ops for upstream Linux kernel, donde podrán encontrar más información de el progreso de los componentes integrados.
Así es, ya esta aquí la versión estable de Xen 4.1, despuśe de 11 meses de desarrollo y gracias a las contribuciones de voluntarios y empresas que contribuyen al desarrollo de Xen.org, Aquí les dejo el anuncio oficial (en inglés), ya es hora de probar esta versión y esperemos que se corrijan muchos de los problemas que había en Xen 4.0.
After 11 months of development and 1906 commits later (6 a day !!!), Xen.org is proud to present its new stable Xen 4.1 release. We also wanted to take this opportunity to thank the 102 individuals and 25 organisations who have contributed to the Xen codebase and the 60 individuals who made just over 400 commits to the Xen subsystem and drivers in the Linux kernel.
New Xen Features
Xen 4.1 sports the following new features:
- A re-architected XL toolstack that is functionally nearly equivalent to XM/XEND
- Prototype credit2 scheduler designed for latency-sensitive workloads and very large systems
- CPU Pools for advanced partitioning
- Support for large systems (>255 processors and 1GB/2MB super page support)
- Support for x86 Advanced Vector eXtension (AVX)
- New Memory Access API enabling integration of 3rd party security solutions into Xen virtualized environments
- Even better stability through our new automated regression tests
Further information can be found in the release notes.
XL Toolstack: Xen 4.1 includes a re-architected toolstack, that is based on the new libxenlightlibrary, providing a simple and robust API for toolstacks. XL is functionally equivalent and almost entirely backwards compatible with existing XM domain configuration files. The XEND toolstack remains supported in Xen 4.1 however we strongly recommend that users upgrade to XL. For more information see the Migration Guide. Projects are underway to port XCP’s xapi and libvirt to the new libxenlight library.
Credit2 Scheduler: The credit1 scheduler has served Xen well for many years. But it has several weaknesses, including working poorly for latency-sensitive workloads, such as network traffic and audio. The credit2 scheduler is a complete rewrite, designed with latency-sensitive workloads and very large numbers of CPUs in mind. We are still calling it a prototype scheduler as the algorithm needs more work before it will be ready to become the main scheduler. However it is stable and will perform better for some workloads than credit1.
CPU pools: The default credit scheduler provides limited mechanisms (pinning VMs to CPUs and using weights) to partition a machine and allocate CPUs to VMs. CPU pools provide a more powerful and easy to use way to partition a machine: the physical CPUs of a machine are divided into pools. Each CPU pool runs its own scheduler and each running VM is assigned to one pool. This not only allows a more robust and user friendly way to partition a machine, but it allows using different schedulers for different pools, depending on which scheduler works best for that workload.
Large Systems: Xen 4.1 has been extended and optimized to take advantage of new hardware features, increasing performance and scalability in particular for large systems. Xen now supports the Intel x2APIC architecture and is able to support systems with more than 255 CPUs. Further, support for EPT/VTd 1GB/2MB super pages has been added to Xen, reducing the TLB overhead. EPT/VTd page table sharing simplifies the support for Intel’s IOMMU by allowing the CPU’s Enhanced Page Table to be directly utilized by the VTd IOMMU. Timer drift has been eliminated through TSC-deadline timer support that provides a per-processor timer tick.
Advanced Vector eXtension (AVX): Support for xsave and xrestor floating point instructions has been added, enabling Xen guests to utilize AVX instructions available on newer Intel processors.
Memory Access API: The mem_access API has been added to enable suitably privileged domains to intercept and handle memory faults. This extents Xen’s security features in a new direction and enables third parties to invoke malware detection software or other security solutions on demand from outside the virtual machine.
Upstreaming
During the development cycle of Xen 4.1, the Xen community worked closely with upstream Linux distributions to ensure that Xen dom0 support and Xen guest support is available from unmodified Linux distributions. This means that using and installing Xen has become much easier than it was in the past.
- Basic dom0 support was added to the Linux kernel and a vanilla 2.6.38 kernel is now able to boot on Xen as initial domain. There is still some work to do as the initial domain is not yet able to start any VMs, but this and other improvements have already been submitted to the kernel community or will be soon.
- Xen developers rewrote the Xen PV-on-HVM Linux drivers in 2010 and submitted them for inclusion in upstream Linux kernel. Xen PV-on-HVM drivers were merged to upstream kernel.org Linux 2.6.36, and various optimizations were added in Linux 2.6.37. This means that any Linux 2.6.36 or 2.6.37 kernel binary can now boot natively, on Xen as dom0, on Xen asPV guest and on Xen as PV on HVM guest. For a full list of supported Linux distributions seehere.
- Xen support for upstream Qemu was developed, such that upstream Qemu can be used as Xen device model. Our work has received a good feedback from the Qemu Community, but is not yet in the mainline.
The Xen development community recognizes that there is still some way to go, thus we will continue to work with upstream open source projects to ensure that Xen works out-of-the-box with all major operating systems, allowing users to get the benefits of Xen such as multi-OS support, performance, reliability, security and feature richness without incurring the burden of having to use custom builds of operating systems.
More Info
Downloads, release notes, data sheet and other information are available from the download page. Links to useful wiki pages and other resources can be found on the Xen support page.
En este documento se explicará paso a paso como instalar y preparar un entorno de para-virtualización con Xen 3.2 sobre Ubuntu Server 8.,04.1 en un sistema de 64-bits.
Caracteristicas de la implementación
- Entorno solo Para-Virtualizacaión sobre arquitectura Intel 64bits
- Automatización de maquinas virtuales mediante xen-tools
- Uso de Linux Volume Manager (LVM) como sistema de almacenamiento
- Soporte para hacer snapshots de maquinas virtuales usando LVM
- Las maquinas virtuales tendrán Ubuntu Hardy 8.04.1
Terminología
Host = Equipo en donde se alojan las maquinas virtuales
Dom0 = En terminología de Xen este es el Host
Guest = Maquina virtual que se ejecuta en el Host
DomU = Maquina virtual en terminología de Xen
Configuración de Hardware
Se instalará Ubuntu Server Hardy 8.04.1 64bits.
Al terminar de instalar el sistema con el siguiente esquema de particiones
Disco Duro Sata 80GB (/dev/sda)
Partición /dev/sda1 /boot 200MB
Partición /dev/sda2 swap 2000MB
Partición /dev/sda3 LVM Resto
/dev/sda3 es el Physical Volume (PV) el cual será parte de un Volume Group (VG) VGsystem01 en el cual se crearán Volumens Lógicos (LV) para la partición raíz de la maquina Host (Domain0) y también las particiones para todas las demás maquinas virtuales (DomainU).
Volumens Lógicos
/dev/mapper/VGsystem01-root / 10G
NOTA: En este momento no crearemos más LV ya que las herramientas xen-tools se encargarán de automatizar la creación al momento de crear las maquinas virtuales.
Al terminar la instalación reiniciamos y confirmamos que tenemos instalado un kernel con soporte SMP y de 64bits:
# uname -a
Ahora actualizaremos el sistema con apt
# apt-get update
# apt-get upgrade
Instalar el servidor OpenSSH
apt-get install openssh-server
Ahora podemos continuar con la instalación de los elementos de xen.
Instalación de Ubuntu Xen Server
Instalación del kernel de xen y las herramientas para nuestro entorno, este paso lo podemos automatizar instalando el metapaquete ubuntu-xen-server
root@actiaxh:~# aptitude install ubuntu-xen-server Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information Initializing package states... Done Building tag database... Done The following NEW packages will be automatically installed: binutils binutils-static bridge-utils debootstrap gcc gcc-4.2 libasound2 libbeecrypt6 libc6-dev libconfig-inifiles-perl libcurl3 libdirectfb-1.0-0 libexpect-perl libgomp1 libio-pty-perl libio-stty-perl libneon27 librpm4.4 libsdl1.2debian libsdl1.2debian-alsa libterm-readline-gnu-perl libterm-size-perl libtext-template-perl libxen3 libxml2 linux-libc-dev linux-restricted-modules-common linux-xen nvidia-kernel-common perl-doc python-dev python-xen-3.2 python2.5-dev rinse rpm screen sgml-base vnstat xen-docs-3.2 xen-hypervisor-3.2 xen-shell xen-tools xen-utils-3.2 xfsprogs xml-core The following NEW packages will be installed: binutils binutils-static bridge-utils debootstrap gcc gcc-4.2 libasound2 libbeecrypt6 libc6-dev libconfig-inifiles-perl libcurl3 libdirectfb-1.0-0 libexpect-perl libgomp1 libio-pty-perl libio-stty-perl libneon27 librpm4.4 libsdl1.2debian libsdl1.2debian-alsa libterm-readline-gnu-perl libterm-size-perl libtext-template-perl libxen3 libxml2 linux-image-2.6.24-23-xen linux-image-xen linux-libc-dev linux-restricted-modules-2.6.24-23-xen linux-restricted-modules-common linux-restricted-modules-xen linux-ubuntu-modules-2.6.24-23-xen linux-xen nvidia-kernel-common perl-doc python-dev python-xen-3.2 python2.5-dev rinse rpm screen sgml-base ubuntu-xen-server vnstat xen-docs-3.2 xen-hypervisor-3.2 xen-shell xen-tools xen-utils-3.2 xfsprogs xml-core 0 packages upgraded, 51 newly installed, 0 to remove and 0 not upgraded. Need to get 56.4MB of archives. After unpacking 196MB will be used. Do you want to continue? [Y/n/?] Y
Cuando terminen de instalar los paquetes, automaticamente se agregará una entrada a la configuración del gestor de arranque GRUB, la podemos ver así:
# grep -A 5 "Xen 3.2" /boot/grub/menu.lst title Xen 3.2 / Ubuntu 8.04.2, kernel 2.6.24-23-xen root (hd0,0) kernel /xen-3.2.gz module /vmlinuz-2.6.24-23-xen root=/dev/mapper/VGsystem01-root ro console=tty0 module /initrd.img-2.6.24-23-xen quiet
Ahora reiniciamos el sistema para que inicie con el kernel de Xen
# reboot
Despues de reiniciar podemos confirmar que estamos sobre un kernel de xen con el siguiente comando:
# uname -a Linux actiaxh 2.6.24-23-xen #1 SMP Mon Jan 26 03:09:12 UTC 2009 x86_64 GNU/Linux
Y podemos usar el coman xm para ver que este corriendo el Dominio0 de Xen
root@actiaxh:~# xm list Name ID Mem VCPUs State Time(s) Domain-0 0 1879 2 r----- 44.4
Preparando la configuración de xen-tools
Los archivos de configuración de xen-tools residen en el directoro /etc/xen-tools/, haremos algunos cambios en los archivos de configuración para personalizar nuestro entorno y predefinir los parametros de creación de maquinas virtuales.
root@actiaxh:~# cd /etc/xen-tools/
Respaldamos el archivo de configuración principal
root@actiaxh:/etc/xen-tools# cp xen-tools.conf xen-tools.conf.orig
Ahora cambiaremos los parametros:
Predefiniendo el Volume Group (VG) a utilizar
Aproximadamente en la linea 55 descomentamos la linea
# lvm = skx-vg
Por
lvm = VGsystem01
Definiendo parametros para discos de maquinas virtuales
Por default al crear una maquina virtual solo se crean dos volumens uno para la partición raíz de 4Gb y otro para la partición swap de 128Mb, cambiaremos esos valores.
Para cambiar el tamaño predeterminado para la partición raíz cambiamos el parametro:
size = 4Gb
Por
size = 6Gb
Para cambiar el tamaño predeterminado de la partición swap cambiamos el parametro:
swap = 128Mb
Por
swap = 512Mb
NOTA: Si no se desea utilizar los valores predeterminados, puede cambiarlos al momento de crear las maquinas virtuales con los parametros --size y --swap del comando xen-create-image.
Definiendo parametros para la memoría RAM asignada a las maquinas virtuales
Por default se asignan 128Mb de RAM a las maquinas virtuales, si queremos predefinir un tamaño de 512Mb, cambiamos el parametro
memory = 128Mb
Por
memory = 512Mb
Definiiendo la distribución por default para las maquinas virtuales
La configuración de xen-tools por default tiene definido a etch como la distribución predefinida, en nuestro caso utilizaremos la distribución Ubuntu Hardy, por lo que cambiaremos la opción
dist = etch
Por
dist = hardy
Definiendo el URL o ruta al repositorio de paquetes para hardy
xen-tools utiiliza la herramienta debootstrap para la automatización de maquinas virtuales, el metodo debootstrap por default baja todos los paquetes de Internet.
TODO: Meter nota sobre el cache.
Por default se tiene definido la ruta a los repositorios de Debian, para utilizar los repositorios de Ubuntu cambiamos
mirror = http://ftp.us.debian.org/debian/
Por
mirror = http://archive.ubuntu.com/ubuntu/
Este cambio será el último, guarde el archivo /etc/xen-tools/xen-tools.conf
Corrección de bug en el script de inicio xendomain
El script /etc/init.d/xendomains es el encargdo de iniciar y detener automaticamente las maquinas virtuales configuradas para arranque automático al inicio y el apagado del sistema.
Existe un bug en el script xendomains (bug 216761) que forma parte de paquete xen-utils-3.2, el problema es que cuando trata de iniciar las maquinas virtuales automaticamente o al tratar de detenerlas al apagar o reiniciar el sistema manda algunos errores en la pantalla referentes a un mal encomillado en las sentencias test del script.
# cd /etc/init.d/
Respaldamos el script original
root@actiaxh:/etc/init.d# cp xendomains xendomains.orig
Descargando y aplicando el parche
root@actiaxh:/etc/init.d# wget http://verde.e-compugraf.com/jm-confs/xen/hardy.xendomains.diff root@actiaxh:/etc/init.d# patch -p0 --verbose < hardy.xendomains.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xendomains.orig 2009-01-29 12:57:45.000000000 -0600 |+++ xendomains 2009-01-29 15:09:53.000000000 -0600 -------------------------- Patching file xendomains using Plan A... Hunk #1 succeeded at 63. Hunk #2 succeeded at 80. Hunk #3 succeeded at 183. Hunk #4 succeeded at 193. Hunk #5 succeeded at 268. Hunk #6 succeeded at 310. done
Para ver más información sobre este problema vea
.
NOTA: Este bug ya fue corregido en las ultimas versiones de Xen 3.2 den Ubuntu Hardy, ver historial de paquete xen 3.2
Corrigiendo bug en el script /usr/bin/xen-create-image
TODO: Creo que esto solo es para cuando usa archivos loopback para las particiones de los DomU.
El script /usr/bin/xen-create-image tiene un error
Los archivos de confguración que genera xen-tools utilizan el parametro file:// dentro del
bloque de configuración disk para indicar la ruta a los dispositivos que usará la maquina virtual,
en Xen 3.2, el parametro file se ha dejado de usar en favor del parametro tap:aio, por ejemplo
para vmbase:
Respaldando el archivo originial
root@actiaxh:~# cd /usr/bin/ root@actiaxh:/usr/bin# cp xen-create-image xen-create-image.orig
Descargando e instalando el parche
root@actiaxh:/usr/bin# wget http://verde.e-compugraf.com/jm-confs/xen/hardy.xen-create-image.diff root@actiaxh:/usr/bin# patch -p0 --verbose < hardy.xen-create-image.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen-create-image.orig 2009-02-07 05:23:16.000000000 -0600 |+++ xen-create-image 2009-02-07 05:24:22.000000000 -0600 -------------------------- Patching file xen-create-image using Plan A... Hunk #1 succeeded at 2408. done
Con este parche se corrige el problema.
Configuración del reloj de sistema y hardware
Es importante que el reloj del sistema Host este correctamente configurado y que se este sincronizando constantemente ya que el reloj de las maquinas virtuales es sincronizado con el reloj del Host.
Verificando que nuestro sistema este usando UTC
# date -u Sat Feb 7 14:28:04 UTC 2009
Ahora reconfiguraremos el sistema para definir la zona horaría
# dpkg-reconfigure tzdata
Seleccionar America y Mexico City.
Sincronización manual con ntpdate
# ntpdate mx.pool.ntp.org 7 Feb 08:30:30 ntpdate[9272]: adjust time server 201.155.229.129 offset -0.014936 sec
Ahora instalamos el servidor NTP para mantener sincronizado el reloj del sistema utilizando una fuente externa
# apt-get install ntp
Al terminar de instalar el paquete, el servidor NTP es automaticamente iniciado, además, el servicio ntp se configuro para arrancar automaticamente al inicio del sistema.
Agregando varios servidores del Pool de servidores NTP de México a la configuración del servidor NTP.
Editar el archvo /etc/ntp.conf y cambiar la linea
server ntp.ubuntu.com
Por
server mx.pool.ntp.org server mx.pool.ntp.org server mx.pool.ntp.org
Guardar el archivo y de configuración y reinciar el servicio ntp
root@actiaxh:~# /etc/init.d/ntp restart * Stopping NTP server ntpd [ OK ] * Starting NTP server ntpd [ OK ]
Creando una maquina virtual con dos particiones, una raiz y una swap
# xen-create-image --lvm=VGsystem01 --hostname=firewall --dhcp \ --install-method=debootstrap --mirror=file://media/cdrom/ --passwd
Por ahora no iniciaremos la maquina, aun falta la configuración de red?????????
Si deseamos que este DomU sea iniciado automaticamente al arranque del sistema debe de crear un enlace simbolico del archivo /etc/xen/firewall.cfg en el directorio /etc/xen/auto/, por ejemplo:
root@actiaxh:~# cd /etc/xen/auto root@actiaxh:/etc/xen/auto# ln -s ../firewall.cfg firewall root@actiaxh:/etc/xen/auto# ls -l firewall lrwxrwxrwx 1 root root 15 2009-02-09 10:12 firewall -> ../firewall.cfg
De ahora en adelante, cuando usted apague el servidor este DomU será apagado limpiamente y tambíen será iniciado automaticamente cuando el sistema arranque.
Creando una maquina virtual con más de un volumen
Si queremos crear DomU con más de un volumen, por ejemplo, queremos instalar un servidor que va a tener una partición independiente para /home y otra para /var, para lograr esta configuración debemos de crear más volumens logicos y asignarlos al sistema, afortunadamente xen-tools nos provee de las funcionalidades para lograr esta tarea de forma sencilla creando plantillas de particiones.
Crearemos una plantilla para el siguiente esquema de particiones:
| Volumen | Punto de Montaje | Tamaño |
| /dev/VGsystem01/fileserver-disk | / | 4GB |
| /dev/VGsystem01/fileserver-swap | swap | 1GB |
| /dev/VGsystem01/fileserver-home | /home | 10GB |
| /dev/VGsystem01/fileserver-var | /var | 10GB |
Ahora crearemos un archivo de configuración para nuestra plantilla, por ejemplo creamos el archivo /etc/xen-tools/partitions.d/root-swap-home-var con el siguiente contenido:
[root] size=4G type=ext3 mountpoint=/ options=sync,errors=remount-ro [swap] size=1G type=swap [home] size=10G type=ext3 mountpoint=/home [var] size=10G type=ext3 mountpoint=/var
Y para crear un nuevo DomU con que use este esquema utilizamos el siguiente comando:
xen-create-image --hostname=fileserver --partitions=root-swap-home-var --dhcp \ --install-method=debootstrap --mirror=file://media/cdrom/ --passwd
Nos mostrará una salida como la siguiente, donde nos muestra los volumenes logicos que se crearon
General Information
--------------------
Hostname : fileserver
Distribution : hardy
Partitions : swap 1G (swap)
/ 4G (ext3)
/home 10G (ext3)
/var 10G (ext3)
Image type : full
Memory size : 128Mb
Kernel path : /boot/vmlinuz-2.6.24-23-xen
Initrd path : /boot/initrd.img-2.6.24-23-xen
Networking Information
----------------------
IP Address : DHCP [MAC: 00:16:3E:44:7F:74]
Creating swap on /dev/VGData01/fileserver-swap
Done
Creating ext3 filesystem on /dev/VGsystem01/fileserver-disk
Done
Creating ext3 filesystem on /dev/VGsystem01/fileserver-home
Done
Creating ext3 filesystem on /dev/VGsystem01/fileserver-var
Done
Installation method: debootstrap
Esto creo los 4 volumens, en la configuración nos muestra así:
disk = [
'phy:/dev/VGsystem01/firewall-swap,xvda1,w',
'phy:/dev/VGsystem01/firewall-disk,xvda2,w',
'phy:/dev/VGsystem01/firewall-home,xvda3,w',
'phy:/dev/VGsystem01/firewall-var,xvda4,w',
]
Como agregar otro disco o volumen a un DomU
Sobre crear volumen LVM manual
Sobre agregar un RAID
Configuración de disk en .cfg
Prreparando la configuración de red en modo bridge para Xen
Xen puede ser configurado para permitir que las maquinas virtuales puedan usar la infraestrucutra de red existente y los segmentos de red. Xen permite configurar la red tanto del Dom0 como de los DomU, desde configuraciones básicas hasta otras más avanzadas usando bridges, STP, NAT, VLANs. En general, se puede configurar casi cualquier escenario que se pueda configurar en una red con Hosts no virtualizados.
La primer vez que se arranca el sistema con el kernel de Xen y sin tener definido un modo de configuración de red en Xen, se tiene un esquema similar al que se muestra en la siguiente figura
Basicamente existen dos tipos de configuración de red en xen, configuración basada en bridge y configuración enrutada.
En este documento se describirá la configuración de red en Xen en modo bridge.
La configuración de red en modo bridge es la más simple y fácil de configurar dentro de Xen. Este tipo de red permite de forma simple y transparente a los DomU usar una interfaz de red virtual conectada a un switch virtual (bridge) creado y configurado en Dom0, la interfaz de red fisica eth0 en Dom0 esta conectada fisicamente al switch de la empresa y esta misma a su vez esta conectada al switch virtual, por lo que toda la comunicación es transparente para todos los hosts ya que todos estan conectados virtualmente a un mismo switch.
Con una configuración en modo bridge nos permitirá:
- Las maquinas virtuales podrán utilizar direcciones IP estaticas tal y como lo hacen las demás maquinas conectadas a tu red fisica, o inclluso utilizar un servicio DHCP.
- Quieres que las maquinas virtuales sean vistas de forma transparente desde las maquinas en la red fisica, es decir, que haya flujo entre las dos redes de forma transparente.
- Incluso puede utilizar tecnologias como VLAN para crear redes locales virtuales y completamente aisladas unas de otras
- Su equipo Host puede tener varias interfaces de red fisicas y quiere asignar o delegar una interfaz o más interfaces exclusivamente para un host, de esta forma puede tener DomU conectados a diferentes redes fisicas, o incluso puede beneficiarse de las funcionalidades de VLAN y Bonding o Link Aggregation (Ether Channel)
Configurando Xen en modo bridge
Los parametros de configuración para la red en se estan en el archivo /etc/xen/xend-config.sxp, en este archivo deben de haber dos lineas donde se especifica el script para la creación de bridges (network-script) y otra para la creación de las interfaces virtuales para los DomU (vif-script).
Para configurar Xen en modo de red bridge ha y que asegurarnos que solo haya una linea descomentada de network-bridge y una de vif-script, tal y como se muestera abajo.
(network-script network-bridge) (vif-script vif-bridge)
Las configuraciones en modo bridge dependerá del numero de redes fisicas a conectar y de el número de interfaces fisicas en el Dom0, La configuración de Xen 3.2 en Ubuntu Hardy esta preconfigurada para sistemas con una sola interfaz fisica, y todas las los DomU utilizarán esta interfaz para el flujo de datos entre las diferentes redes, tanto de entrada como de salida,
Ahora reiniciamos el servidor para que inicie con la configuración de modo bridge.
Configuración predeterminada para una sola interfaz de red
Cuando Ubuntu inicia con xen en modo bridge se ejecuta el script /etc/xen/scripts/network-bridge realiza las siguientes tareas:
- Crea un nuevo bridge llamado xenbr0
- La interfaz Ethernet real eth0 es desactivada
- La dirección IP y MAC de eth es copiada a la interfaz de red virtual veth0
- La interfaz real eth0 es renombrada a peth0
- La interfaz virtual veth0 es renombrada a eth0
- peth y vif0.0 son agregadas al bridge xenbr0
- El bridge, peth0, eth0 y vif0.0 son activados
Al final el sistema quedará algo así:
Como vemos la interfaz fisica peth0 esta conectada al switch de la red LAN y a su vez al bridge eth0, el cual se usa como la interfaz local para el Dom0, y usará la configuración definida en /etc/network/interfaces, por ejemplo, el archivo /etc/network/interfaces en Dom0 esta así:
# Interfaz Local para red LAN auto eth0 iface eth0 inet static address 192.168.1.163 netmask 255.255.255.0 gateway 192.168.1.1
Podemos ver información de la red así
root@actiaxh:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:18:8b:fd:7b:7c
inet addr:192.168.1.163 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::218:8bff:fefd:7b7c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:251 errors:0 dropped:0 overruns:0 frame:0
TX packets:223 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:23932 (23.3 KB) TX bytes:23395 (22.8 KB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
peth0 Link encap:Ethernet HWaddr 00:18:8b:fd:7b:7c
inet6 addr: fe80::218:8bff:fefd:7b7c/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:247 errors:0 dropped:0 overruns:0 frame:0
TX packets:227 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:28074 (27.4 KB) TX bytes:24633 (24.0 KB)
Interrupt:16
Podemos ver el bridge y sus puertos con el siguiente comando
root@actiaxh:~# brctl show bridge name bridge id STP enabled interfaces eth0 8000.00188bfd7b7c no peth0
Cuando creamos maquinas virtuales con xen-create-image solo le asignamos la configuración para la interfaz de red eth0 (predeterminada) en DomU, esto creará un nuevo puerto en el bridge, una interfaz vif1.0 la cual estará conectada a la interfaz virtual eth0 en el DomU, como se muestra en la siguiente imagen.
Si crea más DomU se crearán más interfaces vifX, por ejemplo el DomU 2 tendrá asignada una interfaz virtual eth0 la cual estará conectada al bridge mediante el puerto vif2.0, todas las maquinas DomU por default peth0 para comunicarse con la demás red, habrá ocaciones en donde usted no quiere que todas sus maquinas salgan por una misma interfaz de red, ya se por cuestiones de rendimiento o de seguridad, en todo caso, usted puede agregar una interfaz de red fisica a su sistema y puede crear otro bridge a la que se conectará la maquina virtual, por ejemplo quiere tener una m aquina virtual como firewall/router y quiere tener una interfaz conectada directamente el modem de internet o router y que además este conectado al primer bridge para que todas las demás maquinas en la red puedan usar este equipo como gateway para salir a Innterne, en la sección se verá.
Configuración de Xen con red basada en bridge con multiples interfaces de red fisicas
La configuración actual no nos sirve del todo ya que solo se crea un bridge al que se le conecta una sola interfaz fisica, en nuestro caso vamos a agregar una interfaz fisica al sistema, la cual queremos que sea usada exclusivamente por el firewall/gateway, para esta nueva configuración tendremos que crear un script wrapper para /etc/xen/scripts/network-bridge el cual lo ejecutará dos veces para crear dos bridges.
Crearemos el script /etc/xen/scripts/multi-network-bridge con el siguiente contenido
#!/bin/sh /etc/xen/scripts/network-bridge $1 netdev=eth0 /etc/xen/scripts/network-bridge $1 netdev=eth1
Guarde el archivo y asignele permisos de ejecucón
root@actiaxh:~# chmod +x /etc/xen/scripts/multi-network-bridge
Ahora tiene que cambiar la ruta del script para crear bridges en el archivo de configuración /etc/xen/xend-config.sxp, cambiar de
(network-script network-bridge)
por
(network-script multi-network-bridge)
Ahora reinicie el equipo, este será el último por ahora.
Al iniciar Xen se ejecutará el script multi-network-script y creará el segundo bridge eth1 conectado a la interfaz peth0, como se ve aqui
root@actiaxh:~# ifconfig peth1
peth1 Link encap:Ethernet HWaddr 00:15:17:38:3e:28
UP BROADCAST PROMISC MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Base address:0xece0 Memory:fe9e0000-fea00000
También podemos ver la información de los bfidges
root@actiaxh:~# brctl show bridge name bridge id STP enabled interfaces eth0 8000.00188bfd7b7c no peth0 eth1 8000.001517383e28 no peth1
eth0 de DomU2 estará conectada al bridge eth0 y
eth1 de Domu2 estará conectada al bridge eth1 que estará conectada directamente al modem de internet
Modificaremos el archivo de configuración /etc/xen/firewall.cfg y cambiaremos la linea vif para indicarle los bridges
Por default easta así:
vif = [ 'mac=00:16:3E:EF:91:2F' ]
Ese MAC address se genero automáticamente y por default quedamos que utiliza el primer bridge eth0, para agregarle otra interfaz a este DomU debemos de cambiar la linea así:
vif = [ 'mac=00:16:3E:EF:91:2F, bridge=eth0',
'mac=00:16:3e:07:31:85, bridge=eth1']
Se recomienda utilizar el rango de direcciones MAC reservadas para Xen, el rango es 00:16:3e:xx:xx:xx, puede utilizar un script para generar MAC de forma aleatoria, cree el script /usr/local/bin/macgen.py con el siguiente contenido:
#! /usr/bin/python # macgen.py script generates a MAC address for Xen guests # import random mac = [ 0x00, 0x16, 0x3e, random.randint(0x00, 0x7f), random.randint(0x00, 0xff), random.randint(0x00, 0xff) ] print ':'.join(map(lambda x: "%02x" % x, mac))
Guarde el archivo y dele permisos de ejecución.
root@actiaxh:~# chmod +x /usr/local/bin/macgen.py
Ahora genere una dirección MAC aleatoria.
root@actiaxh:~# macgen.py 00:16:3e:29:c6:fb
NOTA: No olvide verificar que no este utilizando una dirección que ya este asignada.
Cuando ininicia la maquina firewall con esta configuración la red se verá así:
Comandos para administrar las maquinas virtuales
xm
Referencias
http://wiki.xensource.com/xenwiki/XenNetworking
El script /etc/init.d/xendomains es el encargdo de iniciar y detener automaticamente las maquinas virtuales al iniciar o apager el sistema.
Existe un bug en el script xendomains que forma parte de paquete xen-utils-3.2, el problema es que cuando trata de iniciar las maquinas virtuales automaticamente o al tratar de detenerlas al apagar o reiniciar el sistema manda algunos errores en la pantalla referentes a un mal encomillado en las sentencias test del script.
Cuando inicia el sistema se ven errores similares a este:
Starting auto Xen domains: ushldap.cfgcut: cut: No such file or directory /etc/init.d/xendomains: line 196: test: =: unary operator expected * [done]
NOTA: A pesar de los mensajes de error la maquina si es iniciada correctamente.
Y cuando se apaga o reinicia la maquina se ven errores como este:
Shutting down Xen domains:cut: cut: No such file or directory /etc/init.d/xendomains: line 313: test: =: unary operator expected Domain-0(save).Error: 'xm save' requires between 2 and 3 arguments. Usage: xm save [-c] <Domain> <CheckpointFile> ................ /etc/init.d/xendomains: line 271: test: =: unary operator expected .Domain ushldap terminated cut: cut: No such file or directory /etc/init.d/xendomains: line 271: test: =: unary operator expected .All domains terminated /etc/init.d/xendomains: line 305: 11063 Terminated watchdog_xm shutdown /etc/init.d/xendomains: line 305: 11083 Terminated watchdog_xm shutdown 1 * [done]
NOTA: A pesar de los mensajes de error las maquinas si se apagan correctamente, pero no se guarda el estado de la maquina.
A continuación les muestro un procedimiento que use para corregir el problema:
Crear un respaldo del archivo /etc/init.d/xendomains
# cd /etc/init.d/ # cp xendomains xendomains.org
Ahora descargamos el parche para corregir el script
# wget http://verde.e-compugraf.com/jm-confs/xen/hardy.xendomains.diff \ > -O xendomains.diff
Antes de aplicar el parche podemos verificar que se vaya a aplicar correctamente utilizando el modo --verbose y --dry-run del comando patch:
# patch -p0 --verbose --dry-run < xendomains.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xendomains.orig 2009-01-29 12:57:45.000000000 -0600 |+++ xendomains 2009-01-29 15:09:53.000000000 -0600 -------------------------- Patching file xendomains using Plan A... Hunk #1 succeeded at 63. Hunk #2 succeeded at 80. Hunk #3 succeeded at 183. Hunk #4 succeeded at 193. Hunk #5 succeeded at 268. Hunk #6 succeeded at 310. done
Si el resultado es similar entonces podemos aplicar el parche
# patch -p0 --verbose < xendomains.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xendomains.orig 2009-01-29 12:57:45.000000000 -0600 |+++ xendomains 2009-01-29 15:09:53.000000000 -0600 -------------------------- Patching file xendomains using Plan A... Hunk #1 succeeded at 63. Hunk #2 succeeded at 80. Hunk #3 succeeded at 183. Hunk #4 succeeded at 193. Hunk #5 succeeded at 268. Hunk #6 succeeded at 310. done
Ahora podemos probar que el script funcione correctamente
# invoke-rc.d xendomains start Starting auto Xen domains: ushldap.cfg * [done]
También podemos ver el status de las maquinas:
# invoke-rc.d xendomains status Checking for xendomains: ushldap * [running]
Y por último verificar que las maquinas se apagan correctamente y se guarda el estado de la misma
# invoke-rc.d xendomains stop Shutting down Xen domains: ushldap(save)... /etc/init.d/xendomains: line 187: 11988 Terminated watchdog_xm save /etc/init.d/xendomains: line 305: 11988 Terminated watchdog_xm save * [done]
Les dejo aquí como archivo adjunto el parche
Cuando instalamos maqunas virtuales (DomU) en Ubuntu Hardy mediante xen-tools nos encontraremos que en los logs de los DomU podremos encontrar mensajes como estos:
==> auth.log <== Jan 22 13:38:08 malazha sshd[22596]: pam_env(sshd:setcred): Unable to open env file: /etc/default/locale: No such file or directory
Este es un problema relacionado con los modulos de autenticación PAM, que por default cuando un usuario hace login automaticamente se le asigna un locale predeterminado.
Esto es debido a que cuando se instalan maquinas virtuales con xen-tools en el proceso de insalación no se generaron correctamente las locales,
Para solucionar este problema simplemente creamos el archivo /etc/default/locale con el siguiente contenido:
LANG="en_US.UTF-8"
Despues de crear el archivo ya no veremos más esos molestos mensajes en los logs o en los reportes enviados por LogWatch.
NOTA: En este caso se pone en inglés gringo con codificación UTF-8 (Unicode).
Adicionalmente puede generar otras locales, por ejemplo quiere generar las locales para Español de México con UTF-8:
# locale-gen es_MX.UTF-8
Si usamos las herramientas xen-tools para la creación de maquinas virtuales, es posible que utilices el metodo bootstrap para hacer la instalación de maquinas Debian/Ubuntu, el metodo bootstrap por default utiliza como fuente de instalación un mirror de debian en Internet, por ejemplo: http://ftp.us.debian.org/debian/, posiblemente nosotros ya tenemos CD de instalación o la imagen ISO del CD por lo que queremos utilizar este medio y así ahorrarnos el ancho de banda que por default usa el metodo bootstrap.
Para poder utilizar un CD como fuente de instalación para xen-tools haremos lo siguiente:
- Montar el CD de Ubuntu:
# mount /dev/hdd /media/cdrom/ mount: block device /dev/hdd is write-protected, mounting read-only
- Comprobamos que el CD este montado:
# mount | grep cd /dev/scd0 on /media/cdrom type iso9660 (ro)
El CD esta montado en /media/cdrom/
En el caso que desee utilizar una imagen ISO, entonces puede usar algo así:
# mount -o loop /tmp/ubuntu-8.04.1-server-i386.iso /media/cdrom
- Ejecutar el comando xen-create-image para crear el DomU
# xen-create-image --dir=/xen-images --hostname=vmbase --dhcp \ --install-method=debootstrap --dist=hardy --mirror=file://media/cdrom/ \ --passwd General Information -------------------- Hostname : vmbase Distribution : hardy Partitions : swap 128Mb (swap) / 4Gb (ext3) Image type : sparse Memory size : 128Mb Kernel path : /boot/vmlinuz-2.6.24-22-xen Initrd path : /boot/initrd.img-2.6.24-22-xen Networking Information ---------------------- IP Address : DHCP [MAC: 00:16:3E:A9:AA:B4] Creating partition image: /xen-images/domains/vmbase/swap.img Done Creating swap on /xen-images/domains/vmbase/swap.img Done Creating partition image: /xen-images/domains/vmbase/disk.img Done Creating ext3 filesystem on /xen-images/domains/vmbase/disk.img Done Installation method: debootstrap Done Running hooks Done No role scripts were specified. Skipping Creating Xen configuration file Done Setting up root password Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully All done Logfile produced at: /var/log/xen-tools/vmbase.log
- Viendo el archivo de configuración del DomU vmbase:
# grep -vE '^#|^$' /etc/xen/vmbase.cfg kernel = '/boot/vmlinuz-2.6.24-22-xen' ramdisk = '/boot/initrd.img-2.6.24-22-xen' memory = '128' root = '/dev/xvda2 ro' disk = [ 'file:/xen-images/domains/vmbase/swap.img,xvda1,w', 'file:/xen-images/domains/vmbase/disk.img,xvda2,w', ] name = 'vmbase' dhcp = 'dhcp' vif = [ 'mac=00:16:3E:A9:AA:B4' ] on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'restart' extra = '2 console=xvc0'
NOTA: Los archivos de confguración que genera xen-tools utilizan el parametro file:// dentro del
bloque de configuración disk para indicar la ruta a los dispositivos que usará la maquina virtual,
en Xen 3.2, el parametro file se ha dejado de usar en favor del parametro tap:aio, por ejemplo
para vmbase:
disk = [ 'file:/xen-images/domains/vmbase/swap.img,xvda1,w', 'file:/xen-images/domains/vmbase/disk.img,xvda2,w', ]
Debemos de cambiar file por tap:aio, podemos hacer una busqueda/reemplazo con sed:
# sed -e 's/file/tap:aio/' -i /etc/xen/vmbase.cfg y podemos comprobar la configuración: # grep -A3 ^disk /etc/xen/vmbase.cfg disk = [ 'tap:aio:/xen-images/domains/vmbase/swap.img,xvda1,w', 'tap:aio:/xen-images/domains/vmbase/disk.img,xvda2,w', ]
Si no se cambia el parametro file, entonces, al tratar de arrrancar un domU veremos un mensaje algo así:
# Error: Device 51713 (vbd) could not be connected. losetup /dev/loop2 /xen-images/domains/vmbase/swap.img failed
- Arrancando el DomU vmbase
# xm create -c vmbase.cfg Using config file ./vmbase.cfg;. Started domain vmbase [ 0.000000] Linux version 2.6.24-22-xen (buildd@vernadsky) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #1 SMP Mon Nov 24 21:30:37 UTC 2008 (Ubuntu 2.6.24-4.6-generic) ... ... * Mounting local filesystems... [ OK ] * Activating swapfile swap... [ OK ] * Checking minimum space in /tmp... [ OK ] * Configuring network interfaces... [ OK ] * Starting system log daemon... [ OK ] * Starting kernel log daemon... [ OK ] * Running local boot scripts (/etc/rc.local) [ OK ] Ubuntu 8.04.1 vmbase xvc0 vmbase login: root Password: Linux vmbase 2.6.24-22-xen #1 SMP Mon Nov 24 21:30:37 UTC 2008 i686 The programs included with the Ubuntu system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. To access official Ubuntu documentation, please visit: http://help.ubuntu.com/ root@vmbase:~#
- Verificando en el Dom0 que el domU este iniciado:
# xm list Name ID Mem VCPUs State Time(s) Domain-0 0 1893 2 r----- 1701.6 vmbase 8 128 1 -b---- 10.3
Si desea instalar la DomU utilizando volumens LVM debe de utilizar este comando:
# xen-create-image --fs=ext3 --size=4GB --swap=256Mb --lvm=VGData01 \
--hostname=ushldap --dhcp --install-method=debootstrap --dist=hardy \
--mirror=file://media/cdrom/ --passwd
General Information
--------------------
Hostname : ushldap
Distribution : hardy
Partitions : swap 256Mb (swap)
/ 4GB (ext3)
Image type : full
Memory size : 128Mb
Kernel path : /boot/vmlinuz-2.6.24-22-xen
Initrd path : /boot/initrd.img-2.6.24-22-xen
Networking Information
----------------------
IP Address : DHCP [MAC: 00:16:3E:D4:D7:DF]
Creating swap on /dev/VGData01/ushldap-swap
Done
Creating ext3 filesystem on /dev/VGData01/ushldap-disk
Done
Installation method: debootstrap
Done
Running hooks
Done
No role scripts were specified. Skipping
Creating Xen configuration file
Done
Setting up root password
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
All done
Logfile produced at:
/var/log/xen-tools/ushldap.log
Con el comando anterior se creo una maquina virtual y automaticamente creará los volumens logicos ushldap-swap y ushldap-disk en el Volume Group VGData01.
Add comment