Virtualización: Parte 5 — QEMU

QEMU — un emulador y virtualizador libre, distribuido bajo la licencia GPLv2. Hace dos cosas diferentes. Primero, emular un ordenador completo, incluyendo el procesador de otra arquitectura: por ejemplo, ejecutar un sistema para ARM en un servidor x86 convencional. Segundo, trabajar junto con un acelerador de virtualización — en Linux esto es KVM — y entonces las máquinas virtuales se ejecutan casi a la misma velocidad que el sistema anfitrión.

La versión estable vigente en septiembre de 2026 — QEMU 11.1.1 (26 de agosto de 2026).

Cómo QEMU y KVM se reparten el trabajo

KVM — un módulo del kernel de Linux — da a la máquina virtual acceso directo a las capacidades del procesador (Intel VT-x, AMD-V). Por sí solo no crea discos, ni tarjetas de red, ni pantalla. Esa parte la realiza QEMU: emula para el sistema invitado controladores de disco, adaptadores de red, USB, tarjeta gráfica y cargador de arranque. Por eso en un servidor con KVM los procesos de las máquinas virtuales son procesos QEMU.

Sin acelerador QEMU traduce cada instrucción del procesador invitado a instrucciones del procesador anfitrión. Esto funciona en cualquier arquitectura, pero es mucho más lento — para cargas de trabajo este modo no es adecuado; para pruebas y desarrollo normalmente basta.

Dónde se usa QEMU, incluso si no lo conoces

• Proxmox VE ejecuta máquinas virtuales mediante QEMU con KVM; el comando qm y la interfaz web de Proxmox terminan formando los parámetros de arranque de QEMU.
• libvirt, virt-manager y Cockpit en servidores Linux comunes también gestionan procesos QEMU.
• UTM en macOS usa QEMU, incluso para ejecutar sistemas x86 en ordenadores Apple con procesadores ARM.
• Docker construye imágenes para otras arquitecturas (docker buildx --platform linux/arm64) con la ayuda del modo de usuario de QEMU: programas individuales de otra arquitectura se ejecutan de forma transparente, sin iniciar una máquina virtual completa.

Dos modos de funcionamiento

• Emulación de sistema (qemu-system-x86_64, qemu-system-aarch64 y otros) — una máquina virtual completa con su propio kernel, discos y dispositivos.
• Modo de usuario (qemu-aarch64, qemu-arm y otros) — ejecutar un solo programa compilado para otra arquitectura en el sistema Linux actual. Es precisamente lo que se usa para cross-building y pruebas.

Discos: la utilidad qemu-img

QEMU crea y convierte imágenes de disco con la utilidad qemu-img. El formato principal es qcow2: ocupa en disco tanto espacio como realmente está escrito y soporta snapshots. El formato raw es más simple y algo más rápido, pero ocupa inmediatamente todo el tamaño.

# crear un disco de 40 GB en formato qcow2
qemu-img create -f qcow2 disk.qcow2 40G

# ver información de la imagen: formato, tamaño declarado y tamaño real
qemu-img info disk.qcow2

# convertir un disco de VMware (vmdk) a qcow2 — paso típico al migrar desde VMware
qemu-img convert -p -f vmdk -O qcow2 server.vmdk server.qcow2

La conversión convert es la herramienta principal al migrar máquinas virtuales desde VMware o Hyper-V (formato vhdx) a Proxmox y otras plataformas sobre KVM.

Arrancar una máquina virtual manualmente

En la práctica las máquinas se crean mediante Proxmox o libvirt, pero es útil entender qué ocurre internamente. Arranque mínimo del instalador de Linux con aceleración KVM:

qemu-system-x86_64 \
  -accel kvm -cpu host \
  -m 4G -smp 2 \
  -drive file=disk.qcow2,if=virtio \
  -cdrom debian.iso -boot d \
  -nic user,model=virtio-net-pci

• -accel kvm -cpu host — activar KVM y pasar al invitado las capacidades del procesador real;
• -m y -smp — cantidad de memoria y número de procesadores virtuales;
• if=virtio y virtio-net-pci — dispositivos paravirtualizados: el sistema invitado sabe que está en una VM y transmite datos más rápido que con la emulación de hardware real;
• -nic user — la red más simple mediante NAT sin configurar puente; en servidores en su lugar se configura un puente de red.

Si el procesador o el servidor no soportan virtualización por hardware (por ejemplo, en algunas máquinas virtuales en la nube la virtualización anidada está desactivada), QEMU con -accel kvm no se iniciará. Puedes comprobarlo así: ls /dev/kvm — el archivo debe existir.

Emulación de otra arquitectura

Arrancar un sistema para ARM en un servidor x86 se hace así:

qemu-system-aarch64 -M virt -cpu cortex-a72 -m 2G \
  -bios QEMU_EFI.fd \
  -drive file=arm-disk.qcow2,if=virtio \
  -nographic

Aquí no hay aceleración KVM: el procesador ARM se emula completamente y la máquina funciona notablemente más despacio. Para comprobar firmwares, imágenes para placas únicas (single-board computers) y compilar paquetes para ARM normalmente esto es suficiente.

Cuándo elegir QEMU directamente

• Desarrollo y pruebas para otras arquitecturas — ARM, RISC-V, MIPS, PowerPC.
• Depuración de kernels y cargadores de arranque: QEMU puede conectarse al depurador GDB (-s -S).
• Pruebas automatizadas de imágenes en CI, donde no se necesita interfaz gráfica.
• Ejecuciones puntuales de sistemas antiguos desde una imagen de disco.

Para operación continua de servidores no se suele usar QEMU directamente: es más cómodo y fiable gestionar las máquinas mediante Proxmox VE o libvirt, que se ocupan del arranque automático, redes, snapshots y copias de seguridad.

Errores típicos

• Arrancar sin -accel kvm en un servidor donde KVM está disponible: la máquina funciona en modo emulación y se ralentiza sin razón aparente.
• Dispositivos emulados en lugar de virtio: disco IDE y tarjeta de red e1000 son más lentos. En Windows se instalan los controladores virtio por separado desde la imagen virtio-win.
• Copiar el archivo qcow2 de una máquina en ejecución: la copia puede quedar inconsistente. Se debe parar la máquina o usar snapshots y las herramientas de backup de la plataforma.
• Confusión con el formato: si en -drive no se indica format=, QEMU detecta el formato automáticamente y muestra una advertencia; para imágenes raw es mejor especificar explícitamente el formato.