Most Linux stories are about features. This one is about removing a layer you forgot you were paying for. The mklinux v7.0-mk2 tree from Multikernel Technologies is the first public release of a fork that runs multiple independent Linux kernels on the same physical machine, with no hypervisor in the path. That sentence sounds like marketing. It is not. I read the docs, looked at how the boot flow is wired, and I think the people who run bare metal for a living are going to want to pay attention.
The project is named mklinux. Version 7.0-mk2 is the first public cut. It is a direct fork of mainline Linux with patches layered on top. There is no compatibility shim, no userspace trick. Each instance is a real kernel booting natively on a slice of hardware.
Here is what that means in plain terms:
- One host kernel owns the machine’s CPUs, memory, and PCI devices at boot
- The host uses kexec (a kernel mechanism normally used for fast reboots) to spawn more kernels on dedicated hardware
- Each spawned kernel sees its own cores, its own RAM, and its own devices, not a virtual copy of them
- Modern NICs and NVMe drives can hand out separate queues to each kernel, so isolation is hardware-backed
- There is no shared kernel between tenants and no VMM (virtual machine monitor) sitting in the middle
The architecture diagram on their site shows the host kernel on the left, three app kernels on the right, and lines from each app kernel to its own CPU package, RAM bank, and PCIe slot. It is the kind of picture that either means something or means nothing depending on how the boot sequence is wired. In this case it means something.
How the boot flow actually works
When mklinux boots, the first kernel to load becomes the host. It enumerates the platform, takes the SR-IOV capable devices under its control, and exposes them through a sysfs tree at /sys/fs/multikernel/. From there, the operator (or a small management tool) tells the host which cores and memory ranges to hand off, and the host uses kexec to load a fresh kernel on those resources.
The fresh kernel boots the way any Linux box boots. It does not know it is sharing the machine. It does not know there is a host. It sees its CPUs, its RAM, its NIC, its drive, and that is the whole world from its perspective. If you want to move a device from one running instance to another, the host does the rewire through device tree overlays (small description files that tell the kernel which hardware exists where) and the running instance picks up the change without a reboot. That part is genuinely new.
The team picked a sensible split: one kernel for application workloads, one for device drivers, and the host in charge of resource arbitration. Driver code never shares a kernel context with app code. The result is a clean failure-domain boundary that you normally only get from separate physical machines.
Why containers and VMs do not get you here
I have been running a mix of KVM and container workloads for years, so I am the first person to ask the dumb question. Why not just spin up a VM or a container and call it a day. Here is the honest answer.
A virtual machine still pays for a hypervisor and a host kernel between your workload and the metal. You eat the latency, you eat the memory overhead, and if you want direct device access you are configuring passthrough (a mechanism that hands a physical device to a single VM) and hoping your IOMMU (input/output memory management unit, the chip feature that enforces device isolation) plays nice. A container is lighter, but every container on a host shares one kernel. A noisy neighbor, a kernel bug, or a misbehaving syscall can take down workloads that never touched each other.
Multikernel sidesteps both problems by giving each workload its own full kernel on bare metal. If you care about tail latency (the slowest 1% of requests, which is what users actually feel), security boundaries, or running an AI agent that you really do not want sharing a kernel with anything else, that is a meaningful upgrade. The cost is the one every new architecture charges: you give up tooling that has had twenty years to mature.
The three products Multikernel is selling
The fork is the kernel. On top of it, the company is pitching three products that map to specific jobs:
- Private Cloud for consolidating workloads on bare metal without a hypervisor in the path
- Sandbox for running AI agents in their own kernel with direct GPU access
- LiveUpdate for patching a running kernel without scheduling downtime
The LiveUpdate pitch is the one that SRE (site reliability engineering) teams have been begging for since forever. A kernel patch you can apply while the system stays up is the kind of feature that justifies a six-month pilot by itself. The Sandbox pitch is the one AI infrastructure teams should look at. Direct GPU access, no shared kernel, no hypervisor overhead.
None of those products are aimed at desktop users. If you are reading this on a laptop and wondering whether to try mklinux on your daily driver, the answer is no. Not yet. Maybe not ever, depending on how the consumer story shakes out.
A practical first look for bare metal operators
If you do run bare metal for a living, the safest first move is a non-production box with a recent x86_64 CPU and an SR-IOV capable NIC. Pull the source, compile the host kernel, then compile an app kernel against the same tree. Boot the host, spawn the app kernel through kexec, and watch what shows up under /sys/fs/multikernel/. Move a device between instances while the system is up. That is the test that tells you whether this is real or a clever demo.
Things to watch during that test:
- How kexec behaves under load, and whether the new instance comes back clean every time
- Whether the IOMMU groups on your hardware let you split devices the way you want
- How the host kernel reports its own resource usage when three app kernels are running
- Whether your existing monitoring stack can see inside each instance
Keep a rescue image handy. A freshly spawned instance that refuses to come back is the kind of problem that gets worse if you do not have a fallback ready.
Trade-offs
The trade-offs here are real and they are not edge cases:
- x86_64 only at launch, so ARM and RISC-V fleets are waiting on ports that may or may not land on a useful timeline
- Tracking upstream Linux is on the Multikernel team, and you are trusting them to keep the tree stable across merge windows
- The management layer is young, and there is no equivalent to libvirt (the standard open source VM management toolkit) or your usual hypervisor control plane yet
- Documentation is written for kernel and infrastructure engineers, not for developers used to a Docker tutorial
- Moving workloads around dynamically is more constrained than with a mature hypervisor, because hardware queues do not reconfigure for free
The fact that someone finally shipped a multikernel Linux tree in the open is worth paying attention to on its own. Whether the trade-offs are right for your shop is a separate question, and only your pilot on a real box can answer it.
[image placeholder: a side-by-side comparison chart with VM, Container, and Multikernel across rows like hypervisor in path, shared kernel, dedicated hardware queues, and boot time]