From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 864C01FF0E4 for ; Tue, 14 Jul 2026 15:24:32 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id E4A69213E9; Tue, 14 Jul 2026 15:24:31 +0200 (CEST) Message-ID: <7d51cde8-6d16-49d4-8f07-60cb67a09cf9@proxmox.com> Date: Tue, 14 Jul 2026 15:23:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 0/4] lxc: add safe OCI rootfs replacement To: copystring , pve-devel@lists.proxmox.com References: <20260706194059.280257-1-copystring@gmail.com> Content-Language: en-US From: Filip Schauer In-Reply-To: <20260706194059.280257-1-copystring@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1784035421536 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.025 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes RCVD_IN_DNSWL_LOW -0.7 Sender listed at https://www.dnswl.org/, low trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: HSEA3F2NWSBWV46RZYX5P2PIAXY5VBSM X-Message-ID-Hash: HSEA3F2NWSBWV46RZYX5P2PIAXY5VBSM X-MailFrom: f.schauer@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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