Nanvix: A Multikernel OS Design for High-Density Serverless Deployments

Nanvix is a multikernel operating system designed for high-density serverless deployments that achieves strong tenant isolation and reduced resource contention by disaggregating ephemeral execution state into lightweight user VMs while sharing a macro-kernel system VM for I/O among same-tenant applications, resulting in significantly faster startup times and up to 100x higher deployment density compared to state-of-the-art systems.

The Gist

The Big Problem: The "Serverless" Traffic Jam

Imagine a massive, high-speed restaurant called Serverless Land.

• The Goal: The restaurant wants to serve as many customers (applications) as possible on a single building (server) to save money and energy. This is called Deployment Density.
• The Problem: To keep customers safe from each other (so one customer's bad cooking doesn't poison the next), the restaurant puts every customer in their own private, soundproof booth (a Virtual Machine or VM).
• The Catch: Building a new booth takes time and materials. If a customer arrives and the kitchen has to build a whole new booth from scratch, the wait time (Cold Start Latency) is huge.
• The Dilemma:
  • If you build a booth for every customer, you run out of space (low density) and the wait times are long.
  • If you try to squeeze multiple customers into one booth to save space, they might hear each other or steal each other's food (security risks and performance slowdowns).

Current solutions are stuck in the middle: they are either too slow to start or too heavy to fit many on one server.

---

The Nanvix Solution: The "Split-Brain" Restaurant

The authors of this paper, Nanvix, propose a radical new way to run these booths. Instead of one giant, heavy booth for every customer, they split the booth into two distinct parts: The Tiny Booth and The Shared Kitchen.

1. The Tiny Booth (The User VM)

This is where the customer (your app code) actually sits.

• What's inside: Just the absolute essentials. A chair, a table, and a very simple waiter (a Micro-kernel) who knows how to manage the customer's thoughts and memory.
• What's missing: No stove, no sink, no plumbing, no delivery trucks.
• Why it's great: Because it's so small and simple, you can build a new one in milliseconds. It's like setting up a pop-up tent instead of a brick house.

2. The Shared Kitchen (The System VM)

This is a separate, heavy-duty room that handles all the messy, heavy stuff.

• What's inside: The stove, the sink, the internet connection, the file cabinets, and the delivery trucks (Device drivers, Network, File Systems).
• Who uses it: This kitchen is shared by all the customers belonging to the same group (Tenant).
• How it works: When the customer in the Tiny Booth needs to send a letter (I/O request), they don't build a post office. They just hand the letter to the waiter, who runs it over to the Shared Kitchen. The Kitchen handles the heavy lifting and sends the reply back.

The Magic Analogy: The "Hotel vs. Apartment" Model

Think of it like a hotel vs. an apartment complex:

• Old Way (Traditional VMs): Every time a guest arrives, the hotel builds a brand new, fully furnished apartment with its own plumbing, electricity, and kitchen. It takes forever to build, and you can only fit a few guests in the building.
• Nanvix Way:
  • The guest gets a tiny, empty hotel room (User VM) that takes 1 second to clean and hand over.
  • The room has a doorbell.
  • When the guest needs a meal, they ring the bell.
  • A central, high-tech kitchen (System VM) that is already running and staffed with chefs prepares the food and slides it through the door.
  • Because the kitchen is shared among all guests in the same family (Tenant), you don't need to build a new kitchen for every guest. You just need a new tiny room.

Why This Changes Everything

The paper shows that this "Split Design" solves the three biggest headaches in serverless computing:

1. Speed (Cold Starts):

   • Analogy: Instead of waiting for a construction crew to build a house, you just drop a tent down.
   • Result: Nanvix starts applications 10 to 100 times faster than current systems.

2. Density (Fitting More on One Server):

   • Analogy: Since you aren't building a full kitchen for every guest, you can fit 30–50% more guests in the same building.
   • Result: In a test, Nanvix needed 20 to 100 times fewer servers to handle the same amount of work compared to top competitors like Firecracker.

3. Safety (Isolation):

   • Analogy: Even though they share a kitchen, every guest is still in their own soundproof, locked room. If Guest A tries to hack the door, they can't get into Guest B's room.
   • Result: It keeps the strong security of a Virtual Machine but removes the weight.

The Trade-off (The "Extra Step")

Is there a downside? Yes, but it's small.

• In the old way, the guest cooks their own food (everything is in one room).
• In Nanvix, the guest has to walk to the door, hand the order to the waiter, wait for the kitchen to cook, and bring it back.
• The Paper's Finding: This "extra walk" adds a tiny bit of delay (about 50% more overhead for very small tasks), but because the kitchen is so efficient and the rooms are so fast to build, the overall speed and cost savings are massive.

The Bottom Line

Nanvix is like realizing that you don't need a full house for every person who visits your city. You just need a tiny, instant-to-build waiting room and a shared, super-efficient city utility center.

By separating the "temporary" part of an app (the code running right now) from the "permanent" part (the drivers and file systems), Nanvix allows cloud providers to run way more applications on way fewer servers, making the internet faster and cheaper for everyone.

Technical Summary

1. Problem Statement

Serverless computing providers face a fundamental trade-off between deployment density (the number of applications per host server) and application isolation/performance.

