Ver unidades y sus particiones (para detectar el pendrive conectado)

fdisk -l

Montar el pendrive, que lo encontramos en /dev/sdb1 (nos damos cuenta porque es la unidad que
aparece abajo del todo como FAT o WIN95 FAT

mount -t vfat /dev/sdb1 /mnt

Vamos hacia el punto de montaje del pen, miramos el contenido, encontramos el firmware de las
tarjetas ahí

cd /mnt
ls

Instalamos el firmware de las tarjetas de red

dpkg -i firmware-bnx2_0.14+lenny2_all.deb

Reiniciamos

shutdown -r now

Miro la configuración para asegurarme que las tarjetas fueron reconocidas por el sistema (eth0 a
eth5)

ifconfig

Edito el archivo de configuración de las interfaces de red para levantar la tarjeta eth0, la primera de
izquierda a derecha mirando desde atras el servidor

nano /etc/network/interfaces

# This file describes the network interfaces available on your system

# and how to activate them. For more information, see interfaces(5).

# The loopback network interface

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.1.100
netmask 255.255.0.0
network 192.168.0.0
broadcast 192.168.255.255
gateway 192.168.1.7

auto eth1
iface eth1 inet manual

auto eth2
iface eth2 inet manual

auto eth3
iface eth3 inet manual

auto eth4
iface eth4 inet manual

auto eth5
iface eth5 inet manual

Levanto la tarjeta eth0 con la nueva configuración

ifup eth0

Pruebo un ping en la red

ping 192.168.1.1

Configuro dns

nano /etc/resolv.conf

search utu.edu.uy
domain utu.edu.uy

nameserver 192.168.1.1
nameserver 192.168.1.2
nameserver 192.168.1.7

Hago ping a nombres de dominio para saber si los dns están bien reconocidos (puedo tocar
CTRL+C para cortar la secuencia, ya que a diferencia de windows, el Linux la opción -t viene por
defecto)

ping delta1
ping delta2

Edito el archivo de configuración de apt, el sistema de paquetes de Debian, coloco un repositorio

válido para poder actualizar e instalar paquetes (ftp.debian.org)

nano /etc/apt/sources.list

deb http://security.debian.org/ lenny/updates main

deb-src http://security.debian.org/ lenny/updates main

deb http://volatile.debian.org/debian-volatile lenny/volatile main

deb-src http://volatile.debian.org/debian-volatile lenny/volatile main

deb http://ftp.debian.org/ lenny main

Actualizo la base de datos de paquetes a partir de dicho repositorio

apt-get update

Instalo ssh para administrar remotamente el servidor

apt-get install openssh-server

Salgo de la sesión, ya que ahora puedo acceder desde otro equipo de la red

exit

Instalo los paquetes de xen (el sistema xen, el hipervisor, las herramientas, y el kernel)

apt-get install xen

apt-get install xen-hypervisor
apt-get install xen-tools
apt-get install xen-linux-system-2.6.26-2-xen-amd64

Reinicio el servidor (otra manera, más genérica que el shutdown -r)

reboot

Voy al directorio de configuración de xen

cd /etc/xen

Dentro hay un directorio scripts donde se encuentran los scripts de configuración, nos interesa el
script que genera el bridge de las tarjetas de red

cd scripts

Genero un "wrapper" ya que el script network-bridge está hecho para crear bridge sobre una sola
tarjeta , este script llama a network-bridge para crear un bridge por cada tarjeta de red

nano network-bridge-wrapper

#!/bin/sh
/etc/xen/scripts/network-bridge "$@" netdev=eth0
/etc/xen/scripts/network-bridge "$@" netdev=eth1
/etc/xen/scripts/network-bridge "$@" netdev=eth2
/etc/xen/scripts/network-bridge "$@" netdev=eth3
/etc/xen/scripts/network-bridge "$@" netdev=eth4
/etc/xen/scripts/network-bridge "$@" netdev=eth5

Reinicio el servicio de xen

/etc/init.d/xend restart

Si no inicia el bridge sobre las tarjetas podemos ejecutar el script a manopla

sh network-bridge-wrapper restart
o
sh network-bridge-wrapper stop
sh network-bridge-wrapper start

Obviamente, si no levanté las otras tarjetas con una ip válida, nunca va a levantar sus bridges, había
que equivocarse para aprender

nano /etc/network/interfaces

ifup eth1
ifup eth2
ifup eth3
ifup eth4
ifup eth5

sh network-bridge-wrapper start

Siempre es bueno reiniciar

reboot

Ahora, ya que vamos a levantar nuestra primera máquina virtual, debemos generar su archivo de
disco duro, a partir del dispositivo "zero" del sistema, de tamaño 20000 clusters de 1MB cada uno

cd /home
dd if=/dev/zero of=./alpha2.img bs=1M count=20000

Vamos a la carpeta de xen nuevamente, ahora para levantar el archivo de configuración de máquina
virtual previamente subido al equipo por ssh con winscp desde Windows o con gftp desde Linux

cd /etc/xen

Creamos el archivo de configuración de la máquina virtual (establecemos sus parámetros, unidades,

memoria, procesadores, etc)

nano alpha2.cfg

import os, re
arch = os.uname()[4]
if re.search('64', arch):
arch_libdir = 'lib64'
else:
arch_libdir = 'lib'

kernel = "/usr/lib/xen-3.2-1/boot/hvmloader"

builder='hvm'

vcpus = 8

memory = 2048
shadow_memory = 8

name = "alpha2"

vif = [ 'bridge=eth0, type=ioemu, mac=00:16:3e:00:00:22' ]

disk = [ 'tap:aio:/home/alpha2.img,hda,w', 'tap:aio:/root/win2003sp2.iso,hdb:cdrom,r' ]

boot="dc"

vnc = 1
#vncunused=0
sdl = 0
vncconsole=1
vncdisplay=0
#vnclisten='0.0.0.0'
acpi = 1
apic = 1
device_model = '/usr/' + arch_libdir + '/xen-3.2-1/bin/qemu-dm'
stdvga=0
serial='pty'

usbdevice='tablet'

on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

Detalle de cada parámetro a modificar (el esqueleto siempre es el mismo):

builder: le decimos que va a ser una máquina virtualizada por hardware (hvm) o paravirtualizada
desde kernel (pvm), en nuestro caso hvm porque el procesador lo soporta y resulta en una mejor
performance y corre cualquier sistema operativo
vcpus: cantidad de procesadores que queremos que vea la máquina
memory: cantidad de memoria que debe tomar la máquina de la memoria real del equipo
shadow memory: buscar en Google definición completa de esto, escapa a los alcances de este
“how to”
name: nombre del dominio virtual, para operar con él luego de levantado se utiliza este nombre, no
su .cfg
vif: “virtual interfaces”, interfaces de red virtualizadas, tiene varios parámetros, entre ellos
bridge (sobre que tarjeta haremos bridge), type (tipo de virtualización, ioemu por defecto) y mac
(la dirección MAC de la interface virtual a crear, xen tiene reservadas todas las que arrancan por
“00:16:3e”
disk: unidades ide, sean discos duros o unidades ópticas, o incluso unidades de cinta, cada unidad
se especifica entre comillas y en el siguiente órden: tipo_de_acceso:/archivo_de_disco,
bus_y_tipo_de_unidad, modo_de_acceso, el tipo de acceso es por lo general tap:aio (acceso
directo); el bus ide se divide en 4, primary master (hda), primary slave (hdb), secondary master
(hdc) y secondary slave (hdd), solo eso es disco duro, si es unidad óptica hay que declararla
mediante cdrom; y el modo de acceso por regla general va a ser w para lectura-escritura y r para
solo lectura
boot: secuencia de arranque de la BIOS de la máquina virtual, a y b disketeras, c disco duro, d
unidad óptica
vnc/sdl: uno va a ser 0 para desactivado, el otro 1 para activado, por lo general preferimos vnc para
conectarnos a las pantallas de las máquinas, es más moderno y más amigable en todo sentido, sdl
existe por compatibilidad
vncdisplay: número de pantalla vnc del sistema de virtualización, cada máquina tiene que tener uno
distinto para poder acceder
on_poweroff: que hace la máquina virtual cuando la apagamos (en este caso, se apaga)
on_reboot: que hacer cuando se reinicia el sistema dentro de una máquina
on_crash: que se debe hacer ante un cuelgue manejable

Levantamos el archivo de configuración mencionado anteriormente

xm create alpha2.cfg

Miramos si figura en la lista de máquinas virtuales (Dom0 siempre figura, es el xen que se virtualiza
a si mismo, concepto muy abstracto no?)

xm list

Podemos editar el archivo de conf de la virtual aún en ejecución de la misma, para activarlo hay que
dar de baja y volver a levantar la máquina

nano alpha2.cfg

Bajamos la máquina ya que no tiene nada instalado no tiene por qué reiniciarse desde dentro, si no
hay sistema no hay nada que se dañe por apagar "del boton"

xm destroy alpha2

Vamos hacia /root, ahí vamos a colocar las iso de los sistemas que usaremos en las máquinas
virtuales

cd /root

Como el nombre de la iso era demasiado complicado, lo renombro a algo más facil (en Linux
renombrar es mover a la misma carpeta con distinto nombre, lógico, en DOS es igual desde abajo
pero al usuario le es trasparente)

mv win_03_Sp2.iso win2003sp2.iso

Me cercioro que quedó con el nombre que yo quería

ls /root

Doy de alta la nueva unidad de cd cargada con la iso

nano alpha2.cfg

Levanto la máquina virtual

xm create alpha2.cfg

Testeo que tengo conectividad con la nueva máquina

ping alpha2

Puedo también testear que la máquina virtual realmente esté levantada y que no sea otro alpha2 que
ya estaba en la red

xm list