Skip to content

Implement transactional snapshot capture and private restore #4438

Description

Tracking issue: MicroVM support and private snapshot restore.

Motivation

Reusing a prepared microVM requires a snapshot that is either complete and
restorable or clearly unpublished. The manifest, immutable RAM image, and VM state
must describe the same boundary, and each restored instance must have private
memory. Defining a format without a working transaction would leave these central
correctness properties untested.

Proposed Scope

  • Define a versioned, bounded manifest with explicit state compatibility, memory
    layout, and file-reference validation.
  • Capture the base profile at a defined post-OUT boundary, accounting for
    completion of the intercepted guest I/O and the corresponding VP state.
  • Publish immutable RAM and its manifest transactionally using the host-file
    primitives; incomplete staging output must not appear to be a valid snapshot.
  • Restore the base profile using private copy-on-write guest memory and the saved
    CPU/clock contract.
  • Integrate bounded Linux descriptor-table preparation where appropriate without
    hiding failures or changing snapshot semantics.
  • Clean up staging files, mappings, and temporary I/O-boundary preparation after
    failed or cancelled capture/restore operations.
  • Keep manifest, publication, and a working base capture/restore path in one PR.

Acceptance Criteria

  • A source-built guest captures at the post-OUT boundary and resumes with the
    documented instruction and I/O completion semantics, without duplicate effects.
  • Multiple private restores begin with the captured RAM and diverge on writes
    without modifying the snapshot or one another.
  • Oversized or malformed manifests, invalid memory ranges, missing or truncated
    RAM files, and incompatible state are rejected without panics.
  • Failure injection during capture, publication, and restore leaves no
    apparently complete artifact that refers to incomplete state.
  • Failure at the guest I/O boundary tears down temporary hooks and resources;
    retry and VM teardown do not hang or retain stale preparation.
  • Applicable KVM and WHP VMM tests cover the combined base transaction through
    cargo xflowey vmm-tests-run.
  • Format limits, publication guarantees, supported filesystems, compatibility,
    and failure outcomes are documented.

Dependencies

Non-Goals

This issue establishes the base-profile transaction. General virtio persistence,
live network/filesystem attachment reconstruction, snapshot tiers, and performance
optimizations are separate work; unsupported devices must be rejected explicitly.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions