[GH-ISSUE #9] LXC id not validated against cluster availability #1

New issue

Open

opened 2026-10-15 12:52:31 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 12:52:31 +00:00

Owner

Originally created by @traek on GitHub (Aug 30, 2026).
Original GitHub issue: https://github.com/games-on-whales/proxmox-community-script/issues/9

During the initial script run, I am prompted for a CT ID for the Wolf container with a default value for the next available CT:

CT id for the Wolf container [111] (I went with 200... more on that in a minute)

However, later in the script run, I see it attempt to use a CT of 108 (in use by another node in the cluster):
✘ service:wolf:1 Error response from daemon: manager: pct create 108 from tarball: CT 108 already exists on node 'castor'

I tried a few executions and it always seems to pick a different CT each time -- so far, at least -- always from the other node in the cluster. Like most others, I'm currently running GOW inside of a privileged Docker LXC w/ nesting and then came across this script and thought it would be a more "native Proxmox" way to handle containers.

I perused install.sh only briefly and it looks like you're checking the right limits for the cluster but once it starts generating additional containers, it goes back to LXC2Docker which you mention in the comments starting at line 106, potentially breaking this for all clusters, particularly one with tightly allocated CTs. The fact it doesn't seem to do anything with the value I provided as any sort of guide -- like a minimum id number -- is what made me feel the need to log this issue.

A possible solution might be including the prompt CT id as the floor of the possible CTs from thereon out. I provided an id of 200 where I won't use anything for any other purpose until 300, though again, I'd probably won't more control over it, maybe with configurable lower and upper limit (like 200 to 299 or 3000-3100, etc.) and just make the Wolf container CT the lowest value.

I understand that technically this bug is against LXC2Docker but I have to assume that the script could provide a safe configuration for LXC2Docker to use, though I'm not aware of a way for any sort of reservation to be enforced by Proxmox in any way.

Originally created by @traek on GitHub (Aug 30, 2026). Original GitHub issue: https://github.com/games-on-whales/proxmox-community-script/issues/9 During the initial script run, I am prompted for a CT ID for the Wolf container with a default value for the next available CT: `CT id for the Wolf container [111]` (I went with 200... more on that in a minute) However, later in the script run, I see it attempt to use a CT of 108 (in use by another node in the cluster): `✘ service:wolf:1 Error response from daemon: manager: pct create 108 from tarball: CT 108 already exists on node 'castor'` I tried a few executions and it always seems to pick a different CT each time -- so far, at least -- always from the other node in the cluster. Like most others, I'm currently running GOW inside of a privileged Docker LXC w/ nesting and then came across this script and thought it would be a more "native Proxmox" way to handle containers. I perused `install.sh` only briefly and it looks like you're checking the right limits for the cluster but once it starts generating additional containers, it goes back to LXC2Docker which you mention in the comments starting at [line 106](https://github.com/games-on-whales/proxmox-community-script/blob/56d78ec08390138fe8e7db65d38b04b431eea758/install.sh#L106), potentially breaking this for all clusters, particularly one with tightly allocated CTs. The fact it doesn't seem to do anything with the value I provided as any sort of guide -- like a minimum id number -- is what made me feel the need to log this issue. A possible solution might be including the prompt CT id as the floor of the possible CTs from thereon out. I provided an id of 200 where I won't use anything for any other purpose until 300, though again, I'd probably won't more control over it, maybe with configurable lower and upper limit (like 200 to 299 or 3000-3100, etc.) and just make the Wolf container CT the lowest value. I understand that technically this bug is against LXC2Docker but I have to assume that the script could provide a safe configuration for LXC2Docker to use, though I'm not aware of a way for any sort of reservation to be enforced by Proxmox in any way.

bsakaguchi referenced this issue

2026-10-15 12:52:34 +00:00

[PR #1] [MERGED] installer: prompt for storage, disk, CPU, RAM, and GPU #3