snapshots silently drop attached user volumes #1

Open
opened 2026-04-09 04:28:22 +00:00 by harivansh-afk · 0 comments

CreateMachine supports attached user volumes and passes them into the runtime as extra drives, but the snapshot/restore path only persists and restores the system disk.

What happens today:

  • buildMachineSpec includes attached user volumes as additional DriveSpecs (internal/daemon/create.go:169-187).
  • CreateSnapshot only COW-copies the system disk and appends a single system.img entry to SnapshotRecord.DiskPaths (internal/daemon/snapshot.go:86-100).
  • RestoreSnapshot treats snap.DiskPaths[0] as the new system disk, hard-codes loadSpec.DiskPaths to an empty map, and creates the restored MachineRecord without any UserVolumeIDs (internal/daemon/snapshot.go:214-230, internal/daemon/snapshot.go:269-284).

Impact:

  • Snapshots of machines with attached user volumes are incomplete.
  • Restored machines silently lose their attached user disks.
  • The control-plane record for the restored machine no longer reflects the original volume topology.

Expected behavior:

  • Either snapshot and restore all attached user volumes, including drive-id mapping and persisted UserVolumeIDs, or reject snapshot requests for machines that have attached user volumes until that support exists.

Suggested follow-up:

  • Extend SnapshotRecord to persist system vs user disk metadata.
  • Populate SnapshotLoadSpec.DiskPaths during restore.
  • Persist restored UserVolumeIDs on the new machine record.
  • Add an integration test covering snapshot/restore of a machine created with UserVolumeIDs.
`CreateMachine` supports attached user volumes and passes them into the runtime as extra drives, but the snapshot/restore path only persists and restores the system disk. What happens today: - `buildMachineSpec` includes attached user volumes as additional `DriveSpec`s (`internal/daemon/create.go:169-187`). - `CreateSnapshot` only COW-copies the system disk and appends a single `system.img` entry to `SnapshotRecord.DiskPaths` (`internal/daemon/snapshot.go:86-100`). - `RestoreSnapshot` treats `snap.DiskPaths[0]` as the new system disk, hard-codes `loadSpec.DiskPaths` to an empty map, and creates the restored `MachineRecord` without any `UserVolumeIDs` (`internal/daemon/snapshot.go:214-230`, `internal/daemon/snapshot.go:269-284`). Impact: - Snapshots of machines with attached user volumes are incomplete. - Restored machines silently lose their attached user disks. - The control-plane record for the restored machine no longer reflects the original volume topology. Expected behavior: - Either snapshot and restore all attached user volumes, including drive-id mapping and persisted `UserVolumeIDs`, or reject snapshot requests for machines that have attached user volumes until that support exists. Suggested follow-up: - Extend `SnapshotRecord` to persist system vs user disk metadata. - Populate `SnapshotLoadSpec.DiskPaths` during restore. - Persist restored `UserVolumeIDs` on the new machine record. - Add an integration test covering snapshot/restore of a machine created with `UserVolumeIDs`.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: getcompanion-ai/computer-host#1
No description provided.