- Permite ejecutar múltiples instancias independientes del kernel de Linux en una misma máquina física sin necesidad de un hipervisor.
- Se posiciona como una alternativa híbrida que ofrece mayor aislamiento que los contenedores y menor sobrecarga que las máquinas virtuales KVM.
- Facilita la asignación dinámica de CPUs, memoria y dispositivos PCI mediante el uso de árboles de dispositivos y la herramienta Kerf.
Si te mola el mundo del sistema operativo, seguro que te suena que el kernel es el corazón que lo controla todo. Pues bien, ha surgido una propuesta que rompe los esquemas tradicionales: la arquitectura Multikernel Linux. En lugar de tener un único jefe mandando sobre todos los núcleos del procesador, esta tecnología permite que varios kernels independientes convivan en la misma máquina física, aprovechando el hardware de una forma mucho más quirúrgica y eficiente.
Esta movida no es un simple parche, sino una manera totalmente distinta de entender la computación de alto rendimiento. Imagina que puedes repartir tu hardware en trozos y que en cada trozo corra un Linux propio, sin que haya un hipervisor en medio haciendo de intermediario y comiéndose recursos. Es, básicamente, sacar el máximo jugo al silicio eliminando capas innecesarias que suelen ralentizar los procesos en entornos virtualizados.
¿De qué va exactamente el concepto Multikernel?
La idea es sencillamente brillante pero compleja: un kernel principal, que actúa como anfitrión, gestiona un grupo de CPUs, memoria y dispositivos PCI. Este kernel \»padre\» recorta esos recursos y lanza kernels secundarios (spawn kernels) en cada instancia mediante una función llamada kexec_file_load(). Lo más potente de esto es que cada instancia corre de forma nativa; no hay emulación ni trampas, solo compartes lo que tú decidas compartir.
Para gestionar este despliegue, se utilizan árboles de dispositivos (device tree) escritos en /sys/fs/multikernel/. Gracias a los overlays, es posible mover CPUs o memoria entre el pool general y las instancias activas sin tener que reiniciar el equipo. Si una instancia ya no hace falta, se apaga, se recuperan sus recursos y se puede volver a lanzar con una versión de kernel distinta si el flujo de trabajo lo requiere.
Multikernel frente a VMs y Contenedores
Para entender dónde encaja esto, hay que compararlo con lo que ya conocemos. Si hablamos de contenedores, la diferencia es abismal porque los contenedores comparten el mismo kernel; si el kernel peta o hay un exploit, todo el sistema cae. En cambio, aquí cada instancia tiene su propio kernel, por lo que un pánico en una no afecta a las demás.
Si lo comparamos con las máquinas virtuales (VMs), el ahorro es notable. Al no haber un hipervisor, desaparece el camino de salida de la VM (VM exit) y no hacen falta tablas de páginas de segundo nivel ni modelos de dispositivos emulados. Es, en esencia, bare metal puro para cada instancia.
Rendimiento real y el coste energético
En las pruebas realizadas con la batería lmbench, comparando una configuración de 2 núcleos y 1 GB de RAM frente a KVM, los resultados han sido reveladores. Mientras que el ancho de banda de memoria es similar, la latencia de ejecución es mucho menor en Multikernel (1,37 microsegundos frente a los 3,42 de KVM). También se han visto mejoras claras en las comunicaciones de sockets Unix y latencia de tuberías.
Pero ojo, que no todo es color de rosa. Como Multikernel trabaja directamente con los núcleos físicos asignados para evitar el gasto de virtualización, el consumo energético se dispara. En los tests se registró un incremento de unos 19 vatios adicionales. Es el precio a pagar por tener una gestión de recursos más agresiva y eficiente en términos de tiempo de respuesta.
Experimentos en la nube: ¿Funciona en Google Compute Engine?
Resulta curioso que, aunque esté pensado para hardware físico, se ha podido probar dentro de una VM de Google Compute Engine (GCE). En este escenario, no se trata de virtualización anidada, sino de que el kernel primario usa kexec y hotplug de CPU para lanzar kernels hijos dentro de los recursos ya asignados a la VM de Google.
En una instancia n2-standard-16, se logró levantar dos kernels hijos asignando APIC IDs específicos y memoria segmentada. Incluso se probó a correr cargas de trabajo derivadas de imágenes de Docker, donde cada \»contenedor\» tenía su propio binario de kernel, demostrando que la segmentación de recursos es viable incluso sobre hardware virtualizado.
Los baches en el camino: Lo que aún falta pulir
A pesar de lo prometedor que suena, el proyecto está en una fase temprana y tiene puntos débiles. El más crítico es el networking; el transporte VSOCK de Multikernel ha dado problemas de compilación y asignar una NIC virtual a un hijo podría dejar al kernel principal incomunicado.
El almacenamiento también es un quebradero de cabeza. Aunque el uso de DAXFS permite compartir sistemas de archivos de lectura, la escritura simultánea no es coherente y puede generar datos obsoletos. Además, quedan dudas sobre cómo reaccionaría este sistema ante una migración en vivo de la VM o el uso de memory ballooning.
La arquitectura de arranque en ARM64
Para entender la complejidad de lanzar kernels, es útil mirar cómo arranca un sistema ARM64. Todo es una cadena de traspasos: desde la Boot ROM (BL0) que hace chequeos básicos, pasando por el mundo seguro de EL3 con BL1 y BL31 (TF-A), hasta llegar al cargador de arranque no seguro (BL33 como U-Boot). Solo después de todo este baile de seguridad y configuración de hardware, el kernel de Linux se descomprime y toma el control para lanzar el espacio de usuario. Entender este flujo es vital para quienes desarrollan drivers de bajo nivel o BSPs, ya que Multikernel juega precisamente en esas capas profundas del sistema.
Este avance representa un salto cualitativo en la forma de exprimir los procesadores multinúcleo modernos, permitiendo una flexibilidad total entre el aislamiento total de una VM y la ligereza de un contenedor. Aunque el consumo eléctrico sea mayor y el networking aún sea un reto, la capacidad de gestionar instancias de kernel independientes sobre el mismo hardware abre la puerta a entornos de desarrollo y producción mucho más dinámicos y robustos.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.