Skip to content

[blaze] refactor: backend-agnostic checkpoint payload layout #2676

Description

@WeissonHan

Why

The checkpoint on-disk contract freezes one backend shape into the daemon:
capture hands every backend exactly two named VM files (vmstate.snap,
memory.snap), and both the store and the restore path validate committed
checkpoints against a fixed three-file whitelist. Backends whose native
checkpoint is a directory tree cannot express their payload in this contract
at all — runsc checkpoint writes an image directory plus the OCI spec that
restore must revalidate byte-for-byte. The same whitelist is what blocks
sandbox hibernation (#2464) and any future non-VM backend from reusing the
existing capture and restore transactions.

The capture orchestration also unconditionally pauses the backend before
snapshot and resumes it afterwards. Backends whose capture primitive freezes
the workload itself reject exactly that sequence.

What should change

  • Hand each payload producer an owned subtree (backend/ for the backend
    adapter, storage/ for the rootfs capture) instead of fixed file names.
  • Replace whitelist validation with a manifest-driven inventory: walk, hash,
    and record every captured file under its relative path; fail closed on any
    mismatch, symlink, or unregistered file.
  • Move the checkpoint metadata format to version 2; keep version-1 checkpoints
    restorable read-only.
  • Route capture quiescing through overridable backend hooks that default to
    pause/resume.

Scope

src/blaze only. The Firecracker adapter migration follows once #2473 lands.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions