mirror of
https://github.com/games-on-whales/LXC2Docker.git
synced 2026-10-15 12:52:04 +00:00
[PR #152] [MERGED] lxc: see every node's guest ids, and let a caller pin one #152
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
games-on-whales/LXC2Docker#152
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
📋 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)
6a7c869lxc: 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
allocateVMIDscanned only/etc/pve/lxcand/etc/pve/qemu-server— symlinks to this node's entries.pct createrejects 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: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
usedVMIDsnow globs/etc/pve/nodes/*/lxcand/etc/pve/nodes/*/qemu-serveras well. The local symlinks stay in the list so a node with no cluster — and so nonodes/tree — is still covered; ids seen twice are a set, so the overlap is free.allocateVMIDtakes a requested id, set from the newdld.vmidlabel, 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 createduntil 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.gocovers: a peer's CT and VM ids being seen; a single node with nonodes/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
allocateVMIDreturning 100 — the peer's id, i.e. the reported bug reproduced in a unit test.go build ./...clean,go vet ./internal/...clean,internal/lxcfully green.(Unrelated, pre-existing on
main:TestTranslateSiblingBindSourceSocketParentFallbackandTestTranslateSiblingBindSourceSharedDestPicksRealOwneralready 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.