Aug 15, 2011

Adding a KVM hypervisor to OpenNebula (II)

Once I have finished to configure the KVM computing node, Adding a KVM hypervisor to OpenNebula (I), today I am going to conclude this series of technical articles about OpenNebula by setting a new instance up on kvm01.

First of all, I am going to use for my testing, a ttylinux image, downloaded directly from the OpenNebula website. This sort of Linux distribution is designed to consume fewer resources than a typical operating system such as Debian or CentOS.

oneadmin@frontend01:/tmp$ wget http://dev.opennebula.org/attachments/download/170/ttylinux.tar.gz

oneadmin@frontend01:/tmp$ tar xvzf ttylinux.tar.gz ; cd ~/templates

Next step is to define an image template so as to register it into OpenNebula.

oneadmin@frontend01:~/templates$ cat ttylinux.img
NAME        = "ttylinux"
PATH        = /tmp/ttylinux.img
DESCRIPTION = "Very small Linux distribution based on a 2.6 kernel"

oneadmin@frontend01:~/templates$ oneimage register ttylinux.img

oneadmin@frontend01:~/templates$ oneimage list
ID     USER                 NAME TYPE              REGTIME PUB PER STAT  #VMS
 0 oneadmin   Ubuntu Server 8.04   OS   Jul 02, 2011 10:34  No  No  rdy     0
 1 oneadmin             ttylinux   OS   Aug 07, 2011 18:30  No  No  rdy     0

Now we have a virtual image ready to be used on our KVM nodes, in this case kvm01.

oneadmin@frontend01:~/templates$ ls -lh ../var/images/8625d68b699fd30e64360471eb2c38fed47fcfb6
-rw-rw---- 1 oneadmin cloud 40M 2011-08-07 20:30 var/images/8625d68b699fd30e64360471eb2c38fed47fcfb6

oneadmin@frontend01:~/templates$ file ../var/images/8625d68b699fd30e64360471eb2c38fed47fcfb6
var/images/8625d68b699fd30e64360471eb2c38fed47fcfb6: x86 boot sector, LInux i386 boot LOader; partition 1: ID=0x83, starthead 1, startsector 63, 81585 sectors, code offset 0xeb

Then we have to make up a virtual network which will be utilized by all virtual machines built on our KVM computing node. Note that the key of this network is the bridge created in the previous article.

oneadmin@frontend01:~/templates$ cat kvm.net
NAME            = "KVM Network"
TYPE            = RANGED
PUBLIC          = NO
BRIDGE          = br0
NETWORK_ADDRESS = 192.168.1.160
NETWORK_SIZE    = 16
NETMASK         = 255.255.255.0
GATEWAY         = 192.168.1.1
DNS             = 194.30.0.1

oneadmin@frontend01:~/templates$ onevnet create kvm.net

oneadmin@frontend01:~/templates$ onevnet list
ID USER     NAME              TYPE BRIDGE P #LEASES
 0 oneadmin KVM Network     Ranged    br0 N       0

And lastly, we just have to set an instance template up where we outline the characteristics of our virtual machine and thus, to be able to run it over kvm01.

oneadmin@frontend01:~/templates$ cat ttylinux01.vm
NAME   = ttylinux01
CPU    = 1
MEMORY = 128

DISK   = [ SOURCE = "/srv/cloud/one/var/images/8625d68b699fd30e64360471eb2c38fed47fcfb6",
           TARGET = "hda" ]

NIC    = [ NETWORK = "KVM Network" ]

oneadmin@frontend01:~/templates$ onevm create ttylinux01.vm

oneadmin@frontend01:~/templates$ onevm list
ID     USER     NAME STAT CPU     MEM        HOSTNAME        TIME
 0 oneadmin ttylinux runn   0      0K           kvm01 00 00:01:03


5 comments:

  1. Podría poner este mensaje en esta entrada o en otra cualquiera: ¡qué pedazo de blog! Muy interesantes todas las entradas, te estoy siguiendo ...

    ReplyDelete
  2. Gracias Alberto, tus comentarios serán bien recibidos, ;-)

    ReplyDelete
  3. Hola Javier. He intentado montar opennebula por mi cuenta, y luego he seguido tus dos post, pero el caso es que no consigo que las vm vean la red (ni que la red vean a las vm) si ven la ip del bridge pero hasta ahí. Imagino que debe ser un problema con iptables, se te ocurre algo?

    ReplyDelete
    Replies
    1. Hola Manolo, ni idea qué puede estar pasando... yo lo que haría sería poner un tcpdump, capturar el tráfico de red y analizarlo posteriormente con wireshark.

      Los puntos del tcpdump interesantes serían el interfaz del propio bridge y la máquina destino de la red con la que estás tratando de comunicarte. Al ser un bridge, es probable que OpenNebula no haga ningún tipo de NAT y los paquetes estén llegando al destino con la dirección IP origen de la VM, con lo que igual el destino no sabe por dónde retornar los paquetes.

      Tú piensa que para la VM vea la red debe de tener una dirección IP perteneciente a esa subred. Me imagino que eso lo habrás tenido en cuenta.

      Delete
    2. Gracias Javier, ya localize el problema. Pongo la solución por aquí por si alguien más se tropieza. No se si configuré la red virtual como privada pero el caso es que tenía las reglas de ebtables filtrando los paquetes de las macs que no eran. Limpie la tabla del ebtables y todo a las mil maravillas.

      PD: Gracias por la respuesta, los articulos y la web ya te tengo en mis favoritos

      Delete