Snapshots

Save a running machine, GPU memory included, and pick up exactly where it left off, with savevm or migration to a file.

A snapshot is the whole running machine: every core, every device, the RAM, the display's GPU memory and the shared folders' files. Restoring it continues exactly where it stopped.

Two kinds, as in QEMU:

savevm and loadvm

(wemu) savevm before-upgrade
(wemu) info snapshots
(wemu) loadvm before-upgrade
(wemu) delvm before-upgrade

From code, through the monitor or QMP's snapshot jobs:

await vm.hmp("savevm before-upgrade");
await vm.qmp("snapshot-load", { "job-id": "load1", tag: "before-upgrade" });

Where snapshots are kept

The host's snapshot store decides. By default it's memory, for as long as the machine exists.

• In Node: keep them as files with nodeWEMUHost({ snapshotDir: "./snapshots" }), and start a new machine from one with -loadvm TAG.
• In a browser: give the host a snapshots store backed by IndexedDB or OPFS.

Saving to a file

await vm.qmp("migrate", { uri: "file:state.bin" });

Then start a machine with the same command line plus -incoming:

wemu-system-aarch64 <same options> -incoming file:state.bin

Or start it with -incoming defer and load the state when you're ready with migrate-incoming.

What's included

• Every core, the interrupt controller, the timers and every device's state.
• RAM, compressed: blocks the guest never wrote are skipped.
• Disks held in memory (with snapshot=on, or in the stock browser host).
• The shared folders' files.
• With a display: the GPU's memory, every texture and buffer, and the screen.

Not included: disks opened in place. Their bytes are already in their files. Restore on a machine that opened the same disk files, unchanged since the snapshot.

Size and speed

Measured on an Apple M3:

See also

• QMP: snapshots and migration
• The monitor