FAQ

flash-mcp gives MCP-compatible agents direct access to the complete FlashVM lifecycle. An agent can create and inspect VMs, run commands inside them and copy files in and out (flash_exec, flash_cp), fork a running VM into copies, 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 own endpoint — a Unix socket on Linux and macOS, a named pipe on Windows. The same twenty tools, with the same parameters, ship on every platform. 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 launches a VM with a bundle, its shape (--vcpus and --mem-mib, both required), a workload entry point, and a CPU template. Every limit — CPU, disk capacity, disk I/O, and per-NIC bandwidth and packet rate — is optional: pass it and it is enforced, omit it and that resource is uncapped. Nothing picks a limit on the agent's behalf, and a limit the platform cannot enforce is refused rather than silently dropped. On Linux, flashnet establishes bridge, NAT, or routed networking while the VMM itself stays 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.

With flash_exec (or flash exec --json): pass the VM and an argv, get back exit_code, stdout, stderr, state and how long it took. There is no network or SSH involved — the command rides a dedicated virtio-console port to the guest agent. Timeouts kill the whole process tree, output is kept up to 16 MiB per stream, and up to 64 commands can run at once. flash_cp moves files and directory trees in and out; flash del removes them.

Yes. --egress public lets an agent browse the whole internet but reach nothing private — not your LAN, not the host, not cloud metadata — and deny: adds a blocklist. --egress none lets nothing out but link setup; --egress allow:pypi.org,*.github.com,10.0.0.0/8 lets the VM reach those names (at the addresses its own DNS lookups returned) and CIDRs, and nothing else — a lookup of any other name is answered "refused" before it leaves the host. It is enforced by FlashVMM's network path outside the guest on every OS, survives snapshot/restore and fork, can be changed on a running VM with flash set --egress, and flash connections (MCP: flash_connections) lists every connection and DNS question the VM made, allowed or refused.

Give the VM --secret-proxy model=KEYFILE,upstream=https://.... The agent calls $FLASH_PROXY_MODEL_URL in plain HTTP; FlashVMM, outside the VM, adds the key, forwards over TLS, streams the reply and logs the call (flash proxies). The key never enters the guest, and with --egress none the model is the only thing the agent can reach. Caps (max-calls, max-bytes) answer 429 inside the VM.

Yes. flash fork VM --count N (through flash_cli) starts N children that continue from the parent's state at that instant — same memory, same running program — each with its own identity, while the parent keeps running. A parent started with --forkable forks with its RAM frozen in place, and later forks are diffs: 15 ms on Linux x86_64. It is how an agent tries several approaches from one prepared state.

Yes. A warm-pool spare is already booted and waiting for work. An agent can claim it, assign the workload entry point and — only if it wants one — a CPU or disk cap, 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 — restore-via-claim. Instead of an entry point, flash_cli(["claim", ...]) (or flash_api's POST /v1/flashvm/claim) can hand a warm-pool spare a snapshot to become. The spare's own already-running process is reused, so the restore pays neither the cold boot's kernel-init time nor a fresh process's spawn and privilege-drop cost. Available on arm64 hosts today; see LLM-native operations for the exact tool call.

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 the operating system's own permissions on each VM's endpoint: file ownership and permissions on the Unix socket on Linux and macOS, and the named pipe on Windows. Teams apply familiar user, group, service-account, and process-isolation policies without 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 exactly the caps the scheduler passes for each workload — and applies none it did not pass. 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, and any CPU or disk cap the controller passes 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. A claim can also carry a snapshot instead of a workload entry point — restore-via-claim — reusing the spare's own process so a restore skips the fresh-process spawn cost too, on arm64 hosts.

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. Restoring onto a warm-pool spare instead of a fresh process is the same restore, applied without the spawn cost.

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.

A full VM with its own kernel boots in 18 ms on macOS and 42 ms on Linux x86. A warm VM is claimed from a pool in 1.2 to 2 ms, a snapshot restores in as little as 7.8 ms, a sleeping VM wakes in 8.4 ms, and 50 VMs come up together in 125 ms. See Performance for every platform.

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 hardware virtualization, 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 arm64 host with KVM, an Apple Silicon Mac, or a Windows x64 or ARM64 PC with the Windows Hypervisor Platform 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. The same arm64 build runs on ARM64 servers, giving one FlashVM model a path from compact edge hardware to large ARM infrastructure.

No specific server brand or accelerator is required. FlashVMM runs on macOS (Apple Silicon), Linux (x86_64 and arm64 with KVM — bare metal, nested virtualization, home servers, Raspberry Pi 5), and Windows (x64 and ARM64 with the Windows Hypervisor Platform).

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 guest environments on a Mac, a Linux box, or a Windows PC, 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.