Como hacer visible en toda la red nuestra máquina virtual con KVM, en Debian GNU/Linux

3
30094

Creación: 13-10-2007

Índice de contenidos

1. Introducción
2. Entorno
3. Instalación
4. Creando el bridge
5. Configurando la red en KVM
6. Un script para lanzar todo el «tinglado»
7. Comprobando que todo funciona según lo esperado
8. Conclusiones
9. Sobre el autor

1. Introducción

En el tutorial
https://adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=debianKvm
hemos visto como conseguir una máquina virtual con KVM.

Incluso vimos cono configurar la red para acceder desde la máquina que hace de anfitrión o host (la máquina física) a la máquina que hace de invitadoguest (la máquina virtual). Pero esta configuración se nos queda corta si lo que queremos es acceder a la máquina virtual como si se tratar de otra máquina cualquier en nuestra red, o como si se tratara de un servidor para explotar sus servicios.

Este tutorial sería la continuación de aquel, y vamos a ver como conseguir que la máquina virtual se vea como otra máquina más en nuestra red. Para ello usaremos un bridge que, básicamente, se encarga de pasar paquetes de una interfaz a otra (en nuestro caso pasará paquetes de la interfaz del host a la interfaz del guest, y viceversa).

Este tutorial está inspirado en el que ya publico mi compañero Germán
(https://adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=qemuIntranetDebian)
sobre como hacer lo mismo en el Qemu (veréis que se muy similar). Aquí vamos a ver como hacerlo para el KVM.

2. Entorno

El tutorial está escrito usando el siguiente entorno:

  • Hardware: Portátil Asus G1 (Core 2 Duo a 2.1 GHz, 2048 MB RAM, 120 GB HD).
  • Sistema Operativo: GNU / Linux, Debian (unstable), Kernel 2.6.22, KDE 3.5
  • kvm 36-0.1
  • bridge-utils 1.2-1


3. Instalación

Sólo necesitamos instalar el paquete bridge-utils:

# apt-get -u install bridge-utils

4. Creando el bridge

Modificamos el fichero /etc/network/interfaces y añadimos:

iface br0 inet dhcp
bridge_ports
eth1
bridge_stp off

Con estas líneas estamos creando una nueva interfaz llamada br0, que será el bridge.

Nótese que no tenemos ninguna línea del estilo auto br0, esto es porque no queremos que el bridge se levante siempre que se arranque la máquina, el bridge sólo lo vamos a levantar cuando usemos el KVM (la interfaz la levantaremos con ifup br0, pero eso lo veremos un poco más adelante).

Con bridge_ports eth1, lo que estamos haciendo es añadir al bridge el puerto eth1. Podríamos decir que estamos definiendo uno de los extremos del bridge (luego veremos como definimos el el otro extremo).

STP (Spanning Tree Protocol) es un protocolo para correr múltiples bridges, o bridges redundantes. Como no es nuestro caso lo desactivamos lo desactivamos con bridge_stp off. Como no usamos STP no hace falta que tengamos líneas del estilo: bridge_fd 9, bridge_hello 2, o bridge_maxage 12, ya que esto lo que hace es definir
parámetros del STP.

5. Configurando la red en KVM

Ahora vamos a editar el fichero /etc/kvm/kvm-ifup, y cambiamos su contenido por (quitamos lo que habíamos puesto en el otro tutorial y lo sustituimos por esto):

ifconfig $1 0.0.0.0 promisc
up
brctl addif br0 $1
exit 0

Aquí vemos como con brctl addif br0 $1 estamos añadiendo el otro extremo del bridge. Nuestro bridge ya está completo y pasará los paquetes de eth1 (el sistema host) a tap0 (el sistema guest) y viceversa.


6. Un script para lanzar todo el «tinglado»

Vamos a mostrar un sencillo script para lanzar nuestras imágenes. Podría ser algo así:

#!/bin/sh

#
Para ejecutar con
qemu
#VIRTUALIZATION_MODULE=kqemu
#VIRTUALIZATION_PROGRAM=qemu

#
Para ejecutar con kvm. Recomendable si el HW lo
soporta.

VIRTUALIZATION_MODULE=kvm-intel
VIRTUALIZATION_PROGRAM=kvm

#
Parámetros para lanzar qemu o kvm

QEMU_PARAMS="-m
1024 -net nic -net tap"

#
Los siguientes parámetros del qemu permiten arrancar la imagen
como un demonio. Es decir, sin
# salida gráfica. Esto puede
resultar muy útil para arrancar la imagen en un servidor. Si
dentro
# la imagen tienes instalado un VNC, puede ser el
complemento perfecto para administrar la imagen.
#--nographic
--daemonize

#
El nombre de la imagen que vamos a lanzar

IMAGE="windowsXP.qcow2"

#
Levantamos el módulo del kernel (qemu o kvm)

modprobe
$VIRTUALIZATION_MODULE

echo 1024 >
/proc/sys/dev/rtc/max-user-freq

#
Levantamos el bridge

ifup br0

#
Ejecutamos la imagen

$VIRTUALIZATION_PROGRAM
$QEMU_PARAMS $@ -hda $IMAGE

#
Tiramos el bridge

ifdown br0


7. Comprobando que todo funciona según lo esperado

Después de arrancar la imagen con el script que presentábamos en el apartado anterior, podemos ejecutar:

# brctl show

y deberíamos ver algo como:

bridge name     bridge id               STP enabled     interfaces
br0             8000.001a928d3dd1       no              eth1
                                                        tap0

Podemos apreciar como el bridge br0 está levantado y «enganchado» a eth1 y tap0.

Si entramos en nuestra imagen (el XP que estamos corriendo como sistema guest) deberíamos tener acceso a Internet, pero ojo, debemos acordarnos de configurar el XP para que esté dentro de nuestra red. Ya sea con DHCP o con IP fija, debemos configurar el Windwos XP. Una vez configurado adecuadamente nuestro sistema guest, deberíamos poder hacerle ping o acceder a sus servicios desde cualquier punto de nuestra red.

8. Conclusiones

Veis que prácticamente hemos hecho lo mismo que nos proponía Germán en su tutorila, pero un poco adaptado a KVM.

Además hemos presentado un posible script para lanzar las imágenes que, cambiando un par de variables, nos sirva tanto para usarlo con qemu como con kvm.

Y en definitiva hemos conseguido lo que queríamos, poder acceder desde cualquier punto de la red a nuestra máquina virtual.

9. Sobre el autor

Alejandro Pérez García, Ingeniero en Informática (especialidad de Ingeniería del Software)

Socio fundador de Autentia (Formación, Consultoría, Desarrollo de sistemas transaccionales)

mailto:alejandropg@autentia.com

Autentia Real Business Solutions S.L. – «Soporte a Desarrollo»

http://www.autentia.com

 

Alejandro Pérez García
Alejandro es socio fundador de Autentia y nuestro experto en Java EE, Linux y optimización de aplicaciones empresariales. Ingeniero en Informática y Certified ScrumMaster. Seguir @alejandropgarci Si te gusta lo que ves, puedes contratarle para darte ayuda con soporte experto, impartir cursos presenciales en tu empresa o para que realicemos tus proyectos como factoría (Madrid). Puedes encontrarme en Autentia: Ofrecemos servicios de soporte a desarrollo, factoría y formación.

3 COMENTARIOS

  1. Las cookies son breves informaciones que se envían y almacenan en el disco duro del computador del usuario por medio de
    su navegador cuando éste se conecta a una web.

  2. Hola, Alejandro.
    No me sale el procedimiento.
    En mi hospedador host o baremetal (con Centos), en el que están alojadas las VM’s no me aparece el directorio /etc/kvm.

    Tengo un lío bastante considerable.

    ¿Serías tan amable de echarme un cable?
    Saludetes y gracias.

    [root@awesome ~]# brctl show
    bridge name bridge id STP enabled interfaces
    br1 8000.000000000000 no
    br2 8000.3ca82aa04510 no eno1
    virbr0 8000.525400284d1d yes virbr0-nic
    virbr1 8000.525400b9ea9a yes virbr1-nic
    virbr2 8000.525400f3e2ee yes virbr2-nic
    vnet1
    virbr3 8000.5254003336a2 yes virbr3-nic

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad