La miseria, es lo único que; aun repartida a muchos, toca en abundancia. Esta historia se desarrolla en un policlínico remoto y olvidado; donde tuve que facturar con un 50% de descuento para que dejaran de decir “por favor ayuda”.

La superioridad tecnológica de XenServer es indiscutible: seguro (esquema de pacheo de XOA), versátil (la XAPI), robusto (CentOS) y sencillo (Xen Orchestra Appliance) y enterprise (next, next, next, install, boot, ready!) PERO:

Cuando los megas de RAM se cuentan con los dedos de una mano, el peso de la XAPI y la necesidad de tener otra máquina corriendo para el XenOrchestra, DUELEN. Tomemos por ejemplo, una máquina con 2 gigas de RAM. En mi caso tengo Xen Orchestra en la laptop, pero desplegar node+servidor en una máquina virtual más; no es una opción en este escenario. Que se jodan XOA, XenServer y los capitalistas de la Citrix ¡Hora de ser completamente libre!

Yo hubiera matado la jugada con LXC pero el cliente insiste en usar los 3 sistemas; tal como está en mi esquema del calixto. Lo cierto es que 3 contenedores no inspiran mucha confianza. Tampoco KVM es una buena opción, sobre todo cuado no hay un super microprocesador.

Rercordemos que: Xen, mejor con CPU, pero peor IO. Mientras que: KVM, mejor IO, pero CPU más penalizado.

El menú:

Dos interfaces de red, un disco de 500G, 2G de ram, y un CPU que por suerte soporta virtualización. Un switch de 24 puertos a 100 megas, otro a gigabit. Un friki que oye reguetton, una enfermera de post-guardia (la mujer del friki) y 5 pesos de café en un vaso plástico.

Las VM y su RAM:

• debian como servidor de correo (postfix y dovecot, sin webmail) - 512M
• alpine como ruter (dns, dhcp y firewall) - 512M
• FreeBSD como proxy (squid) - 1G

La brujería:

Con suerte No se matarán por los 2 Gigas de RAM. El squid con usuarios PAM como autenticación y casi nada en las ACL, además en BSD no come mucha ram. Alpine es un chiste en lo que a RAM se refiere y el de correo no tendrá un webmail así que plin.

Los 3 servidores tendrán unos cortafuegos super estrictos. Descartarán todo tipo de ICMP para evitar cuellos de botella. La LAN funciona a 100 megas y el servidor está conectado al ÚNICO switch a gigabit. Osea, el server, un switch y un cable al netgear viejo que está a 100 megas. Con eso, la difusión “uno a varios” será mayor y no habrá congestiones, mientras que la peticiones entrantes (individual) no excederán el 10% el ancho de vianda del servidor. La ley del embudo.

Entrando en materia:

Volvemos a la génesis de xen pero usaremos virt-manager para manejar el hypervisor.

Primero que todo, llevamos a cabo una instalación típica de Xen en un debian 8. Nada que contar; el clásico Dom0.

1
2
3

 aptitude update
 aptitude install xen-linux-system
 dpkg-divert --divert /etc/grub.d/08_linux_xen --rename /etc/grub.d/20_linux_xen

Esta PC tiene dos interfaz de red. Una de cara al router, con una ip/29 “públicas” y otra interfaz, de cara a la LAN. Por tanto crearemos 3 puentes:

• br0 de eth0 hacia el router
• br1 de eth1 hacia la LAN
• br2 para comunicación interna (costumbre, nunca está de más)

Así me quedó el /etc/network/interfaces

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

 # arriba todo el mundo
 auto lo eth0 eth1 br0 br1 br2

 # el lo
 iface lo inet loopback

 # levanta las dos interfacess
 # pa cuando el bridge se levante
 iface eth0 inet manual
 iface eth1 inet manual

 # puente de la interfaz onboard (WAN)
 iface br0 inet static
    bridge_ports eth0
    bridge_stp off
    bridge_waitport 0
    bridge_fd 0

 # puente de la interfaz PCI (LAN)
 # y la ip del hypervisor para hacer SSH
 iface br1 inet manual
    address 192.168.99.10
    netmask 255.255.255.0
    bridge_ports eth1
    bridge_stp off
    bridge_waitport 0
    bridge_fd 0

 # una interfaz de red local de las VM
 # note que el puente apunta a la interfaz none
 iface br2 inet static
    bridge_ports eth0
    address 169.254.0.1
    netmask 255.255.255.0
    bridge_ports none
    bridge_stp off
    bridge_waitport 0
    bridge_fd 0

