Notes ·
One Machine, Several Linux Kernels, No Hypervisor
Joshua MorrisMultikernel Linux has reached its first public release, and this is one of the more interesting Linux experiments I have seen lately. The basic idea sounds like virtualization until you get to the important part: there is no hypervisor.
One physical machine can run several independent Linux kernels at the same time, with each kernel receiving its own CPUs, physical memory, and hardware devices. The kernels run directly on the machine—no virtual CPU, no emulated hardware, no VM exits, no hypervisor sitting underneath everything.
Containers are lightweight because they all share the host kernel—and that shared foundation is also one of their most important boundaries. Virtual machines give each guest its own kernel, but a hypervisor sits between those kernels and the physical machine. Multikernel Linux takes another path: several independent kernels, each owning a slice of the actual hardware. That is wonderfully strange.
The mechanism builds on things Linux already knows how to do. The machine boots a multikernel-enabled Linux kernel normally; that kernel then carves CPUs, memory, and PCI devices away from itself using existing hotplug mechanisms. A device tree describes the hardware for the new instance, and an extended kexec boots another Linux kernel into those resources. Normally kexec replaces the currently running kernel. Here it boots another one alongside it. Apparently the next logical step was: what if we just did all of that without killing the first kernel?
Resources are not necessarily permanent either—CPUs, memory, and devices can move between kernels while the machine stays up. One kernel for a database, another for an AI workload, another for networking; different configurations or even different kernel versions; restart or upgrade one without necessarily restarting the others.
What I especially like is the chance to tune the OS around individual workloads instead of forcing one compromise kernel to serve everything. Latency-sensitive work could have dedicated cores with almost nothing else interrupting them. A database kernel could be built around huge pages and storage. Another could own the GPU. That starts to sound less like virtualization and more like turning the OS itself into another resource you allocate to an application. I find that fascinating.
Multikernel Technologies is already pitching sandboxing AI agents—an agent in its own Linux kernel with dedicated resources and direct hardware access. I would be cautious about assuming that means "VM security without a hypervisor." There are still shared physical machines, DMA, firmware, and all the other wonderfully unpleasant places where isolation gets complicated. A new architecture does not automatically inherit decades of hypervisor security research. But giving an untrusted workload its own kernel and physical resources is certainly an interesting boundary to investigate.
Operationally, live kernel updates get weirdly good too. Move the workload, boot another kernel, move resources, retire the old one. Crash failover and rollback experiments are already underway. That turns "the kernel" into something much less permanent: a pool of hardware, kernels that come and go, workloads that move between them.
This is still the first public release—Linux 7.0 plus patches, not upstream, x86-64 initially—and the claims need broader independent testing. For the last year Multikernel existed primarily as patches and an architecture. Now people can actually build and break it.
There is something deeply appealing about the simplicity of the idea. Instead of pretending one computer is several computers through virtualization, physically divide the computer and let several Linux kernels use it. Modern servers already look like small collections of computers hiding inside one chassis. Maybe running one giant general-purpose kernel across all of it should not always be the default.
I don't think hypervisors are going away. I don't think containers are either. But Linux now has another genuinely interesting point in that design space: give the workload a real kernel and give the kernel real hardware. No hypervisor required. I am definitely going to have to find a machine to experiment with this on.
Read Cong Wang's mklinux v7.0-mk2 announcement.