• The Challenge: To achieve high density, providers must share resources across applications. However, sharing components between different tenants introduces security risks (side-channel attacks), necessitating strong isolation via Virtual Machines (VMs).
• The Bottleneck: Traditional VM-based approaches use a full-featured Guest OS for every application invocation. This results in:
  • High Cold Start Latency: Initializing a full OS (device drivers, network stacks, file systems) takes hundreds of milliseconds.
  • Low Deployment Density: The memory footprint of full OSs is large, limiting the number of concurrent instances per server.
  • Resource Contention: Sharing a single "Base VM" among multiple containers (a common alternative) leads to resource stranding or latency penalties when dynamically resizing resources (hot-plugging).
• The Core Insight: The high cost of compatibility stems from requiring every ephemeral application invocation to initialize a full OS. The authors argue that the ephemeral execution state (threads, memory, scheduling) should be disaggregated from the long-lived persistent state (device drivers, network stacks, file systems).

2. Methodology: The Nanvix Architecture

Nanvix is a multikernel OS designed specifically for serverless workloads. It splits the traditional OS services into two distinct, co-designed virtualized environments:

A. User VM (Micro-kernel)

• Role: Executes the application code and manages ephemeral state.
• Design: A lightweight, custom micro-kernel written in Rust.
• Features:
  • Implements processes, threads, scheduling, memory management, IPC, and a POSIX compatibility layer.
  • Excludes device drivers, network stacks, and file systems.
  • Startup: Extremely fast (milliseconds) because it avoids scanning ACPI tables or enumerating PCI devices.
  • I/O Handling: Forwards all I/O system calls to the System VM via a specialized communication channel.

B. System VM (Macro-kernel)

• Role: Serves as a shared resource for all User VMs belonging to the same tenant.
• Design: Runs a trimmed Linux kernel (Macro-kernel) acting as a "system server."
• Features:
  • Contains the full set of device drivers, network stacks, and file systems.
  • Long-lived: Unlike User VMs, System VMs are persistent, pre-warmed, and auto-scaled.
  • Multiplexing: It handles I/O requests from multiple User VMs, reducing resource contention.
  • Isolation: It does not execute tenant-specific application code, allowing it to be restored from a generic snapshot for all tenants.

C. Communication & Co-Design

• Inter-Kernel Communication: User VMs and System VMs communicate via a custom, credit-based flow control mechanism using shared memory and Port-Mapped I/O (PMIO).
• Zero-Copy Optimization: The system uses a rendezvous-style protocol for bulk data transfer to minimize VM exits and memory copying.
• Compatibility: Nanvix supports unmodified C, C++, and Rust applications (via recompilation with a custom toolchain) and supports Python, JavaScript, and WebAssembly by compiling their runtimes.

3. Key Contributions

1. Disaggregated Multikernel Design: A novel architecture that separates ephemeral execution state from persistent system state, allowing the heavy OS components to be shared safely among same-tenant applications while maintaining strong hypervisor isolation between tenants.
2. Custom Micro-kernel & VMM: A purpose-built micro-kernel and Virtual Machine Monitor (VMM) in Rust that eliminates unnecessary initialization overhead, achieving sub-10ms cold starts for User VMs.
3. Efficient I/O Multiplexing: A design where a single System VM handles I/O for many User VMs, eliminating the resource stranding issues found in "containers-in-VMs" approaches and reducing the need for complex snapshot management.
4. Open-Source Implementation: The entire system is implemented in Rust and released as open-source, providing a clean-slate alternative to existing solutions like Firecracker or Unikraft.

4. Evaluation Results

The authors evaluated Nanvix against state-of-the-art baselines (Firecracker, CloudHypervisor, gVisor, Unikraft, Hyperlight) using microbenchmarks and a production trace replay (Huawei 2025 trace).

• Cold Start Latency:
  • User VM Startup: Nanvix User VMs start in ~7ms (p50) and ~11ms (p99) when the System VM is already running.
  • Full Startup: A full deployment (System + User VM) takes <30ms.
  • Comparison: This is 20–100× faster than traditional VMs (Firecracker/CloudHypervisor) and 6–11× faster than specialized solutions like gVisor or Unikraft.
• Memory Footprint & Density:
  • User VMs have an order-of-magnitude smaller memory footprint than full Linux VMs.
  • In a worst-case scenario (1 System VM per User VM), Nanvix matches snapshot-based baselines.
  • In a realistic scenario (sharing one System VM per tenant), Nanvix achieves 30–50% more sandboxes per GiB of memory compared to snapshot-based systems.
• Deployment Density (Trace Replay):
  • When replaying a production trace, a serverless fleet using Nanvix requires 20–100× fewer physical servers compared to Firecracker or optimized snapshot-based systems to handle the same load.
  • This is primarily due to reduced resource contention on host OS resources (e.g., network namespaces) and faster startup times allowing higher throughput.
• Overhead:
  • The additional hop to the System VM introduces a modest ~50% overhead in round-trip latency for small payloads compared to direct execution, but this is negligible compared to the startup savings.
  • Bulk data transfer is optimized to prevent latency spikes as payload size increases.

5. Significance

Nanvix demonstrates that application compatibility does not require a full Guest OS for every invocation. By rethinking the OS abstraction for serverless workloads:

• Security: It maintains strong hypervisor-level isolation between tenants, avoiding the side-channel risks of shared kernels or containers.
• Efficiency: It solves the "cold start vs. density" dilemma, enabling providers to run significantly more applications on fewer servers without compromising performance.
• Scalability: It removes the complexity of managing massive snapshot libraries and the latency penalties of dynamic resource resizing (hot-plugging).

The paper concludes that Nanvix offers a principled path forward for serverless infrastructure, shifting the paradigm from "fast snapshots of heavy OSs" to "lightweight execution environments sharing a persistent system core."