¿Es posible arrancar un kernel Linux dentro de Linux sin usar KVM, ni QEMU, ni VirtualBox… y además sin ser root? Sí: se llama User Mode Linux (UML) y lleva décadas en el árbol del kernel, aunque casi nadie se acuerde de él.
Este enfoque permite ejecutar un kernel Linux como proceso de usuario, con su propio espacio de procesos, su propio rootfs y sus propios dispositivos… pero apoyándose en las facilidades del kernel anfitrión. No es una alternativa moderna a KVM para producción, pero sí una herramienta muy curiosa y útil para pruebas, formación y depuración de kernel.
¿Qué es exactamente User Mode Linux?
La documentación oficial del kernel lo resume así: Linux ha sido portado… a sí mismo. Es decir, existe una configuración del kernel que en lugar de ejecutarse sobre hardware real, se ejecuta como binario de espacio de usuario sobre un kernel Linux ya en marcha.
En UML:
- El “hardware” es virtual, pero no al estilo QEMU/KVM.
- El kernel invitado usa ficheros, sockets y descriptores del sistema anfitrión como si fueran dispositivos.
- La consola puede mapearse a la entrada/salida estándar.
- Un “disco” puede ser simplemente un fichero del host accesible a través de un driver especial (como
ubd).
En la práctica, UML se comporta como una especie de paravirtualización ligera: el kernel invitado sabe que está encima de otro kernel y aprovecha sus servicios de usuario para simular hardware.
Cómo encaja UML en la pila de virtualización
Si pensamos en las opciones clásicas:
- Contenedores: comparten kernel con el host; buena aislación a nivel de procesos y namespaces, pero mismo kernel para todos.
- KVM/QEMU: hipervisor completo, con fuerte aislamiento y soporte amplio de sistemas operativos.
- UML: punto intermedio raro, donde:
- hay otro kernel ejecutándose,
- pero no existe un hipervisor clásico,
- y el invitado depende fuertemente del kernel anfitrión.
Por tanto, UML no sustituye a KVM ni a contenedores en entornos de producción, pero es perfecto para:
- experimentar con configuraciones de kernel,
- probar cosas “peligrosas” sin romper el host,
- enseñar cómo arranca y se comporta un sistema Linux a bajo nivel.
Requisitos y limitaciones importantes
Antes de jugar con UML conviene tener claras sus restricciones:
- Solo está soportado en x86 (x86_64). La idea es: kernel x86 “real” en el host + kernel x86 UML encima.
- Se ejecuta como proceso de usuario, por lo que:
- se puede lanzar sin root (salvo para crear/formatar ficheros de disco, etc.),
- hereda las limitaciones del usuario que lo lanza.
- El aislamiento no es equivalente al de una VM KVM sobre hardware: UML depende del comportamiento del kernel anfitrión y de sus primitivas.
Compilando un kernel UML
El núcleo de UML es simplemente un kernel Linux compilado con ARCH=um.
- En el árbol de fuentes del kernel:
ARCH=um make menuconfig
Ahí verás opciones específicas de UML: son básicamente “drivers” que usan recursos del espacio de usuario como si fueran hardware.
- Un driver clave es el de User-Mode Block Device (UBD), que permite usar ficheros del host como discos dentro del UML:
- Opción
BLK_DEV_UBD→ márcala comoY.
- Compila el kernel:
ARCH=um make -j$(nproc)
Lenguaje del código: JavaScript (javascript)Esto generará un binario llamado simplemente linux en el directorio raíz del árbol del kernel:
$ file linux
linux: ELF 64-bit LSB executable, x86-64, dynamically linked, ...
Es un ejecutable de usuario, enlazado con la libc del sistema, que es tu kernel UML.
Preparando el espacio de usuario (rootfs)
El kernel por sí solo no hace nada útil; necesitas un rootfs con herramientas básicas. Una opción cómoda es:
- Usar Buildroot para generar una imagen minimalista x86_64.
- O reutilizar un rootfs que ya tengas preparado (por ejemplo, un tarball mínimo con busybox).
Supongamos que tienes un rootfs.ext2 generado por Buildroot en /tmp/uml/rootfs.ext2.
Arrancando el kernel en modo usuario con discos simulados
Primero, creamos un fichero que actuará como segundo disco dentro de UML:
dd if=/dev/urandom of=./disk.ext4 bs=1M count=100
sudo mkfs.ext4 ./disk.ext4
Lenguaje del código: JavaScript (javascript)Ahora puedes lanzar el kernel UML indicando:
ubd0=→ el fichero que se usará como disco raíz (rootfs.ext2).ubd1=→ el fichero que se usará como segundo disco (disk.ext4).root=→ el dispositivo raíz dentro del UML, por ejemplo/dev/ubda.
Ejemplo de arranque:
./linux ubd0=/tmp/uml/rootfs.ext2 ubd1=/tmp/uml/disk.ext4 root=/dev/ubda
Lenguaje del código: JavaScript (javascript)Verás un boot log de Linux completo, como en cualquier máquina, y al final un login de tu sistema Buildroot (o el que hayas integrado):
Welcome to Buildroot
buildroot login:
Dentro de ese entorno ya tienes un Linux completo corriendo sobre otro Linux, sin QEMU, sin KVM y sin root.
Demostración práctica: escribir desde UML y leer desde el host
Dentro de la sesión UML:
# mkdir /mnt/disk
# mount /dev/ubdb /mnt/disk
# echo "This is a UML test!" > /mnt/disk/foo.txt
# cat /mnt/disk/foo.txt
This is a UML test!
Lenguaje del código: PHP (php)Después apagas el sistema dentro de UML:
# poweroff
Lenguaje del código: PHP (php)En el host puedes montar el mismo fichero disk.ext4:
sudo mount ./disk.ext4 ./img
cat ./img/foo.txt
This is a UML test!
Has arrancado un kernel dentro de otro, has montado un “disco” virtual, has escrito datos desde el invitado y los has leído desde el anfitrión. Todo con un binario linux que no deja de ser un proceso de usuario.
¿Tiene sentido UML para producción?
Pregunta legítima para cualquier sysadmin.
En general, no es la herramienta adecuada para:
- entornos multi-tenant,
- cargas críticas,
- escenarios que requieran aislamiento fuerte (tipo cloud público).
Para eso siguen siendo mucho más adecuados:
- KVM y el ecosistema de hipervisores “clásicos”,
- o contenedores si compartir kernel no es un problema.
Donde UML sí brilla:
- Debugging de kernel: puedes probar configuraciones, fallos y módulos sin arriesgarte a tumbar el host.
- Formación y docencia: es perfecto para enseñar el arranque del kernel, la interacción con el rootfs, los drivers, etc.
- Experimentación sin root: usuarios sin privilegios pueden levantar un entorno con su propio kernel y espacio de procesos, ideal para entornos multiusuario o laboratorios.
En cierto modo, UML ocupa un nicho muy particular entre contenedores y VMs: ofrece un kernel separado, pero sigue apoyándose en el kernel del sistema para muchas cosas. Es más una herramienta de laboratorio que una plataforma de virtualización generalista.
Conclusión
User Mode Linux es una de esas piezas históricas del ecosistema Linux que muchos han leído en la documentación, pero pocos han probado. No va a sustituir a KVM ni a los contenedores en tu día a día, pero si te interesa:
- entender mejor cómo se comporta el kernel,
- montar laboratorios de pruebas,
- o jugar con arquitecturas y rootfs minimalistas,
merece muchísimo la pena dedicarle una tarde.
Y lo mejor: no necesitas hipervisor, ni root, ni una granja de servidores. Solo el código fuente del kernel, algo de paciencia con menuconfig y ganas de trastear.
Feliz hacking 😄🐧
Fuente: Popovicu
