Benjamin Elder 9bc9f7ac92 ateom-microvm: mount durable-dir volumes over a writable virtio-fs share ...

DurableDir volumes shipped for gVisor only; the micro-VM runtime dropped
Container.durable_dir_volumes on the floor and the API rejected the
combination outright. Give the guest the volume:

  - cmd/ateom-microvm/internal/tarutil: archive/restore a directory tree
    preserving modes, ownership, times, symlinks and hardlinks, with
    os.Root-confined extraction. Snapshot support (a later commit) ships the
    volume as a tar; no reusable helper existed, and atelet's image untar does
    not preserve ownership.
  - A SECOND virtiofsd serves the actor's durable-dir directory read-write
    with cache=auto. The kataShared share stays read-only at cache=always,
    which is what its TODO asked for: writable volumes get their own share
    rather than weakening the overlay lower's caching.
  - The guest mounts the new tag at /run/ateom-durable and each WORKLOAD
    container binds <tag>/<volume> at its declared paths. The carrier is
    deliberately left alone: its rootfs is the read-only lower, where the
    agent could not create a missing mount point.
  - Lift the CEL rule banning durableDir on sandboxClass microvm.

ateom learns the volume name from the directory layout atelet prepares: the
wire protocol carries mount paths only, and the API allows at most one
durable-dir volume, so anything but exactly one directory is an error.

Snapshot scopes are unchanged so far, so the contents live only as long as
the actor. Checkpoint and restore follow.

2026-07-24 18:59:35 -07:00

..

v1alpha1

ateom-microvm: mount durable-dir volumes over a writable virtio-fs share

2026-07-24 18:59:35 -07:00