Firecracker snapshotは状態を持つsandbox再開に向く
FirecrackerはmicroVMを軽量に実行するVMMであり、snapshot機能を使うとrunning microVMのmemoryとVMM stateを保存して後から再開できる。
Firecrackerのsnapshotは主に次の要素から構成される。
- guest memory file
- microVM state file
- block device files（これは利用者側で管理する）
restore時にはmemory fileを MAP_PRIVATE でmappingし、pageを必要になった時点で読み込む。書き込みはcopy-on-writeになる。このため、同じmemory snapshotやread-only diskを複数microVMから共有する設計が可能で、pre-initializedな実行環境を多数cloneする用途と相性がよい。
例えば、OS起動、toolchain導入、依存取得などの高コストな初期化を済ませた状態をsnapshotし、そこから複数の実行環境を起動する構成が考えられる。
一方で、snapshotは「VMの全状態を1ファイルに完全保存する魔法」ではない。
Firecrackerのdocumentationでは、block device filesは利用者が別途管理する必要がある。またsnapshot file自体はFirecrackerのthreat containment model上でtrustedとされ、移送・保管する場合のauthenticationやencryption、lifecycle管理は利用者側の責任になる。
さらに、snapshotから別Firecracker processへrestoreした場合、network connectionのstateが維持される保証はない。vsock connectionもsnapshot/resumeでresetされる。したがって、長時間動くprocessをsnapshotする場合には、外部connectionが再接続可能であることを前提に設計した方がよい。
FirecrackerはVM境界とsnapshotの自由度が魅力だが、OCI runtimeとして高レベルに統合された Kata Containers 4.0はOCI UXのままVM境界を使う より、rootfs、block device、network、vsock、snapshot lifecycleなどのcontrol planeを自分で設計する範囲が広い。
sandboxの隔離境界全体は Linuxサンドボックスの隔離境界をどう捉えるか を参照。