QEMU

Notas breves para tener QEMU funcionando sobre una distribución Debian Lenny.

Conceptos básicos

• Host: máquina donde está funcionado el programa QEMU.
• Guest: sistema operativo que está funcionando sobre la máquina virtual creada por QEMU.

Discos

Creando un disco

$ qemu-img create lenny-i386 3000000

Redimensionar un disco con formato ...

... NTFS y con el indicador de arranque activo es una operación delicada y algo peligrosa si no se toman las precauciones adecuadas.

He encontrado bastante información en un hilo del foro especializado de QEMU, pero donde estaba la idea simple y genial ha sido en las páginas de Bryan Murdock, en las que hace uso de la virtualización y las herramientas especializadas de clonación de discos.

Bryan describe estos pasos en su método:

1. Creamos un nuevo disco qemu con el tamaño que pretendamos que tenga el nuevo sistema:

   # qemu-img create -f qcow2 windoze.qcow2 30G
   

2. Arrancamos Windows XP con el nuevo disco como secundario y lo inicializamos (formateamos en realidad) desde el sistema en marcha. Se supone que debería encontrar el nuevo disco él solito pero en mi caso he tenido que emplear el administrador de medios para ello. En cualquier caso ya tenemos un disco de 30G con formato NTFS listo, o casi listo, para ser utilizado.

3. Dado que vamos a emplear clonezilla procedemos a descargar una imagen ISO si no la tenemos ya disponible.

4. Arrancamos entonces una máquina virtual con el disco escaso de espacio como primer disco (/dev/hda), el nuevo disco aún vacío como secundario (/dev/hdb) y la imagen ISO del programa clonezilla como lectora de CDs.

   # kvm -k es -redir tcp:3389::3389 -localtime -daemonize -usb -usbdevice tablet -m 512 -vnc :2 -hdb winxp.qcow2 -hda /var/qemu/winxp.ovl -cdrom ~/clonezilla-live-1.2.3-5.iso -boot d
   

   Dado que al final le indicamos que busque en CD el programa de inicio, terminamos empleando el menú textual de clonezilla para clonar un disco sobre otro. Tenemos buen cuidado de indicar que redimensione el sistema de archivos para adaptarlo al tamaño del nuevo disco (parámetro -r) y que cree una tabla de particiones acorde a ello (-k1).

5. Si todo ha ido bien tendremos que apagar ordenadamente la máquina virtual y rearrancar con el nuevo disco:

   #  kvm -k es -redir tcp:3389::3389 -localtime -daemonize -usb -usbdevice tablet -m 512 -vnc :2 winxp.qcow2
   

   WinXP efectuará un chequeo del disco bastante escandaloso al iniciarse pero luego arranca sin problemas y con el nuevo tamaño ya disponible.

6. Limpiamos las antiguas imágenes y todos aquellos archivos temporales que hemos considerado necesarios (más que nada porque se suele hacer una copia de seguridad del disco original y terminará consumiendo un espacio en disco absurdo) y renombramos el disco nuevo con el nombre del antiguo si es necesario para ponerlo en marcha en producción.

La siguiente imagen corresponde a un pantallazo del proceso de clonación de los discos, muy importante de cara a saber si está funcionando y empezar a respirar:

Arrancando una instalación

En este modo ...

$ qemu -cdrom /dev/cdrom -boot d lenny-i386

Acceso a la red

La configuración predeterminada de red en QEMU es el modo user, en el cuál no son necesarias atribuciones de superusuario, y para el que se crea una red virtual cuya configuración es la siguiente:

Qemu VLAN   <-----> Cortafuegos/Servidor DHCP <---> Internet
                |       (10.0.2.2)
                |
                +-> Servidor de nombres (10.0.2.3)
                |
                +-> Servidor SMB (10.0.2.4)

