CPU templates
Templates mask CPUID leaves and define the CPU features available to the guest. A destination that cannot satisfy the template is rejected. Options include host-raw and the vendor-specific t-amd-v1 and t-intel-v1 templates.
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. Operators can move running workloads between physical hosts, 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.
Cross-host live migration
Migration is composed from three operations: capture a running VM, transfer the snapshot, and restore it on another physical host. The workflow stays visible and scriptable instead of being hidden behind a separate migration service.
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
migrate verb.Measured migration
Cross-host migration was measured between independent physical machines running different kernel versions. One direction completed successfully; the incompatible reverse path was rejected with a contract-mismatch error.
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, with private SGI/PPI state outside the snapshot boundary. 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.
10 MCP tools
flash-mcp brings the same lifecycle to AI agents. See LLM for the tool reference.