Introducción a VNX

INTRODUCCIÓN A VNX GP1 Seguridad En esta actividad presentaremos la herramienta de emulación de redes VNX, que nos servirá de base para la realización de la parte práctica de la asignatura Introducción a VNX Página 1 ÁREA DE INGENIERÍA TELEMÁTICA Introducción a VNX S E G U R I D A D INTRODUCCIÓN En esta sesión de grupo pequeño presentaremos la herramienta de emulación de redes VNX (http://web.dit.upm.es/vnxwiki/index.php/Main_Page), que utilizaremos a lo largo de toda la asignatura para reproducir distintos escenarios de seguridad. Entendemos por escenario de seguridad a un conjunto de redes, dispositivos de red y equipos finales sobre los cuales queremos estudiar o evaluar algún aspecto relacionado con la seguridad de la información y de sistemas y que reproducimos para tal fin. Para poder reproducir escenarios, una tecnología clave es la virtualización. La virtualización es una tecnología que simplifica mucho la infraestructura necesaria para el despliegue de escenarios pero que todavía lleva asociados altos costes de creación, despliegue y configuración de los escenarios. La utilización de VNX permite abstraerse de la complejidad del despliegue y configuración del escenario y centrarse únicamente en aquellos aspectos que se quieren trabajar en el laboratorio. Un escenario donde esto queda claro es un laboratorio sobre un cortafuegos con subred de protección. Configurar un escenario de esas características implicaría: • Crear tres segmentos de red distintos y configurar los dispositivos asociados. • Configurar el direccionamiento IP para cada uno de los equipos de cada segmento y configurar dos encaminadores para interconectarlos. • Crear y configurar los sistemas finales (hosts y servidores) que se deseen incluir en el escenario. Todas estas tareas no son tareas específicamente relacionados con los cortafuegos pero constituyen la infraestructura necesaria para poder definir un cortafuegos de esas características. La creación y configuración de un escenario de ese tipo conlleva más trabajo que la propia creación de las reglas de filtrado necesarias. VNX nos permite olvidarnos de esas tareas no específicamente relacionadas con la materia sobre la que queremos trabajar y centrarnos en aquellos aspectos propios de la asignatura. VNX es una herramienta de emulación de redes y sistemas que gracias a la utilización de tecnologías de virtualización permite reproducir en cualquier ordenador que ejecute el sistema operativo Linux1 escenarios complejos de red. VNX permite la definición de esos escenarios de red en formato XML y se encarga de crear los equipos y redes (virtualizados) necesarios para la reproducción del mismo. El usuario puede acceder a todos y cada uno de los equipos que componen el escenario mediante interfaces de texto o gráficas. En esta sesión de laboratorio nos familiarizaremos con el funcionamiento básico de VNX, aprenderemos a interpretar un fichero de definición de un escenario y veremos cómo interaccionar con los escenarios. 1 Es necesario además que el procesador tenga extensiones de virtualización: http://es.wikipedia.org/wiki/Virtualizaci%C3%B3n_x86#Soporte_hardware Introducción a VNX Página 2 VNX está instalado en todos los puestos de laboratorio y recomendamos trabajar sobre ellos. Si quieres instalar VNX en tu equipo, te recomendamos que descargues una máquina virtual (http://gist.aut.uah.es/nemesis/Seguridad-Telematica-UAH-v001.tar.bz2) que hemos preparado con todo lo necesario para que puedas trabajar con la herramienta. No obstante, la asignatura se ha planificado de manera que con el tiempo disponible en el laboratorio haya tiempo suficiente para terminar las actividades diseñadas. CONCEPTOS BÁSICOS DE VIRTUALIZACIÓN Hipervisor y Máquina Virtual La virtualización es una tecnología que nos permite ejecutar diferentes sistemas operativos de manera simultánea sobre un mismo equipo. La plataforma que permite esta ejecución simultánea se denomina hipervisor o monitor de máquina virtual. Ejemplos de hipervisores son VMWare Fusion, Player o Workstation, VirtualBox, entre los que se ejecutan sobre software, y Xen, Hyper V o VMWare ESXi entre los que ejecutan directamente sobre el hardware. Gracias a la virtualización podemos ejecutar dentro de un determinado sistema operativo, otro sistema operativo bien modificado, en cuyo caso hablaríamos de paravirtualización, o bien un sistema operativo sin modificar. El sistema operativo se ejecuta dentro de lo que se denomina máquina virtual (virtual machine o VM). Al igual que un equipo físico tiene unas determinadas especificaciones hardware (memoria, procesador, disco duro, tarjetas…), la máquina virtual también tiene la especificación del hardware que se desea virtualizar. Existe un formato estandarizado (Open Virtualization Format, OVF2) para la especificación de las características de la máquina virtual. Hipervisores específicos emplean formatos propios (vmx, en el caso de VMWare, por ejemplo) y usualmente convertibles a OVF para este mismo fin. Cuando el hipervisor inicia una máquina virtual, emula las características que aparecen indicadas en el fichero de especificaciones de la máquina virtual. .encoding = "UTF-8" displayname = "Seguridad - Telemática UAH" guestos = "ubuntu" virtualhw.version = "9" config.version = "8" numvcpus = "1" cpuid.coresPerSocket = "1" memsize = "512" à MEMORIA RAM pciBridge0.present = "TRUE" pciBridge4.present = "TRUE" pciBridge4.virtualDev = "pcieRootPort" 2 Open Virtualization Format: http://dmtf.org/standards/ovf Introducción a VNX Página 3 pciBridge4.functions = "8" vmci0.present = "TRUE" ide0:0.present = "TRUE" ide0:0.deviceType = "disk" ide0:0.fileName = "Seguridad - Telemática UAH-disk1.vmdk" ide0:0.mode = "persistent" ide1:0.clientDevice = "FALSE" ide1:0.present = "TRUE" ide1:0.deviceType = "cdrom-image" ide1:0.autodetect = "TRUE" ide1:0.startConnected = "TRUE" usb.present = "TRUE" ethernet0.present = "TRUE" ethernet0.virtualDev = "e1000" ethernet0.connectionType = "nat" ethernet0.startConnected = "TRUE" ethernet0.addressType = "generated" usb:1.parent = "-1" vhv.enable = "TRUE" keyboardAndMouseProfile = " 526a5fe7-c630-5276-7cd1-b0a531da" gui.lastPoweredViewMode = "fullscreen" unity.wasCapable = "TRUE" tools.remindInstall = "FALSE" gui.viewModeAtPowerOn = "fullscreen" floppy0.present = "FALSE" checkpoint.vmState = "" bios.bootOrder = "CDROM" Figura 1: Extracto del fichero de especificaciones de la máquina virtual Seguridad – Telemática UAH Junto con este fichero de especificaciones, una máquina virtual tiene que tener asociado un archivo que hará las veces de repositorio de los dispositivos de almacenamiento persistente que se hayan definido para la máquina virtual. Es en este archivo donde se guardarán todos los archivos que instalemos o almacenemos en la máquina virtual, incluyendo el sistema operativo. Existen distintos formatos para este fichero de almacenamiento. Algunos de los más conocidos son vhd (VirtualBox), vmdk (VMWare) y qcow2 (KVM). Los distintos hipervisores suelen proporcionar herramientas para la conversión de formatos. Esto, junto a la facilidad para traducir los ficheros de especificaciones entre distintos hipervisores, facilita el poder importar Introducción a VNX Página 4 máquinas virtuales creadas en un hipervisor en otros hipervisores. En Linux, una herramienta para la conversión entre formatos es qemu-img3. Resumiendo, para que un hipervisor pueda ejecutar una máquina virtual necesitamos: 1. Un fichero donde se definan las especificaciones hardware de la máquina virtual. 2. Un fichero donde estén los dispositivos de almacenamiento (discos duros) de la máquina virtual. Configuración de Red Cuando creamos una nueva máquina virtual dentro un hipervisor, tenemos la posibilidad de incluir uno o más dispositivos de red. Existen distintas topologías posibles de los dispositivos de red de una máquina virtual en función de la relación con los dispositivos de red de la máquina donde se ejecuta el hipervisor (equipo anfitrión o host) y con las interfaces de red de las otras máquinas virtuales que se ejecutan bajo el mismo hipervisor. Seleccionar uno u otro modo de red, dependerá de si necesitamos que la máquina virtual pueda acceder a direcciones externas al equipo anfitrión, de si es necesario que desde el exterior se pueda acceder a servicios que provea la máquina virtual (por ejemplo, un servidor web en la VM) o de si sólo es necesario que la máquina virtual sea accesible desde el mismo anfitrión. Habitualmente, cuando creamos una máquina virtual en nuestro equipo y agregamos una interfaz de red, esta interfaz de red usa el modo de red NAT. Este modo de red permite que desde la interfaz de red en cuestión podamos alcanzar direcciones externas al equipo anfitrión. El modo de red NAT en este contexto quiere decir que el tráfico que tenga como origen esa interfaz de red se encamina a través del equipo anfitrión que hace traducción NAT para poder acceder a direcciones externas. El tráfico generado por esta máquina virtual aparece fuera del host como procedente del mismo host (misma dirección IP origen). Este es el modo que generalmente se suele emplear por defecto al añadir una interfaz de red a una máquina virtual. En este modo, la interfaz de red suele recibir la configuración de red de forma automática (DHCP). El hipervisor mantiene un servidor DHCP para enviar las configuraciones a todas las interfaces de las máquinas virtuales que opten por este modo. También se encarga de enrutar y realizar la traducción NAT para todos los paquetes que genere la máquina virtual. Figura 2: Modo de red NAT (Fuente: VMWare) Existe también la posibilidad de conectar directamente una interfaz de red de la máquina virtual a alguna de las redes a las que esté conectada el equipo anfitrión. Esta forma de configurar la red se denomina “modo puente” (bridged). Esta forma de funcionamiento expone directamente la máquina virtual a la red a la que decidamos conectarle y la hace visible para cualquier otro equipo que haya en la red. En este caso, la interfaz 3 http://en.wikibooks.org/wiki/QEMU/Images Introducción a VNX Página 5 de red de la máquina virtual tendrá que ser configurar (manual o dinámicamente) del mismo modo en que configuraríamos cualquier interfaz de un equipo real que conectáramos a esa red. En este modo de funcionamiento, el hipervisor no enruta ni modifica el tráfico generado por esa interfaz de red de la máquina virtual. Figura 3: Modo de red “bridged” (Fuente: VMWare) Finalmente, existe otro modo de funcionamiento indicado para aquellos casos en los que queremos que interfaces de red de distintas máquinas virtuales aparezcan conectadas a una misma red “virtual”. Este modo puede recibir distintos nombres “host-only”, “internal network”… Los hipervisores permiten crear segmentos de red virtuales y darles un nombre. Si seleccionamos este modo de red para una interfaz, hay que seleccionar a cuál de los segmentos de red existentes queremos conectar la interfaz de red en cuestión. Este modo de funcionamiento es muy útil cuando lo que queremos recrear un escenario formado no por un único equipo sino por varios equipos interconectados en una red de área local. El equipo anfitrión habitualmente también tiene una interfaz conectada a cada uno de los segmentos de red virtuales que creemos de este modo. Figura 4: Modo de red “host-only” (Fuente: VMWare) VNX va a hacer uso fundamentalmente de este modo de funcionamiento. En los próximos apartados, veremos por qué. EL EMULADOR DE REDES VNX Introducción a VNX Página 6 Instalación de VNX Dado que ya tenemos instalado VNX en los puestos del laboratorio y que se os facilita una imagen de una máquina virtual con VNX preinstalado, no vamos a cubrir en detalle el proceso de instalación de VNX en Linux. Si estáis interesados en instalar VNX, os recomendamos seguir las instrucciones que aparecen en el sitio oficial de VNX: http://web.dit.upm.es/vnxwiki/index.php/Vnx-install Es muy importante seguir todos y cada uno de los pasos indicados sin saltarse ninguno. Especialmente crítico resulta el verificar que el equipo donde estamos realizando la instalación tiene las extensiones de virtualización exigidas (orden kvm-ok). Primeros Pasos con VNX En este apartado vamos a ver la estructura básica de VNX. VNX, tal y como hemos dicho, es una herramienta para la emulación de redes. VNX reproduce el escenario de red que nosotros le indiquemos a través de un fichero XML. Llamaremos a este fichero XML fichero de descripción del escenario. En el fichero de descripción del escenario aparecen la descripción de una topología de red. Por cada uno de los equipos de dicha topología de red, se incluye junto con la configuración IP, el tipo de máquina virtual que queramos crear y las características principales (memoria RAM, por ejemplo). Vamos a detenernos por un instante para explicar cómo hace VNX para crear un topología de red. En primer lugar, VNX extrae del fichero de configuración las redes que se hayan definido y las crea dentro del entorno virtual. Estas redes virtuales se corresponden grosso modo con el modo de red “internal network” o “host- only” al que nos referíamos anteriormente. Internamente, para Linux, cada una de estas redes es un puente (bridge). Una vez ha creado estas redes internas (insistimos, las que hayamos indicado nosotros en el fichero de definición del escenario), pasa a crear las máquinas virtuales. Hemos visto anteriormente que para crear una máquina virtual, el hipervisor necesitaba tanto la descripción de la máquina virtual (fichero OVF o equivalente) como del fichero que contenía la instalación del sistema operativo de la máquina virtual propiamente dicha. VNX tiene que proporcionar dicha información al hipervisor para que éste pueda crear las máquinas virtuales. La especificación de la máquina virtual la saca del fichero de descripción del escenario. Para los ficheros de almacenamiento, los que contienen los sistemas operativos, VNX proporciona un conjunto de plantillas, que puede ser extendido, con las distribuciones y sistemas operativos más empleados. Estas plantillas no se distribuyen junto con VNX sino que tienen que ser descargadas con posterioridad, bien desde el sitio web de VNX o de otras ubicaciones, si se trata de plantillas personalizadas. En esta asignatura usaremos plantillas de ambas procedencias. En la descripción del escenario, indicaremos qué plantilla en concreto deseamos usar para cada una de las máquinas virtuales. Este sistema de plantillas para las máquinas virtuales del escenario es una las características más interesantes de VNX de cara a la simplificación del despliegue de redes complejas. El usuario se puede desentender de las pesadas tareas de creación e instalación de las máquinas virtuales y seleccionar simplemente aquellas que le resulten más convenientes. Las plantillas suelen ser ficheros pesados (desde cientos de megas a varios gigas) pero se reutilizan por todas las máquinas virtuales del mismo tipo que componen un escenario. Introducción a VNX Página 7 VNX creará las máquinas virtuales necesarias, con las interfaces conectadas según el fichero de descripción del escenario y proporcionará terminales de acceso a todas ellas. Tras el proceso de arranque, podemos acceder a cualquiera de las máquinas que componen el escenario e interactuar con ella. En el próximo apartado, vamos a ver todo lo anterior para un ejemplo concreto. ESCENARIOS EN VNX Un Ejemplo Sencillo: ‘Tutorial Ubuntu’ En este apartado veremos cómo emular un escenario formado por equipos Linux con distribuciones basadas en Ubuntu. En concreto, trabajaremos sobre el escenario que se muestra en la siguiente figura (tomado de la página web de VNX): Figura 5: Esquema de Red del escenario ‘Tutorial Ubuntu’ Hay varios aspectos del escenario anterior que debemos tener en cuenta: • Cada uno de los equipos que forman parte del escenario tiene un nombre único distintivo. Dos de ellos (r1 y r2) actúan como encaminadores. • Hay cuatro redes distintas: Net0, Net1, Net2 y Net3. • Se utilizan dos plantillas distintas, ubuntu y ubuntu-gui. • El host se incluye dentro del escenario en la red Net3. El fichero de descripción de este escenario es tutorial_ubuntu.xml que podéis encontrar en la ruta /usr/share/vnx/examples/tutorial_ubuntu.xml. Su contenido se muestra a continuación: Introducción a VNX Página 8 2.0 tutorial_ubuntu /usr/share/vnx/filesystems/rootfs_lubuntu- gui 384M 10.0.0.2/24 default conf/txtfile Introducción a VNX Página 9 /usr/share/vnx/filesystems/rootfs_ubuntu 128M 10.0.0.3/24 default /usr/share/vnx/filesystems/rootfs_ubuntu 128M 10.0.0.1/24 10.0.1.1/24 10.0.3.1/24 10.0.2.0/24 /usr/share/vnx/filesystems/rootfs_ubuntu 128M 10.0.1.2/24 10.0.2.1/24 default Introducción a VNX Página 10 /usr/share/vnx/filesystems/rootfs_ubuntu 128M 10.0.2.2/24 default /usr/share/vnx/filesystems/rootfs_ubuntu 128M 10.0.2.3/24 10.0.3.2/24 10.0.0.0/16 Vamos a extraer la información más importante del fichero XML anterior. En primer lugar, tenemos un conjunto de definiciones generales. La más importante de todas para nosotros será el nombre del escenario (que aparece resaltado en negrita). No podemos tener simultáneamente iniciados dos escenarios con el mismo nombre. Tras estas definiciones generales, nos encontramos con la definición de las subredes virtuales Net0, Net1, Net2 y Net3. Estas serán las redes a las que podremos conectar las interfaces de red de las distintas máquinas virtuales que conforman el escenario. Las máquina virtuales se incluyen en el escenario usando la etiqueta vm. En primer lugar, hay que darle un nombre (que deberá ser único) y un conjunto de atributos que definen el tipo de virtualización usada. A continuación, se le indica qué plantilla queremos usar. La etiqueta vm es la que nos permite definir cuál de las plantillas de las que disponemos queremos usar. Una vez que hemos seleccionado la plantilla, especificamos los parámetros de la misma: memoria, interfaz o interfaces de red (con sus correspondientes direcciones ) y encaminamiento. Al detectar un bloque VM VNX dará la orden al hipervisor subyacente (en este caso KVM) para que inicie una máquina virtual con esas características y con la plantilla que digamos (en realidad, se genera una copia de ese archivo) como disco duro. Introducción a VNX Página 11 Tras los bloques de todas las máquinas virtuales, encontramos un bloque host que nos permitirá que el host tenga una interfaz de red dentro de la red (o redes) que le indiquemos dentro del escenario. Antes de poder iniciar el escenario, debemos cerciorarnos de que existen las plantillas que queremos usar. En nuestro caso, tendríamos ver que existen los archivos /usr/share/vnx/filesystems/rootfs_ubuntu y /usr/share/vnx/filesystems/rootfs_lubuntu-gui. Habitualmente, estos archivos que se incluyen dentro de la etiqueta filesystem suelen ser enlaces simbólicos a las plantillas reales aunque también podrían incluirse también las rutas a las plantillas reales. Una vez hemos verificado que tenemos todas las imágenes necesarias, podemos proceder a arrancar el escenario. Para emplear VNX necesitamos privilegios de administración por lo que tendremos que ejecutar la orden usando sudo. Sudo nos permita dar privilegios de administración a un usuario para ejecutar una orden concreta. Estos permisos se definen en el fichero de configuración /etc/sudoers. Cuando ejecutamos una orden con sudo, se nos pedirá nuestra contraseña. Si la introducimos correctamente y tenemos los permisos otorgados en el archivo sudoers, la orden se ejecutará. Abrimos un terminal, y ejecutamos la siguiente orden: sudo vnx –f tutorial_ubuntu.xml --create Si falta alguna de las imágenes necesarias, encontraréis un error parecido a éste: Figura 6: Error al Iniciar VNX: el fichero de imagen no existe Si, por el contrario, va todo bien, VNX comenzará a arrancar terminales, uno por cada uno de las máquinas virtuales que conforman el escenario. La ventana de cada terminal irá identificada con el nombre de la máquina virtual con la que se corresponde. La salida por consola de VNX tendrá un aspecto parecido al siguiente: Introducción a VNX Página 12 Figura 7: Inicio normal de VNX Las consolas que se abren nos proporcionan una interfaz para interactuar con los equipos. VNX permite asociar dos consolas a cada equipo: una gráfica (con0) y otra de texto (con1). Podemos usar cualquiera de Introducción a VNX Página 13 ellas indistintamente. En la figura anterior podéis observar que VNX, al inicio, nos proporciona las órdenes para abrir cualquiera de las consolas. Al iniciarse, VNX puede abrir las consolas que le indiquemos en el fichero del escenario El proceso de arranque y apertura de todos los terminales puede ser agobiante para el usuario. Podéis cerrar las ventanas que se abren sin temor a apagar la máquina dado que la máquina virtual seguirá ejecutándose en segundo plano. Otra forma de acceder a las consolas es usando la herramienta ‘Gestor de Máquinas Virtuales’, que nos da una interfaz directa con el hipervisor. Podemos arrancar ese programa con la siguiente orden: sudo virt-manager Figura 8: Gestor de Máquinas Virtuales Pinchando sobre cualquier de las máquinas del escenario, podéis abrir una consola con dicha máquina virtual. Es muy útil para recuperar el acceso cuando por algún motivo hemos cerrado la consola de un equipo y no podemos recuperarla. El proceso de arranque puede ser costoso. Si observáis la salida que se muestra en las consolas, veréis cómo se produce un reinicio. Este reinicio es necesario para cargar la configuración específica para cada máquina virtual que hemos especificado en el arranque de VNX. La siguiente figura muestra la salida del terminal en el instante de lanzar el reinicio: Introducción a VNX Página 14 Figura 9: Reinicio de una VM en VNX para autoconfiguración Una vez ha terminado el proceso de arranque. Podemos acceder a cualquiera de las consolas y verificar que la configuración se ha aplicado correctamente. Vamos a realizar esta comprobación sobre la consola correspondiente a h2. En primer lugar, tenemos que identificar la consola correspondiente a h2. Podemos hacerlo buscando la ventana que tiene en la barra de título la cadena h2 o directamente abriéndola desde la aplicación ‘Gestor de Máquinas Virtuales’. Una vez en ella, tenemos que iniciar sesión. En las plantillas de VNX, por lo general, existe un usuario de nombre ‘vnx’ con contraseña ‘xxxx’. Es una convención que se suele emplear en todas las imágenes de sistemas que se distribuyen con VNX y que nosotros también vamos a seguir en las que os distribuiremos para este laboratorio. Una vez hemos iniciado sesión, comprobamos que realmente se han podido asignar las direcciones de red solicitadas, tal y como aparece en la siguiente figura: Introducción a VNX Página 15 Figura 10: Visualización de las Interfaces de Red en la VM h2 Podemos repetir este mismo proceso para el resto de los equipos para verificar que las asignaciones se han realizado correctamente. Por motivos de simplicidad, sólo vamos a revisar dos equipos más, r1 y nuestro host. En r1, deberíamos tener tres interfaces de red (más la interfaz local loopback de nombre lo), dado que eso es lo que se especificó en el fichero de definición de escenario. Comprobémoslo: Introducción a VNX Página 16 Figura 11: Visualización de las Interfaces de Red en la VM r1 Finalmente, verificaremos que también se ha creado una interfaz en el anfitrión (host, nuestro equipo) para permitir la conectividad con el escenario. Mediante la etiqueta host hemos incluido el host en el escenario en la red Net3 con la dirección IP 10.0.3.2. Figura 12: Interfaz de red del host dentro del escenario Esto permite que el host pueda ser accesible desde el escenario y viceversa. No es obligatorio que el host esté presente en el escenario pero puede ser interesante en ciertas situaciones. Se deja como ejercicio para el estudiante que compruebe la conectividad del escenario, las tablas de encaminamiento de los encaminadores y la corrección de la asignación de direcciones IP. VNX permite suspender máquinas individuales o el escenario y también directamente detenerlo por completo. Lo más habitual es detenerlo. La opción de vnx para ello es --destroy. vnx –f tutorial_ubuntu.xml --destroy Figura 13: Finalización del Escenario Introducción a VNX Página 17 En condiciones normales, la orden anterior detiene todos los equipos, los destruye y libera los recursos asignados. No obstante, en ocasiones puede haber problemas. En esos casos se recomienda emplear la opción --clean-host. vnx – f tutorial_ubuntu.xml --clean-host Esta última opción además de detener el escenario, elimina todos los posibles ficheros temporales que pueda haber guardado VNX. En ocasiones, ni aún usando alguna de las dos opciones anteriores conseguimos un cierre limpio del escenario. Esto lleva asociado el problema de que si intentamos arrancarlo de nuevo, no nos deja debido a que el escenario aún existe. En esos casos, es útil la opción –D de vnx: vnx –D Figura 14: Eliminación de ficheros residuales de VNX Si ni aún así solventamos los problemas, se recomienda eliminar por completo el subdirectorio .vnx del directorio del usuario. Evaluación y Plazos de Entrega Enseñe al profesor y comente con él sus avances y dudas sobre la plataforma. Referencias Máquina virtual (VMWare) para realizar las prácticas de laboratorio: http://gist.aut.uah.es/nemesis/Seguridad- Telematica-UAH-v001.tar.bz2 Imagen de la distribución LUbuntu para VNX: http://gist.aut.uah.es/nemesis/vnx_rootfs_kvm_lubuntu-gui- 12.04-v003.qcow2.bz2