flash-mcp gives MCP-compatible agents direct access to the complete FlashVM lifecycle. An agent can create and inspect VMs, apply resource policies, stream metrics and logs, diagnose workload health, capture snapshots, restore or clone execution state, and remove VMs when the work is complete. The same interface also exposes the underlying CLI and HTTP API for advanced workflows.

Yes. flash-mcp maps each operation to either the flash CLI or HTTP over the VM's Unix socket. Agents and human operators use the same lifecycle, resource, and observability paths, so automation behaves consistently with established operator workflows.

Yes. Through flash_cli, an agent can launch a VM with an explicit bundle, workload entry point, CPU template, CPU and memory allocation, disk capacity, disk I/O policy, and network policy. flashnet can establish bridge, NAT, or routed networking while the VMM itself remains unprivileged.

Yes. flash_watch streams metrics, workload logs, guest console output, lifecycle events, or guest messages through Server-Sent Events. Progress is delivered as it happens, giving the calling agent live operational context instead of a series of disconnected polling results.

Yes. flash_ls provides host inventory, while flash_watch_fleet follows multiple VMs concurrently and prefixes every result with its VM identity. Each FlashVM retains its own process, socket, limits, and telemetry stream, so fleet automation can act on individual workloads without funneling control through a central daemon.

Yes. An agent can capture the running state through the snapshot API, restore the original VM through flash_cli, or clone the snapshot into a new identity. Starting the source VM with a CPU template gives the restored workload an explicit CPU compatibility contract wherever it resumes.

Yes. A warm-pool spare is already booted and waiting for work. An agent can claim it, assign the workload entry point and resource policy, and begin execution without putting a cold boot on the request path. This makes warm pools a natural fit for latency-sensitive agent workloads and bursty task queues.

Yes. Both use the same per-VM control socket and see the same state. A human can inspect an agent-created VM with the CLI, while an agent can continue from a VM created by an operator. That shared model makes handoffs straightforward and keeps operational behavior predictable.

Access follows standard Linux ownership and file permissions on each VM's Unix socket. This lets teams apply familiar user, group, service-account, and process-isolation policies without introducing a separate credential system inside the VMM.

Each FlashVM runs in its own process and owns its own Unix socket, resource policy, and telemetry stream. There is no central VMM daemon in the execution path. Fleet controllers can place, observe, update, snapshot, move, and remove VMs independently through the CLI, API, or MCP interface.

The scheduler places VMs against available host capacity, while FlashVMM enforces the allocation assigned to each workload. CPU, memory, disk capacity, disk throughput, disk IOPS, and network policies remain scoped to the individual VM, giving the orchestration layer a clear and enforceable resource contract.

Resource controls are independent rather than bundled into a single coarse quota. CPU time is enforced by a signal-driven pacer, disk growth uses host-side admission control, disk I/O uses token buckets, and every NIC has separate egress bandwidth, egress packet-rate, and ingress bandwidth policies.

FlashVMM does not depend on the guest yielding voluntarily. A background pacer forces regular exits from guest execution, measures per-thread CPU time, and delays vCPU threads that have consumed their assigned budget. The policy stays effective even for continuously busy workloads.

Disk capacity is reserved before writes are admitted, so the host enforces the VM's allocation independently of guest accounting. Separate throughput and IOPS token buckets shape the virtio block path. Operators can inspect current usage and policy through the same per-VM control API.

Each NIC combines bandwidth and packet-rate enforcement. Egress traffic must satisfy both its byte and packet budgets, while ingress shaping applies backpressure through the host tap queue. Policies can be updated while the VM remains online.

Every VM receives a fixed memory ceiling at placement, giving the scheduler a stable capacity commitment. Virtio ballooning provides live reclamation within that ceiling; a virtio-mem region lets the host resize a tenant's live footprint on demand within its own declared bound, so density decisions are the host's to make and enforce, not the guest's to cooperate with. Copy-on-write cloning lets related workloads share unchanged snapshot pages instead of allocating a private copy for every replica.

Warm-pool spares boot ahead of demand and wait at zero workload CPU. A claim assigns the workload, identity, disk capacity, and CPU policy to an already-running VM. Fleet controllers can maintain the pool depth they need and absorb bursts without turning every request into a cold start.

FlashVMM composes migration from capture, transfer, and restore. The destination resumes the captured execution state rather than restarting the application, and CPU templates define the feature contract the destination must satisfy. Because each step is exposed through the standard control surface, operators can integrate migration directly into maintenance and placement workflows.

Metrics, logs, lifecycle events, and guest messages stream from every VM over SSE. Consumers receive explicit continuity signals and can persist the streams in their existing observability stack. flash_watch_fleet provides a ready-made concurrent view with every event labeled by VM identity.

VM execution and control remain local to each flashvmm process. A controller can restart, move, or upgrade independently of running workloads, and each VM continues to operate within its own process boundary rather than depending on a host-wide VMM daemon.

FlashVMM leads the published cold-start comparison on every measured platform, with 5.4× to 29.2× faster startup across x86_64, aarch64, bare metal, and nested virtualization. It also delivers low-single-digit millisecond snapshot restore across x86 environments and reaches 1.36 ms on AWS Graviton3. See Performance for the complete comparison.

A microVM keeps the hardware isolation and private guest kernel of a virtual machine while removing legacy device emulation that modern workloads do not need. FlashVM is FlashVMM's high-performance implementation of that model, built for millisecond startup and a small resource footprint.

Containers share the host kernel. A FlashVM runs its own guest kernel behind KVM, inside a dedicated process and address space. That gives each workload a VM boundary while preserving the speed and operational simplicity expected from modern application infrastructure.

Yes. Any Linux x86_64 or aarch64 host with KVM can run FlashVMM, including compact home servers and virtual machines with nested virtualization enabled. It installs as a standalone distribution and is managed directly through the flash CLI.

Yes. FlashVMM supports 64-bit ARM systems with KVM and runs on Raspberry Pi 5, including snapshot and restore. It also supports AWS Graviton systems, giving the same FlashVM model a path from compact edge hardware to cloud-scale ARM infrastructure.

No specific server brand or accelerator is required. FlashVMM uses KVM on standard Linux hosts and supports x86_64 and aarch64, bare metal, selected nested-virtualization environments, home servers, and Raspberry Pi 5.

If you are comfortable using a terminal, you can work with FlashVMM. The CLI handles VM creation, inspection, networking, snapshots, restore, cloning, and cleanup. Kernel or hypervisor development experience is not required.

FlashVMM combines fast cold starts, instant warm-pool claims, copy-on-write cloning, cross-host workload movement, per-VM resource enforcement, streaming observability, and an MCP-native control plane. It delivers these capabilities in a standalone architecture with one process and one control socket per VM.

Yes. FlashVMM provides fast, isolated Linux environments without requiring a hosted control plane or dashboard. It is especially well suited to developers and operators who want direct CLI control, scriptable automation, predictable resource policies, and snapshots they can move between machines.

Start with installation and the first-run workflow on the Developer page. From there, explore warm pools, snapshots, cloning, migration, and LLM-native operations using the same standalone installation.