[!] QEMU proporciona un servidor DHCP interno, de tal manera que una máquina que lo solicite puede obtener una dirección IP y salir al exterior; el problema aparece cuando se quiere acceder desde ese exterior a la máquina virtual. No hay una comunicación bidireccional puesto que QEMU comparte la IP con la máquina en la que se ejecuta.

Así pues, en este escenario, tenemos las siguientes características:

• El servidor de red virtual de QEMU se comporta como si estuviese detrás de un cortafuegos y bloquea todas las conexiones entrantes.
• El servidor DHCP comienza a dar direcciones IP desde la 10.0.2.15, por lo que se puede emplear perfectamente desde la máquina virtual.
• La máquina virtual tiene salida al exterior, aunque se advierte que los ping no son fiables porque en muchos casos es necesario ser root para ello.
• Si se utiliza el servidor TFTP interno tendrá la misma dirección que el cortafuegos (10.0.2.2).
• La opción -redir también permite en este caso que las conexiones entrantes a la máquina local sean redirigidas a la máquina virtual (guest) en el puerto indicado.

Accediendo a la red como uno más

Para conseguir que la máquina virtual funcione como un nodo de red más, independiente, es necesario seguir una serie de pasos que voy a detallar aquí, y aunque existen varias formas de encarar el problema, me voy a limitar al escenario más habitual en mi entorno: un único par de sistema host y sistema guest.

Dado que es necesario que se comparta un interfaz físico (eth0 en la máquina host), pero que existan dos de ellos, la solución pasa por crear un puente ethernet en el que estén incluídos ambos.

Para ello en el host debemos hacer lo siguiente:

1. Añadimos un interfaz puente en /etc/network/interfaces y lo empleamos directamente en lugar de eth0. Así, si lo tenemos configurado mediante [dhcp][] quedaría de esta forma:

   auto br0
   iface br0 inet dhcp
       bridge_ports eth0 tap0
       bridge_fd 9
       bridge_hello 2
       bridge_maxage 12
       bridge_stp off
   

   las opciones bridge_ son gestionadas directamente por los programas del paquete ifupdown, por lo que siguiendo las instrucciones de la página de manual de interfaces es bastante sencillo de poner en marcha. Eso sí, las que aquí aparecen han sido tomadas de los enlaces que proporciono; las pruebas que he realizado hasta ahora demuestran que los valores por defecto son más que suficientes.

2. Una vez levantado el interfaz, sólo tenemos que hacer algo más si queremos ejecutar QEMU con otro usuario que no sea root:

   # tunctl -u victor -t tap0
   

   El programa tunctl (que puede usarse junto a sudo) viene incluído en el paquete uml-utilities.

3. Lanzar QEMU con las opciones de red necesarias:

   $ qemu -net nic,vlan=0 -net tap,vlan=0,ifname=tap0
   

Otras opciones

QEMU puede emplear otro buen número de opciones que a mí siempre se me olvidan:

• Teclado español: -k es
• Tamaño de memoria RAM: -m 256
• Acceso consola virtual: -vnc :1
• Hora local en el reloj hardware: -localtime
• Crear un archivo PID: -pidfile ruta
• Modo demonio: -daemonize

Aceleración y otras arquitecturas

Una de las mejores características que tiene QEMU es que puede emular otras arquitecturas hardware, lo que permite instalar y ejecutar binarios escritos para otros procesadores, por ejemplo.

Si queremos emular una arquitectura amd64 debemos invocarlo de esta forma:

$ qemu-system-x86_64 -no-kqemu

mientras que si queremos activar la aceleración hardware emplearemos:

$ qemu-system-x86_64 -kernel-kqemu

siempre que tengamos el soporte en el sistema host, por supuesto.

Enlaces y referencias

• Guía de Dan Walrond para configurar qemu con dispositivos tap. Muy sencilla y limpia.
• Guía de Mark McLoughlin con gráficos ASCII bastante esclarecedores.
• Wikilibro sobre el tema.
• Entrada en el wiki de Debian