Bare Metal vs Virtualized Hosts for Firecracker Agent Fleets

With Firecracker micro-VM isolation for AI agents, each agent has its own kernel. This comparison of bare metal and virtualized hosts explains why bare metal is the natural foundation for snapshot-restore fleets. Firecracker requires /dev/kvm, which the host provides directly, exposes through nested virtualization, or blocks entirely.

Why the host layer is an architecture decision for Firecracker agent fleets, not a procurement one

“Which cloud do you run on?” sounds like a procurement question, answered by a vendor name and an instance price. For a Firecracker agent fleet, however, that answer leaves the central constraint unresolved. Two instance families from the same provider can differ in which virtualization features they support. One may have the device Firecracker needs, while the other blocks it from starting. The choice therefore defines the architecture before it defines the bill.

That distinction matters because host suitability extends beyond whether a micro-VM boots. The path to KVM affects boot latency, I/O speed, snapshot-restore throughput, and the amount of useful work a host can carry. A fleet built around persistent agents must allow for those effects each time agents wake, run, and go back to sleep. Maritime makes this choice explicitly by deploying each agent inside its own Firecracker micro-VM on bare metal. Its host model treats direct KVM access as a constraint on latency, density, and per-agent economics rather than a detail to settle after the runtime is built.

How does Firecracker give each AI agent its own kernel, and why does it require /dev/kvm?

Firecracker is a userspace virtual machine monitor that drives KVM to run micro-VMs, each with its own kernel. It opens /dev/kvm, requests a VM file descriptor, creates vCPU descriptors, and operates through ioctl calls. That device is not an optional acceleration feature. Without it, Firecracker has no emulation fallback and fails at startup.

Firecracker is kept small by design, at roughly 50,000 lines of Rust. Firecracker’s GitHub FAQ lists six emulated devices, including virtio-net, virtio-balloon, virtio-block, virtio-vsock, serial console, and a minimal keyboard controller used only to stop the microVM. This minimal device model is part of its design and remains dependent on the capabilities the host makes available. It also does not provide GPU passthrough, CPU hotplugging, or support for hosting nested virtualization. Running Firecracker inside an outer VM is a separate question from using Firecracker itself as a host for another virtualization layer.

OCI’s Firecracker guidance draws the relevant host distinction directly. Bare metal gives the operator control of the host OS and direct KVM access. An outer VM instead needs nested virtualization to make /dev/kvm available inside its guest. Firecracker’s minimal design cannot bypass that requirement, so the next question is which hosts expose it and under what conditions.

How each major cloud exposes or blocks /dev/kvm, and what that means in practice

Amazon EC2 exposes nested virtualization on 8th-generation Intel virtualized instances, including C8i, M8i, R8i and related families, through the NestedVirtualization CPU option. That makes supported virtualized instances a real deployment option. Only some EC2 instances have this support. Bare-metal instance types are still the reliable choice for workloads that need high performance and families that do not support nesting.

Google Compute Engine makes nested virtualization a per-instance-template setting restricted by machine family and CPU platform. Its exclusions include E2 VMs, memory-optimized VMs, Arm families, and AMD families except N4D. On a supported configuration, the enabling Terraform setting is advanced_machine_features { enable_nested_virtualization = true }. The configuration line matters, but only after the underlying family qualifies. A flag cannot turn an excluded machine family into a supported one.

OCI’s Firecracker guidance describes support on both bare metal and select VM shapes with nested virtualization. Teams can choose a direct path to the hardware or the ease of running a VM, as long as the chosen shape supports nesting. Across these providers, advertised CPU capabilities and usable KVM access remain different facts. Virtualization extensions can appear in /proc/cpuinfo while /dev/kvm is absent because the provider has not exposed nesting on that family. A bootstrap check must therefore check that the device is there and that the process can use it, along with the CPU flags.

What nested virtualization actually costs, mechanically, for a snapshot-restore fleet

Nested virtualization does not impose one uniform percentage penalty. On bare metal, a guest exit traps into the host kernel’s KVM, which handles it and resumes execution. With nesting, an L2 exit goes to L0 first. L0 then decides whether to service it directly or reflect it into L1’s KVM before the VMM handles it. Some exits still cost relatively little, while others go through two hypervisors.

Memory translation adds another source of work. Hardware nested paging is designed for one virtualization level, so an additional level requires L0 to maintain a merged mapping. Page faults that would otherwise be handled once can create work at two levels. This matters especially during snapshot restore, which maps a memory file, resumes the guest, and lets it fault its working set back into memory. With userfaultfd, a handler services those faults by pulling chunks and installing them.

A restore-heavy fleet repeatedly generates the workload for which that second translation level is least free. Agents that sleep and wake hundreds of times per day pay the cost each time they restore, as well as when they first deploy. Across thousands of concurrent restores, those costs accumulate. For a snapshot-restore platform such as Maritime, avoiding nesting therefore serves the scheduling model itself. Performance depends on both how quickly agents recover their working sets and how quickly an already-running guest executes CPU-bound code.

