Real use, not promises
Memory is measured where the host pays for it, and prediction follows each VM's recent peak use. Overcommit ratios, headroom and pressure lines are one policy per host, set with flash host policy.
For fleet and cloud operators
Per-VM control at fleet scale.
FlashVMM treats each VM as an independent unit of placement, enforcement, and observation. CPU, memory, disk capacity, disk I/O, and network limits are applied per VM on both x86_64 and aarch64. Every host knows its own room and admits only what fits; one controller places VMs across many hosts and moves running ones between them. Operators follow lifecycle and resource data over SSE and manage the fleet through the API, CLI, MCP, or their own tooling. Nested virtualization extends the same model to KVM workloads running inside a FlashVM, including snapshot and restore.
Resource enforcement at the VM boundary
| Resource | Mechanism |
|---|---|
| CPU | A signal-based pacer thread uses tgkill to enforce execution limits without relying on cgroups. |
| Memory | The KVM mapping sets a hard ceiling. PATCH /memory returns 422 memory_immutable; ballooning reclaims idle pages, and a virtio-mem region grows or shrinks a tenant's live footprint on the host's own schedule — right-size into more RAM once a workload's real need is known, reclaim it deterministically when it isn't, all without a reboot. |
| Disk capacity | A reserve-and-settle quota accounts for allocated blocks and applies a separate per-inode charge. |
| Disk I/O rate | Token buckets in the io_uring path govern throughput and operations independently. |
| Network | Each NIC has separate token buckets for egress bandwidth, egress packet rate, and ingress bandwidth. |
| vCPU count | A fixed ceiling is applied at cold boot and enforced on restore. |
| NIC count | The same fixed ceiling applies on x86_64 and aarch64. |
Each resource is governed independently, so changing one allocation does not alter the enforcement of another.
Every host knows its own room
Each host runs flashhostd, which counts every VM on it: what the VM asked for, what it really uses, and what it will need next. A new VM is placed only where it fits, and the reason is given when it does not. It also meters what every VM used, hour by hour: CPU time, memory over time, disk and network (flash host usage).
Room freed on its own
When memory runs short, the host frees room one step at a time: it shrinks idle VMs, rebuilds idle spares later, and can put the least busy VM to sleep. Nothing is killed.
One check for every create
flash run, wake, pool spares and fleet placement all pass the same check, serialized on the host: twenty requests for room for ten admit exactly ten.
One controller, many hosts
flash controller is the same binary in another role. It needs no virtualization of its own, reaches hosts over SSH with the keys you already have (or, for large fleets, over a certificate-protected port with certificates flash makes itself), and places each VM on the host where it fits best.
sequenceDiagram
participant C as Controller
participant A as Host A
participant B as Host B
C->>A: VM web-1 (2 vCPU, 2 GiB)?
A-->>C: full, with the reason
C->>B: VM web-1?
B-->>C: placed, running
C->>B: move web-1 to Host A
B->>A: memory copied while asleep
A-->>C: running where it left off
Spread by fit
Fifty VMs placed across three hosts of three operating systems in three seconds, each handed on whenever a host was full, and all fifty running.
Live moves, one command
flash controller move carries a running VM to another host: its program continues exactly where it was. A 256 MB VM moved between two physical Linux x86 machines with different CPUs in 27 s, on macOS, Linux and Windows alike.
Never lost, never twice
A move either completes or wakes the VM back where it was. Its old copy is marked while it moves, so it cannot run twice, and a controller restart mid-move is picked up again with one command.
CPU templates
The same CPU everywhere
Templates define exactly the CPU features a guest sees, so a VM restored or moved onto another machine finds the CPU it started with. Options include t-v2, t-v3, the vendor templates t-amd-v1 and t-intel-v1, and host-raw.
ARM interrupt controllers
Snapshot and restore support both GICv2 and GICv3, selected in the same way irqchip::create chooses the controller at boot. GICv2 restore covers distributor and per-vCPU interface state. See Performance for results from both versions.
Observability at fleet scale
Blended live metrics
A single Server-Sent Events stream combines guest-reported CPU, memory, and swap data with host-measured disk, quota, and NIC counters.
Explicit backpressure
When a consumer falls behind, the stream reports a lagged event instead of silently discarding the gap.
Bounded logs with clear truncation
Each VM keeps two 256 KiB head-and-tail log buffers. If output is truncated, the buffer records the omission rather than presenting an incomplete stream as complete.
Control surface
~30 API routes
Lifecycle operations, snapshots, restores, warm-pool claims, and live resource updates.
36 CLI commands
The complete operator workflow, with VM creation handled through flash.
21 MCP tools
flash-mcp brings the same lifecycle, host and fleet controls to AI agents. See For AI agents for the tool reference.