From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 0EE8A1FF09B for ; Mon, 28 Sep 2026 09:15:17 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 20EEC2171D; Mon, 28 Sep 2026 09:14:58 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; t=1790275193; cv=none; d=google.com; s=arc-20260327; b=fa/ESR/fj2NoMzRDxx7kOWUmNwp6gpIaen7vgEiwftUZ43MUz1Q1TjYCVNVQl04P7h LTbLj5HLIB1LpgJb6BBO+kftE1TV3RTR0kog0/dcXdQamqFqcpFq3gK6aISH+5OxdIXi a6voEXyYibHapXYr1crl3gDovxEM9AB+SPPRM26nb4pGr4W1dT5THbHHidv735bhmk6y WvtiSiPT27/cgvTp6C+oZ4pWt5tyzKyhK+V2BMQQuAFYSlwzCtIpk2Q3xd6RHf3J4w9S 2XK49QA1GAETbcAeMSf5YF437cnt6QMGs8QtqqhWSCduPdpYNYAUvD4vjkiPg9C17svF j8mw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:dkim-signature; bh=jYBCExllpZjuV9VV1zLjY0X5zeX8IfnjDk3OiaM07WQ=; fh=Yn2FgLkrE4Wky7I1X01KFJzJaoryZy7FAEYxSZbOvT0=; b=MvCqW9G8yHW8ZcJOV+hUzXHXcr8VtyBaWsR6Bnv/zcHdG9od4F75AQ9iAg8haw0hwl FxvqwrmkEOvfHUaFodvqnU1TPpL/UysxHjIIirdDNR2S/teI/mhX47hv1FQrlv6K0dtu 6elFVTsEiHCI4a1JNfwCEh4DvESvBoPg9oRGNWsGqzY+r2rUQBQ2dnz2+Nerg3SUJEPj aM3ZWbchH9gsIai9js4AjpAgumO62ZC5xC+7a/EIzkFmrC+zeYeKwNNsSIrr6mN40GEI DXRG8YiM53uMWp9r3srlQymh5e7EJqhe1MBd84s7wa3DS4VQvnCCqPpLp8YqKIgVR1pt gelg==; darn=lists.proxmox.com ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790275193; x=1790879993; darn=lists.proxmox.com; h=content-type:cc:to:subject:message-id:date:from:references :in-reply-to:mime-version:from:to:cc:subject:date:message-id :reply-to:content-type; bh=jYBCExllpZjuV9VV1zLjY0X5zeX8IfnjDk3OiaM07WQ=; b=Gy06vAccaMyCcuhszbw5nPXeJaEdXBYVKbeMQuoGv9nSqJpd55K8ynaa/uMhJxs58l OrhJfyjh7G8E7n2PyruJ8A5tyTFJD1+R0PMHtRICfFqRYQsO+LdSqoLYrywPhnOGVOND yGPNPHzYb+w0I4aF9mkk9+sBCPMj2IkdR7XbxAacpWpVzc0qwAeb3LW7/3OqT6BhxS68 t7j863en+W5sxg/EdokbCEgd3xlYOAs5m9ffCzO/E8xzeSJRjaK0EL54TDEfa8PoZNIm TzZFxa4rXBn8wUkp8KTsrN0jtXeRCMguZVtL8fXKyS7Kt7/bi3j5nnp9kd8qVk3wl+rI fBSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790275193; x=1790879993; h=content-type:cc:to:subject:message-id:date:from:references :in-reply-to:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=jYBCExllpZjuV9VV1zLjY0X5zeX8IfnjDk3OiaM07WQ=; b=Q8NFxqr2pD/deSU0HD+9Klk1PK7zULmtybh7nTV8VDNbFee7KqPSwfeI4wE/R8mZtg Je008UfmGpEEau8CfyQd2zdeTbisn/SCl5wWVcL+FL73Za9q/fKNQ/UPp2pf1AV+RuoF b9Z7hx0XmELyBkA4WbWZBksgjc+3xQntbEfk/eKBfWpPDOQBYEH3zZ1by5ER08rsbzVl SCuq3jQXVLWZvMh7c1wfBkqm69TwZqhnd7ikeQLvcL7n+CKyFvY61COIWF7RLE+9dHGa cqzMryeQXARbyGglBEkY6VWmDK5wXMaoHPJJ85Z0a5/BVkuJAeualujnBNVDJdJmnSBw +LhQ== X-Gm-Message-State: AFuF++m7tawO2sULDIEjbTb/DmSXEPH97EO1/ndy9izenvI2os7s+orH Q4jZ1uFuRDZgHV4cKYybmyguWJnBgr2xUViQX7DCsdNKp0gfVvDXb1lBzv3R88YyYVqeOPYTYGV +LO0aA6OkTE94m2/OLW7kKQqDfRAgu+E= X-Gm-Gg: AYBFou1ji9ChMvCBc4Odaw4NeIgDy3Yq0V/goDfchTU3kaREtoNyh9Kc9opbHYz08sR 1uMZyB+tOdrKcrfJ89qb7IhKdfpn6brzL5BG3N0kUlt/69wVNAEzCCRL/0HhbO2RdTmwwjiawHj heIHu9BZWYCh00xMvh+uhVApOyqueF4N5b/yk7IS3Srh5M2mCW8mpfgwOyAqpaSD4NYBGqSTijG Chuthy6w0l3+HJyVHzvUbIyz+pRovKi/ZmNELnB+DC4lkjvvjWxwV3VfdEa+BzxrYpv8uSu1hei //4QRpQUbHtQf+KKgNg8k8nkXSJXy8aV14qML1MPdLPS9Ex6qXsplQ== X-Received: by 2002:a05:6871:810b:b0:48f:e107:8e48 with SMTP id 586e51a60fabf-491e6beac77mr3555833fac.41.1790275193391; Thu, 24 Sep 2026 11:39:53 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <7d51cde8-6d16-49d4-8f07-60cb67a09cf9@proxmox.com> References: <20260706194059.280257-1-copystring@gmail.com> <7d51cde8-6d16-49d4-8f07-60cb67a09cf9@proxmox.com> From: =?UTF-8?Q?Felix_G=C3=B6hringer?= Date: Thu, 24 Sep 2026 11:39:52 -0700 X-Gm-Features: AclHuK-2FpSP9ON5iJk05wwo_2LqM_dM1k89Cror0agFU1u9KdeD1bZYFy_FXUc Message-ID: Subject: Re: [RFC PATCH 0/4] lxc: add safe OCI rootfs replacement To: f.schauer@proxmox.com Content-Type: text/plain; charset="UTF-8" X-SPAM-LEVEL: Spam detection results: 0 DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain DMARC_PASS -0.1 DMARC pass policy FREEMAIL_FROM 0.001 Sender email is commonly abused enduser mail provider 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_NONE -0.0001 Sender listed at https://www.dnswl.org/, no trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record X-MailFrom: copystring@gmail.com X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation Message-ID-Hash: V5R53MSHGKZLAL7TIRGAYEHHK7UFRRMT X-Message-ID-Hash: V5R53MSHGKZLAL7TIRGAYEHHK7UFRRMT X-Mailman-Approved-At: Mon, 28 Sep 2026 09:14:42 +0200 CC: pve-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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 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