Re: [RFC PATCH 0/4] lxc: add safe OCI rootfs replacement

[Filip Schauer <f.schauer@proxmox.com>]

On 09/07/2026 10:21, copystring wrote:
> This RFC adds an explicit rootfs replacement path for stopped LXC containers
> created from OCI images. The intent is to support the common "refresh the OCI
> image" workflow without pretending that data stored inside the old rootfs can be
> merged safely.
>
> The safety model is intentionally conservative:
>
> * require an explicit confirmation parameter;
> * only operate on stopped, non-template, non-HA, unprotected CTs without
>    snapshots or pending config changes;
> * only replace the active rootfs volume, while preserving mpX mount points;
> * keep the previous rootfs as an unusedX volume instead of deleting it;
> * fail if no unusedX slot is available;
> * never remove the newly allocated rootfs once config writing has started;
> * do not use overlayfs or path heuristics such as /config or /data detection;
> * reject shrink-like requests by requiring the target size to be at least the
>    current rootfs size.
>
> This means data that only exists on / becomes data on the old unused volume, not
> on the new active rootfs. Users are expected to keep persistent application data
> on separate mount points or to have a backup before replacing the rootfs.
>
> By default, the endpoint also updates OCI-derived runtime config such as
> entrypoint, environment, ostype, arch and OCI-generated lxc keys. A caller can
> set update-oci-config=0 to preserve the existing runtime config and only switch
> the rootfs.

Thanks for putting this together.

For context: I am working on improving the current OCI container tech
preview by adding OverlayFS-based storage, so that image layers are
stored once (content-addressed & deduplicated) and mounted as read-only
lower layers under a thin writable upper layer, rather than being
squashed into a single rootfs volume per container.
I just posted my proposal as a separate RFC:
https://lore.proxmox.com/pve-devel/5709a436-fb72-4fa5-8bdc-702c3e96a5a7@proxmox.com/

Your series creates a clean new rootfs volume and extracts a fresh copy
of an image. This makes sense given that local changes cannot be safely
merged.

In the OverlayFS model, the equivalent would be to allocate a fresh
empty `overlay` volume (just the upperdir and workdir) and point it at a
new image digest as its `ocibase`. That would be cheap since no layers
need re-extracting.

Looking at your patch series, it seems like your replacement API could
be a good approach for migrating existing squashed-rootfs containers to
the new OverlayFS model aswell. If a user wants to update an existing
OCI container, they could use this API. Under the hood, instead of
extracting the OCI image into a new squashed volume, we would allocate a
new `overlay` volume and set its `ocibase`.

Because of this overlap, it would be great to align our efforts. Once
the OverlayFS implementation takes shape, your series could be
adapted/extended to generate the `overlay` volumes instead.

Thanks,
Filip