Firecracker Virtualization Overview

Source: Dev.to

Firecracker is an open source virtualization technology created by Amazon Web Services (AWS) which underpins their AWS Lambda Functions as a Service (FaaS) serverless product.

Firecracker was open‑sourced in 2018 [0], making it possible for anyone to use this extremely fast and reliable system for their own projects and use cases.

The ecosystem is surprisingly flexible: although it powers AWS Lambda, the design is not limited to that tightly‑controlled environment. It can be leveraged from AWS‑scale workloads down to a home lab running a single VM.

Firecracker High Level Overview

There are many good quick‑start documents [1] and blogs describing how to install and start a single Firecracker MicroVM instance, so the basic requirements are simply:

• Firecracker binary
• Kernel image
• Root filesystem (rootfs)
• Networking configuration (optional)

When you start a Firecracker VM by executing the firecracker program, you run a single VM instance that can be managed through the Firecracker process you launched. Management commands are sent via the HTTP API over a Unix socket. When the VM is no longer needed, it should be stopped gracefully.

Multiple Firecracker processes can run concurrently, which translates to multiple VMs—presumably how AWS runs millions of Lambda functions.

Configuration

VMs can be configured in two main ways:

1. Sending HTTP requests via the API socket – see the API reference [2].
2. Using a configuration file – see the getting‑started guide [3].

Even when a configuration file sets the guest kernel and rootfs, the socket can still be used for additional API requests. This dual approach reflects the system’s flexibility.

The HTTP API is wrapped by an official Go SDK [4], which can be used to programmatically manage Firecracker instances. AWS likely uses this SDK internally to provision and control Lambda functions via the same API.

Initialization

Firecracker can be initialized through several mechanisms:

• Direct command‑line execution
• Systemd unit files
• The jailer tool (see below)

The first two are common Linux patterns; the third provides additional isolation for multi‑tenant scenarios.

Enhanced Isolation using Jailer

The jailer tool [5] isolates each Firecracker process in its own chroot jail directory. This adds a layer of security suitable for multi‑tenant environments. For a home lab running trusted code, using the jailer is optional.

Demonstration

Below is a minimal Bash script that starts a Firecracker micro‑VM using a pre‑downloaded kernel and rootfs.

#!/usr/bin/env bash

firecracker="/usr/bin/firecracker"
uuid=$(/usr/bin/uuidgen)

# Start Firecracker in the background, exposing a Unix socket
nohup "$firecracker" --api-sock "/tmp/$uuid.socket" &

echo "created firecracker process running on socket: /tmp/$uuid.socket"

# Configure the kernel
curl --unix-socket "/tmp/$uuid.socket" -i \
    -X PUT 'http://localhost/boot-source' \
    -H 'Accept: application/json' \
    -H 'Content-Type: application/json' \
    -d '{
        "kernel_image_path": "/tmp/firecracker-test/hello-vmlinux.bin",
        "boot_args": "console=ttyS0 reboot=k panic=1 pci=off"
    }'

# Attach the root filesystem
curl --unix-socket "/tmp/$uuid.socket" -i \
    -X PUT 'http://localhost/drives/rootfs' \
    -H 'Accept: application/json' \
    -H 'Content-Type: application/json' \
    -d '{
        "drive_id": "rootfs",
        "path_on_host": "/tmp/firecracker-test/hello-rootfs.ext4",
        "is_root_device": true,
        "is_read_only": false
    }'

# Start the VM instance
curl --unix-socket "/tmp/$uuid.socket" -i \
    -X PUT 'http://localhost/actions' \
    -H 'Accept: application/json' \
    -H 'Content-Type: application/json' \
    -d '{
        "action_type": "InstanceStart"
    }'

echo "Started VM instance."

Running the script produces output similar to:

created firecracker process running on socket: /tmp/b214c708-e506-455b-a98d-647939a0ef0d.socket
nohup: appending output to 'nohup.out'
HTTP/1.1 204 
Server: Firecracker API
Connection: keep-alive

HTTP/1.1 204 
Server: Firecracker API
Connection: keep-alive

HTTP/1.1 204 
Server: Firecracker API
Connection: keep-alive

Started VM instance.

The nohup.out file then shows the VM booting:

 [ ok ]
 * Mounting persistent storage (pstore) filesystem ...
 [ ok ]
Starting default runlevel
[    1.088111] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2879b124109, max_idle_ns: 440795245440 ns

Welcome to Alpine Linux 3.8
Kernel 4.14.55-84.37.amzn2.x86_64 on an x86_64 (ttyS0)

localhost login:

The VM is up and ready for a login prompt (no networking or SSH keys were configured in this example). The script demonstrates how straightforward it is to launch a Firecracker micro‑VM using the HTTP API and a Unix socket.

Firecracker Ecosystem Discrepancies Compared to Lambda

AWS re:Invent talks (e.g., Julian Wood’s 2022 session A closer look at AWS Lambda (SVS404‑R) [video]) describe the Lambda data plane as a collection of services that handle synchronous and asynchronous invocations.

Synchronous services

• Frontend Invoke Service
• Counting Service
• Assignment Service
• Worker Hosts
• Placement Service

Asynchronous services

• Poller Fleet
• Queue Manager
• State Manager
• Stream Tracker
• Leasing Service

These administrative services orchestrate millions or billions of Lambda invocations. They are not part of the open‑source Firecracker project, which focuses solely on the lightweight virtualization layer. Consequently, while Firecracker provides the underlying VM runtime, the surrounding Lambda‑specific control plane remains proprietary to AWS.