Virtio devices
How block, network, console, balloon, memory-hotplug, random-number, and 9p devices are implemented, including the failure cases found under load.
Device model →One process per VM. No shared daemon.
Each FlashVM runs in its own process and exposes its own control endpoint — a Unix socket on Linux and macOS, a named pipe on Windows — protected by the operating system's own permissions. Warm-pool spares are booted before they are needed, so a new workload can claim a running VM instead of waiting for a cold boot. Running VMs can be captured, moved between physical hosts, and restored against a defined CPU template. The same control surface serves the CLI and MCP, with independent limits for CPU, memory, disk, and network resources. The same architecture runs on KVM on Linux (x86_64 and arm64), on Apple's Hypervisor.framework on Apple Silicon Macs, and on the Windows Hypervisor Platform on Windows (x64 and arm64).
In this section
Boot, claim, restore, fork and wake, measured on every platform.
Capability drop, per-thread seccomp, OS-native trust.
Per-VM caps and cross-host live migration.
NAT, bridge and routed modes; the flashnet helper.
How CPU caps are enforced without cgroups.
blk, net, console, balloon, rng, 9p.
Metrics, logs and events streamed over SSE.
One model on the host GPU, shared by every VM.
One process, one VM. Every FlashVM has its own address space, device model, vCPU threads, and crash boundary. There is no shared VMM process connecting otherwise independent guests.
One socket, one API. Each process serves its control API over a local endpoint — a Unix socket on Linux and macOS, a named pipe on Windows — rather than a network port. The operating system's own permissions govern access, without adding a separate application credential or authentication service.
A standalone deployment. FlashVMM ships as a self-contained binary. It does not depend on another product's repository, CDN, signing infrastructure, or update service to run.
flowchart TB
subgraph Host
CLI["flash CLI"]
MCP["flash-mcp
(MCP server, stdio JSON-RPC)"]
NET["flashnet
(privileged network helper)"]
subgraph VM_A["flashvmm process — VM A"]
SockA["unix socket
/run/flashvm/A.sock"]
VcpuA["vCPU threads"]
DevA["virtio-blk · virtio-net · virtio-console
virtio-balloon · virtio-mem · virtio-rng
virtio-9p"]
end
subgraph VM_B["flashvmm process — VM B"]
SockB["unix socket
/run/flashvm/B.sock"]
VcpuB["vCPU threads"]
DevB["virtio devices"]
end
end
CLI -->|spawn + exec, once at creation| VM_A
CLI -->|spawn + exec, once at creation| VM_B
CLI -->|HTTP, every command| SockA
CLI -->|HTTP, every command| SockB
MCP -->|HTTP + SSE| SockA
MCP -->|HTTP + SSE| SockB
NET -->|creates TAP, drops caps, execs| CLI
Cold boot performs work that does not need to happen when a request arrives. FlashVMM can boot generic spare VMs in advance, complete kernel and device initialization, and park them at zero CPU. When capacity is needed, flash claim assigns the workload, applies its CPU and disk limits, and starts it immediately.
sequenceDiagram participant Host participant Kernel as Guest kernel participant Agent as Guest-agent (PID 1) Host->>Host: map guest memory (~700us) Host->>Kernel: load kernel image, build boot params
(ACPI DSDT + virtio-mmio on x86,
device-tree on aarch64) Kernel->>Kernel: decompress (LZ4), init subsystems
(the ~70ms+ of real boot time) Kernel->>Agent: exec /init (no separate init system) Agent->>Agent: mount pseudo-fs, start reader/broker/
metrics threads, spawn zombie reaper Agent->>Host: Ready (over COM2 control channel) Host->>Host: report.running() — flash inspect now
shows state:"running", boot_us stamped Host->>Agent: Start (with entry point) Agent->>Agent: exec the workload
Ready, then waits. A claim updates its CPU and disk limits and sends Start.A claim can hand the spare a snapshot instead of an entry point — restore-via-claim. The spare's own already-running process becomes the restored capsule, so the restore pays neither the cold boot's kernel-init time nor a fresh process's spawn and privilege-drop cost. aarch64 only today; x86_64 refuses cleanly, since its uffd-based restore needs a capability an already-privilege-dropped process no longer has.
FlashVMM moves a running VM through three ordinary operations: capture, transfer, and restore. Capture freezes the guest and writes its vCPU registers, memory maps, and device state to a snapshot. That snapshot can then be moved to another physical host and resumed there.
CPU templates make compatibility explicit. A template masks host-specific CPU differences and defines the feature set presented to the guest. Before restore, FlashVMM checks the destination against that contract and refuses to proceed if a promised feature is unavailable.
Every restore gets fresh randomness. A snapshot carries the guest kernel's random-number state with its memory, so two VMs restored from one capture would otherwise produce the same "random" bytes — the same keys, the same session IDs. FlashVMM reseeds every restored, cloned and claimed guest from the host's CSPRNG as it resumes, on every platform, and the VM's run log records it.
Restoring onto a warm-pool spare instead of a fresh process is the same restore, applied without the spawn cost — see restore-via-claim above.
sequenceDiagram participant HA as Host A participant File participant HB as Host B HA->>HA: POST /v1/flashvm/snapshots (running VM) HA->>File: write snapshot File->>HB: move HB->>HB: PUT /v1/flashvm (source: Snapshot) HB->>HB: CPU template checked, fail-closed Note over HB: refused if a promised
CPU feature is missing
CPU, memory, disk capacity, disk I/O, and network traffic are enforced separately for each VM. A workload that exhausts one allocation cannot borrow capacity from another resource or another tenant.
| Resource | Mechanism |
|---|---|
| CPU | A signal-based pacer controls the execution window of each vCPU thread. |
| Memory | The KVM memory map sets a fixed ceiling that the guest cannot exceed; a virtio-mem region reserved within it can be grown or shrunk live, host-driven, without a reboot. |
| Disk capacity | A reserve-and-settle quota accounts for storage before writes are committed. |
| Disk I/O | Token buckets limit throughput and operations independently. |
| Network | Separate token buckets govern egress bandwidth, egress packet rate, and ingress bandwidth. |
flash-mcp exposes the FlashVMM lifecycle through twenty tools. Any MCP-compatible model can create and manage VMs, follow live telemetry, adjust resource limits, and run diagnostics through the same API used by the CLI. There is no separate automation layer to configure or keep in sync.
flowchart LR
subgraph Agent["Any MCP-speaking LLM"]
C["Claude"]
G["ChatGPT"]
M["Gemini"]
O["..."]
end
Agent -->|stdio JSON-RPC| MCP["flash-mcp"]
MCP -->|HTTP + SSE| SockA["unix socket
/run/flashvm/A.sock"]
MCP -->|HTTP + SSE| SockB["unix socket
/run/flashvm/B.sock"]
SockA --> VMA["FlashVM A"]
SockB --> VMB["FlashVM B"]
flash-mcp gives MCP-compatible models access to the same sockets and lifecycle operations used by the CLI.How block, network, console, balloon, memory-hotplug, random-number, and 9p devices are implemented, including the failure cases found under load.
Device model →How flashnet configures bridge, NAT, and routed networking without giving the VMM process CAP_NET_ADMIN.
How the pacer interrupts vCPU threads, accounts execution time, and applies a bounded grace period during boot.
CPU scheduling →Metrics, logs, and lifecycle events over Server-Sent Events, including explicit notification when a consumer falls behind.
Observability →One model loaded on the host GPU, shared by any number of VMs over their network cards, each with its own key. About 258 tokens/s from inside a VM on an Apple M4 Max, about 67 on integrated AMD graphics (Qwen2.5 1.5B).
GPU pools →FlashVMM uses HTTP/1.1 over AF_UNIX, with one socket per VM: /run/flashvm/<id>.sock for root, or $XDG_RUNTIME_DIR/flashvm/<id>.sock for an unprivileged user. The API, CLI, and MCP server are three ways into the same control surface.
Lifecycle operations, snapshots, resource updates, guest communication, command execution and files in the guest, metrics, logs, and events — strict resource CRUD.
The complete control surface for human operators: create, fork, exec, copy, snapshot, migrate — all through flash.
flash-mcp brings the same lifecycle to AI agents. See For AI agents for the tool reference.
How we make claims
FlashVMM has no dependency on any other product's repository, signing keys, CDN or updater. If you install FlashVMM, that installation is complete.
Every claim on this site maps to a named mechanism or a real measurement, and every number states how it was measured.
The same measurements run on macOS, Linux and Windows, x86 and ARM, and every figure is the median of repeated runs — see Performance.