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

["Felix Göhringer" <copystring@gmail.com>]

Hi Filip,

Any updates on the OverlayFS integration and how we should proceed
with the OCI rootfs replacement series?

Is there anything you need from my side to move this forward? Would it
make sense to continue reviewing the replacement functionality for
existing squashed-rootfs containers independently, or would you prefer
the next revision to align with the OverlayFS work?

Thanks!


On Tue, 14 Jul 2026 15:23:57 +0200, Filip Schauer <f.schauer@proxmox.com> wrote:
> 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