Ahora vienen los toques mágicos. Libvirt!

1

 apt-get install libvirt-bin

De más está que te diga, que este debian fue instalado sobre LVM. Crea el directorio /etc/libvirt/storage/ y dentro, le pondremos un fichero llamado xenvg.xml o comotedelagana.xml. Al instalar con el particionado guiado; el grupo llama hostname-vg, en este caso xen-vg. Note como la cláusula path, apunta hacia el mapper del grupo de volumen group y que tanto nombre del fichero como del pool; no deben contener espacios ni “-”.

1
2
3
4
5
6

<pool type='logical'>
  <name>xenvg</name>
  <target>
    <path>/dev/xen-vg</path>
  </target>
</pool>

Ahora inicializaremos el pool de libvirt:

1
2
3

 virsh pool-define /etc/libvirt/storage/xenvg.xml
 virsh pool-start xenvg
 virsh pool-autostart xenvg

Corre virsh pool-info xenvg para ver si todo pinchó. Llegado a este punto te recomiendo reiniciar…

De regreso a la máquina del informático…

Arrancamos el virt-manager:

De más está que te diga, que las operaciones de libvirt se hacen por ssh, así que debes tener ssh en la máquina remota; preferiblemente con autenticación por llaves y no por password.

1
2

 ssh-keygen
 ssh-copy-id root@192.168.99.10

Vamos a File y Add connection, agregaremos una conexión del tipo Xen.

De aquí en adelante, es la misma mecánica básica de virt-manager. Solo quiero hacer un apartado para crear un pool más y me refrito a un pool donde pondremos los ficheros “.iso”.

Creamos el directorio donde meteremos los ISO y copiamos el iso que querramos para allá. Como ya me conocen, soy el enemigo de las plantillas. Confío más en lo que yo mismo hago que en lo que hacen otros.

1
2

 ssh root@192.168.99.10 mkdir /opt/isos/
 scp ~/Downloads/ISO/*.iso root@192.168.99.10:/opt/isos/

Selecciona la conexión al Xen, y haz click en el botón de crear nueva máquina.

El asistente nos llevará al gestor de almacenamiento. Seleccionamos “Local install media” y click en siguiente. Luego “Use ISO image”.

Aquí haces click en Browse y te conduce al lugar donde crearemos los ISO. Inmediatamente te verás en la pantalla donde te pedirá que selecciones los storage volume. En la imagen se puede apreciar que ya existe uno llamado “iso”, pero de igual, para el ejemplo mostraremos como se creará.

Odio las interfaz visual, como hacen pasar trabajo! Pero virsh no es cosa jamón para mi cliente que no es del todo un hacha en linux.

Bueno… has click en el signo de más color azul y te mostrará un dialogo que muestra “Create Storage Pool”. Lo nombramos “iso” y le decimos que será del tipo “dir”. O sea un directorio común en el sistema de archivos.

Como segundo argumento, nos pedirá la ruta. Le daremos la que creamos en el servidor, en este caso /opt/isos.

Sí todo salió bien, verás los .iso que tiene el directorio.

Al hacer click en el iso seleccionado, vuelve el asistente y muestra que se usará dicho iso.

Lo demás es pa mongo, la RAM el disco que creamos en el SR “default”, etc…

Marcamos el check que dice “Customize configuration before install” y caeremos en la pantalla que muestra todos los detalles de la máquina.

Esta pantalla es importante; no permite configurar de manera más exquisita el hardware. Por ejemplo, las interfaces de redes, yo quiero que tenga como primera interfaz, la que apunta a br0 y como segunda, la que apunta a br2. Además, algunas veces la máquinas traen una wacom tablet como interfaz (mariconerías del virt-manager).

En fin, así me quedó la mía.