Platforms and engines

FlashVMM platforms are the native hypervisors it runs on: KVM on Linux x86_64 and arm64, Hypervisor.framework and Virtualization.framework on Apple silicon Macs, and the Windows Hypervisor Platform (WHP) on Windows x64 and arm64, each serving the same /v1/flashvm contract with virtio devices.

Every platform has its own flashvm built for that hypervisor and its own tuned guest kernel, and all of them run the latest Linux kernel with a slim BusyBox and musl root filesystem. A program written against the flash CLI, flash-mcp or the REST API runs unchanged on all five OS and architecture combinations.

Key facts

How it works

Each OS uses its native hypervisor and the same contract on top of it.

Linux: KVM

flashvm opens /dev/kvm, maps guest RAM as KVM memory slots and runs one thread per vCPU. On x86_64 guest RAM splits around a 32-bit device window at 3328 MiB and resumes at 4 GiB; on arm64 it is one region. Snapshots, diff snapshots, live fork, checkpoints and demand-paged restore through userfaultfd all run here, with KVM dirty-page logging plus host-write tracking. Networking is the flashnet helper with bridge, NAT and routed modes, plus NIC pools from flashnetd.

macOS: Hypervisor.framework and Virtualization.framework

The hvf engine is FlashVMM's own VMM on Hypervisor.framework: every resource cap, snapshots, live fork, dirty tracking, warm pools and remote restore. The vz engine runs on Virtualization.framework for Rosetta, which runs x86_64 Linux binaries in the arm64 guest, and for virtio-fs folder shares, with NIC caps enforced. Choose with flash run --engine. Networking is built-in user-mode NAT.

Windows: Windows Hypervisor Platform

flashvm drives one WHP partition per VM on x64 and arm64, serves the API over a named pipe, and supports snapshots, restore, live fork and warm pools. Networking is built-in user-mode NAT.

Fresh randomness after restore

The host supplies entropy and the guest agent applies it. On Linux, a restored, cloned or forked guest receives a reseed frame carrying bytes from the host's /dev/urandom drawn at resume, and reseeds its kernel CRNG. On Windows the same reseed frame is queued before the vCPU first runs, carrying fresh host CSPRNG bytes; at boot x86 guests receive 64 host CSPRNG bytes and arm64 guests read virtio-rng. On macOS the hvf engine's virtio-rng device is backed by the host OS entropy source.

Interfaces

CLI

flash run --bundle ./bundle --id x86tools --vcpus 2 --mem-mib 1024 --engine vz --entry 'sleep 3600' --detach
flash version x86tools
flash inspect x86tools

MCP

flash_cli(args: ["run", "--bundle", "./bundle", "--id", "x86tools", "--vcpus", "2", "--mem-mib", "1024", "--engine", "vz", "--entry", "sleep 3600", "--detach"])
flash_resource(vm_id: "x86tools", resource: "version")

REST

PUT /v1/flashvm  {"source": {"type": "bundle", "bundle_dir": "./bundle"}, "vcpus": 2, "mem_mib": 1024, "engine": "vz", "entry": "sleep 3600"}
GET /v1/flashvm/version

Contract: an engine the host does not have returns 422 unsupported_engine; a cap the chosen engine cannot enforce returns 422 cap_not_enforceable, so a requested limit is always either applied or refused.

Guarantees

• Native hypervisors. Every VM runs on the platform's own hardware virtualization interface.
• One contract everywhere. The same bodies, defaults and error codes on Linux, macOS and Windows.
• Caps are honest. A limit is enforced or refused with a typed error, never silently dropped.
• Unique randomness per copy. Every restored or forked guest is reseeded with host entropy.