Performance benchmarks

​

Latest QEMU published Ubuntu medians

​

Running your own benchmarks

uv run python scripts/benchmarks/ubuntu_transport.py \
  --variants qemu-ssh,qemu-vsock \
  --iterations 3 \
  --warm-exec-runs 5 \
  --rootfs-source published \
  --output /tmp/smolvm-ubuntu-transport.json \
  -v

uv run python scripts/benchmarks/disk_io.py \
  --iterations 3 \
  --json \
  --output /tmp/smolvm-disk-io.json

​

Performance characteristics

​

Boot performance

• Sandbox creation: SmolVM allocates names, IPs, disk metadata, and network rules in tens of milliseconds.
• Time to ready: QEMU + vsock reaches readiness in 413.1 ms on the latest published Ubuntu run; QEMU + SSH reaches readiness in 1152.2 ms.
• QEMU microvm default: On Linux x86_64 direct-kernel guests, QEMU uses the smaller microvm machine by default.
• Hardware virtualization: SmolVM uses KVM on Linux and Hypervisor.framework on macOS for near-native performance.
• Safe boot trims: The default MICROVM_DIRECT profile appends tsc=reliable no_timer_check quiet to the kernel command line. Set SMOLVM_VERBOSE_BOOT=1 to drop quiet when debugging a stuck boot.

​

Runtime performance

• Command execution: Warm-command latency is about 1.0 ms on vsock and about 43 ms on SSH.
• File transfer: New guest-agent builds use the newer streaming file-transfer protocol. Only compare transfer numbers after the published image advertises those capabilities.
• Memory overhead: Minimal host overhead beyond configured VM memory (default 512MB).
• CPU efficiency: Hardware virtualization provides near-native CPU performance.

​

Native helper performance

• Networking: TAP setup, route changes, and sysctls can use direct Linux calls when SmolVM has the right permissions.
• Disk I/O: zstd decompression uses a native path, while sparse copy keeps the host’s cp fast path when it is already best.
• QEMU control: Pause, resume, and snapshot control use a native QMP client.
• Firecracker control: Firecracker API socket requests use the native transport.

python -m smolvm_core

​

Teardown performance

• Graceful shutdown: SmolVM asks the backend to stop cleanly before removing local state.
• Resource Cleanup: Network rules, TAP devices, and disk images are cleaned up automatically
• Fast Path for Ephemeral VMs: SIGKILL-based teardown for sandbox VMs that don’t need state preservation

​

Optimization tips

​

1. Reuse VMs for multiple commands

from smolvm import SmolVM

with SmolVM() as vm:
    # The context manager starts the VM automatically
    result1 = vm.run("apk add py3-requests")
    result2 = vm.run("python3 script.py")
    result3 = vm.run("cat output.txt")

​

2. Use appropriate resource allocation

from smolvm import SmolVM

# Lightweight workload
with SmolVM(memory=256) as vm:
    print(vm.run("echo small").stdout)

# Heavy workload
with SmolVM(memory=2048) as vm:
    print(vm.run("python3 --version").stdout)

​

3. Pre-built custom images

from smolvm.build import ImageBuilder
from smolvm import SmolVM, VMConfig
from smolvm.utils import ensure_ssh_key

private_key, public_key = ensure_ssh_key()
builder = ImageBuilder()
kernel, rootfs = builder.build_alpine_ssh_key(
    public_key,
    rootfs_size_mb=2048,
)

config = VMConfig(
    kernel_path=kernel,
    rootfs_path=rootfs,
    boot_args="console=ttyS0 reboot=k panic=1 init=/init",
)

with SmolVM(config, ssh_key_path=str(private_key)) as vm:
    vm.run("apk add python3 py3-requests py3-numpy")

​

4. Shared vs isolated disk mode

• ✅ Complete isolation between VMs
• ✅ No cross-VM contamination
• ❌ Higher disk usage
• ❌ Copy overhead on first boot

• ✅ No disk copy overhead
• ✅ Lower disk usage
• ❌ Changes persist across VMs
• ❌ Potential cross-VM contamination

​

5. Backend selection

• Firecracker (Linux): Low overhead and a narrow device model, recommended for Linux production.
• QEMU (macOS/Linux): Broad compatibility, Windows guest support, and a faster microvm path on Linux x86_64.
• libkrun: Experimental runtime testing. It does not support snapshots yet.

from smolvm import SmolVM

# Explicitly choose backend
vm = SmolVM(backend="firecracker")  # Linux only
vm = SmolVM(backend="qemu")         # macOS/Linux

​

Performance monitoring

​

Check VM status

smolvm sandbox list

from smolvm import SmolVM

vm = SmolVM.from_id("my-vm")
info = vm.info
print(f"VM {vm.vm_id}: {info.status}")
print(f"  PID: {info.pid}")
if info.network:
    print(f"  IP: {info.network.guest_ip}")
vm.close()

​

Clean up stale VMs

smolvm sandbox delete --all --force

​

Scalability considerations

​

IP address pool

​

SSH port pool

​

System limits

# Check file descriptor limit
ulimit -n

# Check process limit
ulimit -u

# Increase limits (add to /etc/security/limits.conf)
* soft nofile 65536
* hard nofile 65536

​

Profiling tips

​

Measure individual phases

import time
from smolvm import SmolVM

# Create + start phase
start = time.time()
vm = SmolVM()
vm.start()
print(f"Create + Start: {time.time() - start:.3f}s")

# Command execution
start = time.time()
vm.run("echo hello")
print(f"Command: {time.time() - start:.3f}s")

# Teardown
start = time.time()
vm.delete()
vm.close()
print(f"Teardown: {time.time() - start:.3f}s")

​

Network latency

import time
from smolvm import SmolVM

with SmolVM() as vm:
    start = time.time()
    result = vm.run("echo pong")
    elapsed = (time.time() - start) * 1000
    print(f"Control-channel roundtrip: {elapsed:.1f}ms")