[SOLVED] Docker inside LXC (net.ipv4.ip_unprivileged_port_start error)

chunkynutella said:
Is there a way, and if so is there any danger, in installing lxc-pve 6.0.5-3 on PVE 8.4?
Click to expand...
No. In theory you could install the package from PVE9 but then you will also need to update dependencies resulting in a kind of Frankensteinian mix of PVE8, PVE9, Debian12 and Debian13. This tends to make more problems than it's worth:
https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian



@fabian referenced a Patch in https://bugzilla.proxmox.com/show_bug.cgi?id=7057 so there will be a Bugfix soon.

This being said please note that for Debian 12 ( the base of PVE8) and PVE8 are still supported but are only guaranteed to get security patches and only until August 2026. So I would really consider upgrading to PVE9 if you have no good reason to stick with PVE8
 
Last edited:
  • Like
Reactions: rpijoan_ennogtal
I'm pleased to report that lxc-pve 6.0.0-2 appeared in the PVE 8 pve-no-subscription repository today and that after upgrading lxc-pve from 6.0.0-1 to 6.0.0-2 docker 29 runs without issue in my LXC containers.

Thanks for porting this patch to PVE 8.

Code: 
root@pve01:~# pveversion
pve-manager/8.4.14/b502d23c55afcba1 (running kernel: 6.8.12-17-pve)

root@pve01:~# grep "upgrade lxc-pve" /var/log/dpkg.log
2025-11-27 12:51:24 upgrade lxc-pve:amd64 6.0.0-1 6.0.0-2

root@doc01:~# grep "upgrade docker" /var/log/dpkg.log
2025-11-27 12:53:07 upgrade docker-ce-cli:amd64 5:28.5.2-1~debian.12~bookworm 5:29.0.4-1~debian.12~bookworm
2025-11-27 12:53:08 upgrade docker-ce:amd64 5:28.5.2-1~debian.12~bookworm 5:29.0.4-1~debian.12~bookworm
2025-11-27 12:53:10 upgrade docker-buildx-plugin:amd64 0.29.1-1~debian.12~bookworm 0.30.1-1~debian.12~bookworm
2025-11-27 12:53:11 upgrade docker-ce-rootless-extras:amd64 5:29.0.0-1~debian.12~bookworm 5:29.0.4-1~debian.12~bookworm
 
Last edited:
  • Like
Reactions: heapmaster, theaross98, rtgy and 5 others
Johannes S said:
That problem of "resource allocation" isn't one really. Of course if you want to have one VM for each docker container you want to run you will end up in using more RAM (but not neccesarily way more see https://pve.proxmox.com/wiki/Dynamic_Memory_Management#KSM ). But normally you wouldn't do this but run all your docker containers in one lightweight VM. My main docker Debian Trixie vm is configured with 4 GB RAM, right now it uses 1.5 GB. And this can propably reduced even more without changing anything, since Linux always uses part of the memory as cache. By changing the VM os to alpine an even more lightweight VM should be possible. Another benefit of fitting all docker containers in one vm is, that you need the system maintenance (like updates etc) only once instead of doing housekeeping for every lxc instance.
I prefer to save on my time budget instead of saving RAM for the sake of saving RAM.
But if for the sake of "saving resources" you prefer to waste your private time by trouble shooting after breaking changes be my guest.
Click to expand...

For me it's not so much about RAM as it's about Disk Space.

RAM wise I agree that with Dynamic Memory Management (VM Memory using Balloon Feature) it works already much better.

I use podman (rootless) instead of docker.

As a Reference Point, although of course that's highly subjective, I have several pre-configured "templates" CT/VM that I then clone to other Hosts:
- CT Template Fedora 43 AMD64 + salt-minion + podman (no Podman Container running): ~ 105 MB RAM / ~ 715 MB Disk (PVE Host as in zfs list)
- VM Template Fedora 43 AMD64 + salt-minion + podman (no Podman Container running): ~ 207 MB RAM / ~ 3000 MB Disk (PVE Host as in zfs list)

Note that RAM usage is when "freshly booted". The VM will end up using up to 2GB RAM as Caches/Buffers after a while the CT will NOT do that even after several Days.

Sure, 2300MB extra don't seem like much nowadays, but with all the recent Events (AI Bots rewriting every code on GitHub, then spamming the original Project Issue Tracker trying to advertise their "Improved Fork"), I'm starting to migrate away from "Single Hosts with lots of Containers" towards a "Lots of small Hosts with only one Application each". It's only a matter of Time before some of these Applications get compromised, so it's better to plan accordingly and try to compartmentalize them :).
 
You must log in or register to reply here.
Top Bottom
Back