Reference

Glossary

Every FlashVMM term, defined once.

The FlashVMM glossary defines every term used across the FlashVMM CLI, MCP server, REST APIs and this site exactly once, each with a link to the page that explains it in depth.

FlashVM: One virtual machine run by FlashVMM: a Linux guest booted from a bundle, served by its own flashvm process at its own API address. See Architecture.
FlashVMM: The product: the virtual machine monitor, the flash CLI, flash-mcp and the host daemons, on Linux, macOS and Windows. See Architecture.
flashvm: The VMM process: one flashvm serves one FlashVM and exposes its per-VM REST API under /v1/flashvm on a Unix socket (Linux, macOS) or named pipe (Windows). See API contract.
flash: The command-line interface; every command is a REST call to a VM's own address or to a host daemon. See API contract.
flash-mcp: The Model Context Protocol server: a stdio JSON-RPC process whose 21 tools mirror the flash CLI and the REST resources. See MCP server design.
MCP tool: One of flash-mcp's 21 named operations, such as flash_exec, flash_cli or flash_pool, each with a JSON input schema and a structured reply. See MCP.
resource CRUD: The API style of every FlashVMM interface: nouns in paths and HTTP methods as the verbs (PATCH /v1/flashvm to pause, DELETE to stop), with no verbs in paths. See API contract.
bundle: A directory holding a guest kernel and root filesystem that flash run --bundle boots; flash bundle reads what it declares, and self-update installs new ones beside the old. See Bundles.
guest agent: The program inside every FlashVM that runs commands and file transfers for the host over the VM's virtio-console in length-prefixed frames. See Guest.
KVM: The Linux kernel's hypervisor interface, FlashVMM's engine on Linux x86_64 and arm64 (--engine kvm). See Platforms.
Hypervisor.framework: Apple's low-level hypervisor API and FlashVMM's default macOS engine (--engine hvf), with every cap, snapshots, fork and warm pools. See Platforms.
Virtualization.framework: Apple's high-level VM framework, FlashVMM's second macOS engine (--engine vz), adding Rosetta for x86_64 Linux binaries and virtio-fs shares. See Platforms.
WHP: Windows Hypervisor Platform, FlashVMM's engine on Windows x64 and arm64 (--engine whp). See Platforms.
warm pool: A set of booted, parked FlashVMs of one shape kept at a target count by flashpoold under /v1/vm-pools, ready to be claimed. See Pools.
spare: One idle VM in a warm pool, booted with flash run --pool and waiting for its workload. See Warm pools.
claim: Handing a spare its real workload with PUT /v1/flashvm/workload (flash claim): a program to run, or a snapshot to become; it returns once accepted. See Pools.
NIC pool: A set of ready network interfaces served by flashnetd on Linux, attached with --nic pool=ID to new, forked or woken VMs. See NIC pools.
GPU pool: One model loaded by flashgpud on the host GPU (Metal on macOS, Vulkan on Linux and Windows) and shared by many VMs, which call its chat-completions endpoint over their NIC at FLASH_GPU_URL. See GPU pools.
snapshot: A file capturing a running VM's memory and device state, written by flash snapshot --path (POST /v1/flashvm/snapshots) to a path the caller names. See Snapshots.
diff snapshot: A snapshot holding only the pages written since its base, made by a VM restored with --diff-base or by fork captures. See Snapshots.
base: The full snapshot a diff snapshot is relative to; it stays in place for the life of every diff that names it. See Snapshots.
rebase: A fork capture written self-contained that becomes the new base of a VM's later fork captures, so a large change is stored once (rebase: true on POST /v1/flashvm/snapshots). See Fork and checkpoints.
restore: Rebuilding a VM from a snapshot file (--from) or from a signed URL (--from-url) whose memory faults in as the guest touches pages, on Linux and macOS. See Snapshots.
clone: Building a new, separate VM from a snapshot while the VM it was captured from carries on (flash clone). See Snapshots.
sleep: Saving a running VM's memory and devices to a file and ending its process so it uses no memory or CPU while keeping its name (flash sleep); hosts list sleeping VMs at /v1/host/sleep-images. See Sleep.
wake: Resuming a sleeping VM under the same name from the instant it slept (flash wake, with --nic for a VM that had one). See Sleep.
pause: Freezing a VM's vCPUs in place for a bounded time (flash pause, PATCH /v1/flashvm) until flash resume. See Pause.
fork: Branching a running VM into N children that continue from its state at that instant, each with its own identity, while the parent keeps running (flash fork --count N). See Fork and checkpoints.
checkpoint: A numbered capture of a VM's memory, disk and devices kept under the VM (flash checkpoint, or one before each command with flash exec --checkpoint; newest 20 kept by default). See Checkpoints.
rewind: Putting a VM back to checkpoint N under the same name, with its memory, disk and processes as they were; later checkpoints are kept, so a rewind can itself be undone (flash rewind VM N). See Checkpoints.
branch: Starting new VMs from a checkpoint (flash fork VM --from N, or POST /v1/host/flashvms {from: {flashvm, checkpoint}}). See Fork and checkpoints.
egress policy: The per-NIC rule for what a VM may reach (all by default, public, none, or allow: and deny: lists), set with --egress and changed live with flash set. See Egress.
connection log: The record of every outbound connection and DNS question a VM made on a NIC, allowed and refused, with the reason (flash connections). See Egress.
secret proxy: A host-side relay that adds a credential to a guest's API calls so the guest uses it without holding it; the guest calls FLASH_PROXY_<NAME>_URL, with optional call and byte caps (--secret-proxy). See Secret relay.
flashhostd: The host daemon that counts every VM on a machine against its capacity, applies host policy and admission, and serves metering under /v1/host. See Host.
admission: flashhostd's fit check before a VM starts: a reservation at POST /v1/host/admissions, reported or enforced by the host policy's admission: report|enforce, answering 409 host_full when enforced and full. See Host.
metering: Per-VM usage kept per UTC hour (CPU seconds, memory MiB-seconds, disk and network bytes, running and sleeping seconds) at GET /v1/host/usage. See Host.
flash controller: The fleet role of flash (flash controller serve) that places VMs across many hosts by best fit and moves them between hosts. See Controller.
live migration: Moving a VM to another host of the same platform: the controller's POST /v1/moves sleeps it, copies its sleep image and wakes it on the target. See Live migration.
run-length limit: A cap that stops a VM by itself after max_wall_s seconds of life or max_cpu_s CPU seconds, served at /v1/flashvm/limits (--max-wall-s, --max-cpu-s; 0 = none). See Run limits.
CPU template: The CPU model shown to the guest (--cpu-template, such as host-raw or a named one), chosen before a VM is snapshotted so a restore can check the target silicon runs it. See Snapshots.
balloon: The virtio-balloon device through which the host asks the guest to hand pages back (flash balloon, /v1/flashvm/memory/balloon). See Memory.
virtio-mem: The virtio memory device that grows or shrinks a VM's memory region to a live target (flash mem, /v1/flashvm/memory/mem). See Memory.

Glossary

Related