[PR #152] [MERGED] lxc: see every node's guest ids, and let a caller pin one #152

Closed
opened 2026-10-15 12:52:23 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/games-on-whales/LXC2Docker/pull/152
Author: @JBailes
Created: 8/10/2026
Status: ✅ Merged
Merged: 8/10/2026
Merged by: @JBailes

Base: main ← Head: feat/pin-ct-vmid-and-cluster-wide-scan


📝 Commits (1)

  • 6a7c869 lxc: see every node's guest ids, and let a caller pin one

📊 Changes

5 files changed (+230 additions, -11 deletions)

View changed files

📝 internal/api/containers.go (+12 -0)
📝 internal/lxc/config.go (+6 -0)
📝 internal/lxc/manager.go (+57 -8)
📝 internal/lxc/pve_tarball.go (+12 -3)
➕ internal/lxc/vmid_test.go (+143 -0)

📄 Description

allocateVMID scanned only /etc/pve/lxc and /etc/pve/qemu-server — symlinks to this node's entries. pct create rejects an id owned anywhere in the cluster, so on a multi-node cluster the daemon handed out ids a peer already held and every create for such an id failed:

manager: pct create 103 from tarball: CT 103 already exists on node 'pve1'

A restarting container (Wolf, say) walks one id further on each attempt and never settles, and nothing in the error names the peer as the reason. Reported from a live two-node cluster.

Changes

usedVMIDs now globs /etc/pve/nodes/*/lxc and /etc/pve/nodes/*/qemu-server as well. The local symlinks stay in the list so a node with no cluster — and so no nodes/ tree — is still covered; ids seen twice are a set, so the overlap is free.

allocateVMID takes a requested id, set from the new dld.vmid label, for callers that need a container at a known, stable id rather than whatever is lowest and free. A requested id already owned, or already in flight, is an error rather than a silent slide to the next free one: the caller pinned it precisely because which id it gets matters. Image template CTs are daemon-internal and keep taking the next free id.

Reservations are released when the create returns. On success the CT config is on disk, so the reservation was redundant; on failure the id becomes free again. This matters for a pinned id: a leaked reservation made every later create for that exact id fail with already being created until the daemon restarted — so one transient failure permanently wedged a container that was trying to restart, which is the very situation a pinned id is used in.

Tests

New internal/lxc/vmid_test.go covers: a peer's CT and VM ids being seen; a single node with no nodes/ tree still being seen; and a pinned id being honoured, refused when taken, refused when another create holds it, and retryable after a failed create.

Red-before-green: against the old local-only scan the cluster tests fail with allocateVMID returning 100 — the peer's id, i.e. the reported bug reproduced in a unit test.

go build ./... clean, go vet ./internal/... clean, internal/lxc fully green.

(Unrelated, pre-existing on main: TestTranslateSiblingBindSourceSocketParentFallback and TestTranslateSiblingBindSourceSharedDestPicksRealOwner already fail on a stock checkout — verified by stashing.)

Companion: games-on-whales/proxmox-community-script#8, which prompts for the Wolf CT id and passes it as dld.vmid. That label is inert until this lands.


🔄 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/152 **Author:** [@JBailes](https://github.com/JBailes) **Created:** 8/10/2026 **Status:** ✅ Merged **Merged:** 8/10/2026 **Merged by:** [@JBailes](https://github.com/JBailes) **Base:** `main` ← **Head:** `feat/pin-ct-vmid-and-cluster-wide-scan` --- ### 📝 Commits (1) - [`6a7c869`](https://github.com/games-on-whales/LXC2Docker/commit/6a7c869de05a87cce7ea2887f491288485e1fd8e) lxc: see every node's guest ids, and let a caller pin one ### 📊 Changes **5 files changed** (+230 additions, -11 deletions) <details> <summary>View changed files</summary> 📝 `internal/api/containers.go` (+12 -0) 📝 `internal/lxc/config.go` (+6 -0) 📝 `internal/lxc/manager.go` (+57 -8) 📝 `internal/lxc/pve_tarball.go` (+12 -3) ➕ `internal/lxc/vmid_test.go` (+143 -0) </details> ### 📄 Description `allocateVMID` scanned only `/etc/pve/lxc` and `/etc/pve/qemu-server` — symlinks to *this* node's entries. `pct create` rejects an id owned anywhere in the cluster, so on a multi-node cluster the daemon handed out ids a peer already held and every create for such an id failed: ``` manager: pct create 103 from tarball: CT 103 already exists on node 'pve1' ``` A restarting container (Wolf, say) walks one id further on each attempt and never settles, and nothing in the error names the peer as the reason. Reported from a live two-node cluster. ## Changes **`usedVMIDs` now globs `/etc/pve/nodes/*/lxc` and `/etc/pve/nodes/*/qemu-server`** as well. The local symlinks stay in the list so a node with no cluster — and so no `nodes/` tree — is still covered; ids seen twice are a set, so the overlap is free. **`allocateVMID` takes a requested id**, set from the new `dld.vmid` label, for callers that need a container at a known, stable id rather than whatever is lowest and free. A requested id already owned, or already in flight, is an error rather than a silent slide to the next free one: the caller pinned it precisely because which id it gets matters. Image template CTs are daemon-internal and keep taking the next free id. **Reservations are released when the create returns.** On success the CT config is on disk, so the reservation was redundant; on failure the id becomes free again. This matters for a pinned id: a leaked reservation made every later create for that exact id fail with `already being created` until the daemon restarted — so one transient failure permanently wedged a container that was trying to restart, which is the very situation a pinned id is used in. ## Tests New `internal/lxc/vmid_test.go` covers: a peer's CT and VM ids being seen; a single node with no `nodes/` tree still being seen; and a pinned id being honoured, refused when taken, refused when another create holds it, and retryable after a failed create. Red-before-green: against the old local-only scan the cluster tests fail with `allocateVMID` returning **100** — the peer's id, i.e. the reported bug reproduced in a unit test. `go build ./...` clean, `go vet ./internal/...` clean, `internal/lxc` fully green. _(Unrelated, pre-existing on `main`: `TestTranslateSiblingBindSourceSocketParentFallback` and `TestTranslateSiblingBindSourceSharedDestPicksRealOwner` already fail on a stock checkout — verified by stashing.)_ Companion: games-on-whales/proxmox-community-script#8, which prompts for the Wolf CT id and passes it as `dld.vmid`. That label is inert until this lands. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
bsakaguchi 2026-10-15 12:52:23 +00:00
Sign in to join this conversation.
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
games-on-whales/LXC2Docker#152
No description provided.