Storage provides a concrete illustration of the gap. Inside an outer VM, I/O traverses the guest virtio driver and the VM’s hypervisor before reaching physical hardware, adding a layer absent from the bare-metal path. OCI reports that random I/O on bare metal is nearly 1.8× faster, with latency almost half that of the equivalent VM shape. OCI labels these results as illustrative observations from a single environment, with no formal benchmark status or guarantee. The results illustrate the direction of the difference and its mechanism, with the multiplier specific to that environment.

Where bare metal's advantages compound: density, GPU access, and steady-state economics

Removing nesting gives the fleet more than a shorter exit path. It removes work that would otherwise compete with agent execution and restore activity on the host. That lets more agents share a host, especially when many need to resume at once. The benefit grows as the host spends more of its time restoring memory and serving storage and less on uninterrupted CPU work. Density consequently depends on the workload and host path as well as the count of configured vCPUs.

Nested environments generally do not expose the physical IOMMU groups needed for PCIe passthrough, so binding a physical GPU into a nested guest fails by default. Workarounds such as an emulated vIOMMU exist, but they do not make nesting equivalent to direct hardware access. Bare metal removes that outer hypervisor constraint and makes physical device binding available at the host layer. However, Firecracker’s own lack of GPU passthrough remains a separate limitation, so direct /dev/kvm access must not be mistaken for native GPU support in Firecracker.

That distinction matters for agents running local model inference or GPU-accelerated code execution. Bare metal addresses the host prerequisite, but it does not by itself establish that the chosen VMM can expose the required device. The architecture must satisfy both conditions. Treating GPU access as merely another instance-size choice would repeat the same mistake as treating KVM access as a procurement detail.

The economic case is strongest at steady load. The fleet shares a flat monthly cost for the bare-metal server, while snapshotted idle agents consume storage and leave compute capacity available. If only a small fraction of users are awake at once, the server can support many multiples of its simultaneous running capacity as dormant tenants. That differs from a per-minute cloud instance meter that continues while its agents sleep. The savings depend on the active-to-idle ratio and how much of the host is in use, so the per-agent price varies.

When a VM with nested virtualization is actually the right call

A supported VM remains a legitimate production choice when elasticity and operational convenience outweigh the nesting cost. OCI’s Firecracker guidance describes VMs with /dev/kvm as offering practical performance with modest overhead, while bare metal offers the lowest tail latency and highest throughput. It recommends VMs for most microservices and ephemeral jobs, with bare metal favored when storage intensity or latency SLOs are paramount.

VMs let teams add or remove instances as needed and vary what they spend on compute. That freedom can matter more than peak throughput when a product is new or its load is very hard to predict. For CPU-bound or network-light agent tasks, the overhead may also be low enough to accept. Bare metal, by contrast, commits the operator to fixed capacity, host OS ownership, hardware failures, and infrastructure management work. The choice should turn on whether elasticity is essential and whether snapshot-restore throughput or hardware passthrough sits on the critical path, with Firecracker’s separate device limits accounted for.

A practical checklist for evaluating any host before committing a Firecracker agent fleet

Before settling on the fleet architecture, teams should test the host with a bootstrap sequence that checks both signs of support and whether access works. First check for vmx or svm in /proc/cpuinfo, then for the hypervisor flag, then for /dev/kvm, then for the kernel module’s nesting state. Finally, test whether the user that runs the process can read, write, and open the device. Retrieving the KVM API version, with an expected value of 12, tests more than the presence of a pathname. When the provider withholds nesting on a shape, CPU flags without the device do not establish support, and a kernel argument will not supply it.

Next establish the nesting depth using the hypervisor flag and systemd-detect-virt output together. The distinction is between a bare-metal KVM host and an L1 VM whose Firecracker guests run at L2. That result identifies which exit and memory-translation path the fleet will use. Check how well that path fits the workload, especially how often agents restore, how heavily they use storage, and what latency they need. Snapshot-restore-intensive fleets strongly favor bare metal, while ephemeral CPU-bound work with a need for elasticity can start on a supported nested VM.

GPU requirements need their own gate even after a successful boot. Nested passthrough constraints and Firecracker’s device model are separate obstacles, and removing the former does not remove the latter. The same discipline applies to cost comparison. Model the fleet’s actual active-to-idle ratio, including snapshot storage, the fixed cost of bare metal, and bills for the outer VM while agents are idle. Include the engineering time it takes to own the host OS, handle hardware failures, and run without cloud-provider elasticity.

These criteria also provide a concrete way to assess a managed platform. Maritime uses bare metal, direct KVM access, a persistent disk for each agent, and a snapshot-restore scheduler that wakes agents in under a second. Whether the fleet uses that approach, independently managed bare metal, or a supported cloud VM, the decision determines which latency, capacity, and cost promises the product can sustain.