One Machine, Many Kernels
Multikernel runs several independent Linux kernels on the same physical server at the same time. Each kernel owns its own cores, memory, and devices, and there is no hypervisor underneath any of them. This page walks through how that happens, without the deep details.
The Big Picture
A normal server runs one Linux kernel that owns every core, every byte of memory, and every device. Multikernel divides that machine into kernel domains. Each domain is a complete Linux kernel with a dedicated share of the hardware: its own cores, its own memory, and whichever devices you assign to it. The kernels are peers. None of them is a host, a guest, or a hypervisor.
Every box is a complete, unmodified Linux kernel. They share the machine, not a kernel.
From Boot to Running Workload
Five steps, all built on mechanisms Linux already has.
Boot Linux as Usual
The machine boots a standard Linux kernel with the Multikernel patches. Nothing changes for your firmware, bootloader, or drivers. This first kernel starts out owning the whole machine.
Carve Out Resources
You decide how the machine is divided. A set of cores, a block of memory, and optionally some devices are taken offline from the running kernel using standard CPU, memory, and device hotplug, and set aside for a new kernel.
Spawn a New Kernel
Linux's kexec mechanism, extended to boot alongside the running kernel rather than replace it, starts a fresh kernel on those resources. It comes up in tens of milliseconds and can boot straight into a container image.
Talk Through Shared Memory
Kernels never call into each other. When they need to cooperate, they exchange data through a region of memory mapped by both sides, so nothing is copied and no kernel waits on another one's locks.
Run, Rebalance, Retire
Each kernel runs its workload unmodified with native performance. Cores, memory, and devices can be moved between kernels at runtime, and when a kernel is no longer needed it is torn down and its resources return to the pool.
The Three Pieces
Everything above comes down to three mechanisms.
Resource Partitioning
Cores, memory, and devices are assigned to exactly one kernel at a time. Ownership is explicit and can change at runtime, so the machine is divided by policy, not by accident.
Kernel Spawning
Any running kernel can launch another one on resources it has set aside, using kexec. Each new kernel is a full, independent Linux instance with its own failure and update domain.
Shared Memory / DAXFS
The only thing kernels share on purpose. A region of memory exposed as a filesystem, used for message queues, container root filesystems, and data that kernels want to exchange without copying.
The Split-Kernel Configuration
Multikernel itself does not care what each kernel does. In practice, one arrangement stands out because it turns kernel isolation into a performance advantage: give all the physical devices to a single kernel, the device-kernel, and give none to the others, the app-kernels. This is the configuration our products are built on.
The device-kernel runs every driver and takes every interrupt. Each app-kernel sees a virtual NIC and virtual disk whose queues live in shared memory, so packets and blocks stay in place and only descriptors cross the boundary. Applications get cores that no device ever interrupts, and the driver stack can be updated or restarted without touching them.
This is what the Technology page describes in depth. It is one way to use Multikernel, not the only one: kernels can also own devices directly, or mix both styles on the same machine.
One kernel owns the hardware, the rest are interrupt-free.
Why This Design
What separate kernels buy you that containers and virtual machines do not.
Isolation Without a Hypervisor
Each workload has its own kernel, so a kernel bug or exploit in one cannot reach another. There is no hypervisor layer to pay for, and it works on bare metal or inside VMs you already run.
Native Performance
Applications run directly on the CPU and memory assigned to them. No trapping, no nested page tables, and no lock contention with kernels running someone else's workload.
Independent Lifecycles
Kernels come and go independently. Upgrade or restart one kernel while the others keep running, without rebooting the machine.
A Kernel Tailored to Each Application
Every kernel can be a different build with its own version, config, and tuning. A database gets huge pages and a deadline scheduler, a network service gets a lean stack with busy polling, without either compromise leaking into the other.
Still Just Linux
Applications, container images, and tooling run unmodified. There is no new operating system to learn and no compatibility gap to work around.