[PR #71] [MERGED] feat(lxc): instant linked-clone fast path for lvmthin storage #71

New issue

Closed

opened 2026-10-15 12:51:47 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 12:51:47 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/games-on-whales/LXC2Docker/pull/71
Author: @JBailes
Created: 6/7/2026
Status: ✅ Merged
Merged: 6/7/2026
Merged by: @JBailes

Base: main ← Head: feat/pve-lvmthin-linked-clone

📝 Commits (1)

e12a758 feat(lxc): instant linked-clone fast path for lvmthin storage

📊 Changes

3 files changed (+199 additions, -7 deletions)

View changed files

📝 internal/lxc/manager.go (+18 -6)
📝 internal/lxc/pve_tarball.go (+147 -1)
📝 internal/lxc/pve_tarball_test.go (+34 -0)

📄 Description

On lvmthin (and any non-ZFS PVE storage) every docker run took the pct create path, which re-extracts the whole image rootfs tarball into a fresh thin volume each launch — ~2 GB for the Steam image, tens of seconds. Only ZFS had a copy-on-write fast path.

This adds the equivalent for lvmthin while keeping containers as normal pct-managed CTs:

Materialize each image into a Proxmox template CT once (tarball extracted a single time, pct template).
Provision every container as a linked pct clone of that template — an instant CoW clone, no data copy regardless of image size.

Details:

New dispatch branch gated on pveStorageSupportsLinkedClone() (lvmthin only; ZFS keeps its raw-clone path; dir/lvm/nfs keep pct create).
ensureImageTemplateCT materializes/reuses the template once, serialized by tmplMu, tagged so reapOrphanCTs can reclaim it if its image record is lost.
Linked clones use no --full and no --storage (pct rejects --storage for linked clones; the clone stays on the template’s storage).
Falls back to pct create on any template/clone failure, so a launch never hard-fails on the fast path.
RemoveImage destroys the template CT (best-effort; on lvmthin the base volume can be removed while linked clones still reference its blocks).
Shared the post-create config/IP/rootfs tail of both tarball paths into finalizePVECT.

Tradeoff: the per-image template CT is visible in the Proxmox UI — the cost of staying on the supported pct clone path for block storage (ZFS avoids this with a hidden dataset).

Validated the pct primitives live on PVE 9.2 / lvmthin (template create + pct template, linked pct clone with no --storage, and destroying the template while a linked clone still exists). Build, vet, and unit tests pass.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/games-on-whales/LXC2Docker/pull/71 **Author:** [@JBailes](https://github.com/JBailes) **Created:** 6/7/2026 **Status:** ✅ Merged **Merged:** 6/7/2026 **Merged by:** [@JBailes](https://github.com/JBailes) **Base:** `main` ← **Head:** `feat/pve-lvmthin-linked-clone` --- ### 📝 Commits (1) - [`e12a758`](https://github.com/games-on-whales/LXC2Docker/commit/e12a758e2babe5729c1867563a3671245a951888) feat(lxc): instant linked-clone fast path for lvmthin storage ### 📊 Changes **3 files changed** (+199 additions, -7 deletions) <details> <summary>View changed files</summary> 📝 `internal/lxc/manager.go` (+18 -6) 📝 `internal/lxc/pve_tarball.go` (+147 -1) 📝 `internal/lxc/pve_tarball_test.go` (+34 -0) </details> ### 📄 Description On lvmthin (and any non-ZFS PVE storage) every `docker run` took the `pct create` path, which re-extracts the whole image rootfs tarball into a fresh thin volume each launch — ~2 GB for the Steam image, tens of seconds. Only ZFS had a copy-on-write fast path. This adds the equivalent for lvmthin while keeping containers as normal `pct`-managed CTs: - Materialize each image into a Proxmox **template CT** once (tarball extracted a single time, `pct template`). - Provision every container as a **linked `pct clone`** of that template — an instant CoW clone, no data copy regardless of image size. Details: - New dispatch branch gated on `pveStorageSupportsLinkedClone()` (lvmthin only; ZFS keeps its raw-clone path; dir/lvm/nfs keep `pct create`). - `ensureImageTemplateCT` materializes/reuses the template once, serialized by `tmplMu`, tagged so `reapOrphanCTs` can reclaim it if its image record is lost. - Linked clones use no `--full` and no `--storage` (pct rejects `--storage` for linked clones; the clone stays on the template’s storage). - Falls back to `pct create` on any template/clone failure, so a launch never hard-fails on the fast path. - `RemoveImage` destroys the template CT (best-effort; on lvmthin the base volume can be removed while linked clones still reference its blocks). - Shared the post-create config/IP/rootfs tail of both tarball paths into `finalizePVECT`. **Tradeoff:** the per-image template CT is visible in the Proxmox UI — the cost of staying on the supported `pct clone` path for block storage (ZFS avoids this with a hidden dataset). Validated the `pct` primitives live on PVE 9.2 / lvmthin (template create + `pct template`, linked `pct clone` with no `--storage`, and destroying the template while a linked clone still exists). Build, vet, and unit tests pass. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-15 12:51:47 +00:00