Proposal For Podman Container Support

[Raven King]

Thomas,

Going forward, I will send all future emails from raven at encodedbird.com. 
Its a long story that has nothing to do with proxmox, but the timing is 
now. Please direct anything else to that as well.

Thank you for a thoughtful and explanatory response. I can easily see 
that directly implementing OCI seems like a smarter approach that would 
integrate better. I definitely see how maintenance concerns and 3rd 
party dependencies are especially an issue when proxmox has a commercial 
support component.

As for me, I am familiar with rust, more so than perl. However I haven't 
used it in a codebase that involves other people, mostly just privately 
at my work on internal tooling for the company. The insights you gave 
here leave me very glad I reached out before hand.

It also causes me to realize some of the complications I had with using 
LXC containers as proxmox implements them would still exist with 
application containers because its actually the same stuff under the 
hood unless new frontend features were added to hide that complication. 
I should clarify that I was able to share LXC directories, but it 
required a much more in-depth understanding of how they are configured 
and wasn't something I could do in the user interface. I am now in sync 
on that.

I can't know how big a task I would be committing to by taking this on 
unless I have already worked on the codebase. So I am gonna take some 
time to try and catch some bugs before I make grand promises about 
delivering such an integrated feature, staying inline with the advice 
y'all gave about it. Sadly this could mean the project is done by the 
time I am ready to start.

I did read the developer documentation beforehand, it was mostly just 
looking at the bug lists I got a little lost.
However, I will probably just try building it, maybe fixing a few bugs 
and adding some jokester toy features I never show to the world for now.

Sincerely,

Raven King

On 3/18/25 02:45, Thomas Lamprecht wrote:
> Hi Raven King,
>
> I want to say thanks up-front for trying to improve on of our open
> source projects and reaching out upfront for doing so, highly
> appreciated.
>
> Am 13.03.25 um 19:03 schrieb Raven King:
>> This is my first time writing to this mailing list. I have never
>> contributed to proxmox but I would like to try and write a feature that
>> allows native container support (not inside an LXC or VM).
> FWIW, LXC definitively are "native containers", it's less confusing
> to use application containers (like OCI conform ones) and system
> containers (running a full distro), as LXC can be used for both,
> i.e. docker used LXC for a while for isolating application CTs.
>
>> My goal would be that you could manage those containers much like
>> LXC/VMs with similar UI behavior (resource usage views, easy access to
>> container console, and resource sharing).
>> Its a large undertaking, and I would probably want to get a little
>> experience with the proxmox codebase first.
> I think we should take a step back and not focus on integrating podman
> too much, but rather about adding support directly in our existing
> container toolkit. Actually I'm pondering about adding support for the
> OCI runtime spec [0] and maybe also the OCI image spec [1] over the
> last years and had some light talks with developers about that, so I
> think you and I agree on the end goal already, but not on the road or
> method to get there.
>
> [0]: https://github.com/opencontainers/runtime-spec
> [1]: https://github.com/opencontainers/image-spec
>
>> *Why do this?*
>>       1. It is parroted by users frequently. Just look up "run docker in
>> proxmox" and you will see dozens.
>>       2. It would add a major use case to proxmox.
>>       3. For me personally, it removes a major pain point of using
>> proxmox, which is setting up an LXC to then share resources with to then
>> setup a docker image to then share resources with.
>>           Or using docker directly and tearing my hair out as it
>> magically breaks all my proxmox network config.
> The why's are all fine, the reason it does not exist yet is not because
> we saw no reason, but rather because there are good workarounds that
> can be used and correctly implementing this into our container runtime
> while ensuring as much as possible is shared with our existing
> implementation.
>
>> *Why Podman?*
>>       1. Easy enough to use.
>>       2. Packaging. The support in debian is straightforward and won't
>> confuse anyone. This means the project won't have to maintain podman
>> itself in any way.
>>       3. Security. Podman needs limited privileges to operate compared to
>> docker. This makes it easier to mesh with things such as user accounts.
>>       4. Interop. It easily goes to/from kubernetes, which can help in
>> some enterprise use cases. Also doesn't interact in ways that break
>> existing pve config mechanisms.
>>
>> *What does podman offer an LXC doesn't?*
>>       1. Easy deployment, you can just pull images that someone prebuilt
>> for a purpose, including most docker images.
>>       2. Directly sharing a host directory (not a whole drive) such as
>> single zfs datastore. While achievable in LXC, you have to do a bunch of
>> user mapping and the setup is rather involved.
> You're mixing things here, LXC is a lower-level technology, it simply
> does not care about image management and certainly does not limit PVE
> on sharing CT and/or host directories at all. LXC rather provide
> building blocks that can definitively be used to support these things.
>
>> *What drawbacks have I considered?
>> *1. Using privileged ports in a podman container is a little tricky
>> without root. Proxmox mostly runs as root though, so this is really only
>> a problem for secondary users.
>> 2. I will take a lot of work to ensure the networking works in a way
>> consistent with other networking in proxmox.
>> 3. Increase support burden as users who aren't entirely familiar with
>> docker/podman containers ask questions that could be answered through
>> research.
>> 4. Some services people might want to run, such as nginx proxy manager,
>> are gonna be very hard to use in this way due to number 1.
> IMO above are not that significant but rather minor/mid-level technical
> hurdles that can be overcome, the biggest drawbacks of using podman
> directly are IMO rather:
>
> - two CT stack we need to support, ours and a third-party one
> - dependency on third party developers and a programming language (Go)
>    we do not use at all in any of our projects.
> - while great software, it does not align _that_ well with Proxmox VE's
>    ways of things, thus a clean and good integration that feels native
>    to PVE, and not just tacked on, is IMO rather hard to do.
>
> That all means quite some high permanent maintenance cost, which is what
> would have to bear, so I'm rather opposed to it, at least without some
> concrete plan of someone having intermediate+ experience with not just
> working with PVE but also internal development, as otherwise it's IMO
> too hard to ensure above concerns are unfounded or not relevant.
> In general, I'd highly favor a native implementation that we have control
> over and can neatly integrate into Proxmox VE and all its features (SDN,
> backup, HA that gets extended by orchestration ...), and given that
> there are specifications for what we want to support here, that should
> be (hopefully) doable without extreme effort, and ideally with not much
> more effort than integrating complete solutions like podman, at least
> if one also minds the long term maintenance cost.
>
>> I am writing to the mailing list before even beginning on this endeavor
>> to get several questions answered:
>>
>> 1. Do y'all have any general tips and pointers about navigating and
>> working with the proxmox codebase?
> There is some basic info here:
> https://pve.proxmox.com/wiki/Developer_Documentation
>
> Definitively does not cover all the things though, but basic patch
> handling should be described.
>
>> 2. Where is a good list to grab bugs to get familiar with proxmox
>> structure and what functionality is where? I have some hardware, but I
>> am not capable of testing stuff like multi-gpu setups.
>>       I see
>> https://bugzilla.proxmox.com/describecomponents.cgi?product=pve but
>> there is a lot of components to proxmox. I have a hard time picking a
>> spot to start.
> We try to add a "start-contributing" tag to some issue requests, i.e.:
> https://bugzilla.proxmox.com/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=UNDECIDED&bug_status=REOPENED&bug_status=MORE%20INFO%20NEEDED&bug_status=POSTPONED&list_id=5791&longdesc=\btag%3A\s*start-contributing&longdesc_type=regexp&query_format=advanced&resolution=---
>
> This can be filtered for the "container" component, albeit I did not
> ensured the three issues that come up are valid:
>
> https://bugzilla.proxmox.com/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=MORE%20INFO%20NEEDED&bug_status=UNDECIDED&bug_status=POSTPONED&component=Container%2FLXC&list_id=50251&longdesc=%5Cbtag%3A%5Cs%2Astart-contributing&longdesc_type=regexp&order=Importance&product=pve&query_format=advanced&resolution=---
>
>> 3. Are there any major drawbacks to container support that need
>> consideration?
> Just to ensure we speak of the same: Containers are already supported
> in general, albeit our runtime that wraps LXC and co is targeting
> system containers, not application ones.
>
>> 4. Are there specific drawbacks to podman that need consideration?
> See above.
>
>> 5. Anything else I am overlooking with this idea?
> The way I'd get started is evaluating the OCI specs, pve-container and
> potentially also existing runtimes that implement the OCI specs.
> For then implementing the spec and integrating that into pve-container
> we would definitively open, even lightly encouraging, doing so in rust,
> maybe at least the lower level building blocks for understanding/parsing
> formats as defined in the OCI specs. Then use perlmod [2] to integrate
> that rust modules into the existing pve-container Perl based code.
> You could also just stay in perl, that would be fine for us, but in
> general we try to use rust if possible for new (bigger) features and
> also find that it provides us with a lot of guarantees and modern
> language features to make one lives easier in the long term.
>
> [2]: https://git.proxmox.com/?p=perlmod.git;a=blob;f=README.md;hb=HEAD
>
> That's naturally a lot to ask for a new contributor, but if it was
> easy it would have been already done, and we simply want to favor
> native and well integrated solutions to avoid external dependencies,
> of which drawbacks we had to deal with too much in the past, so we're
> pretty much set on that part.
>
> FWIW, I directly CC'd one developer I talked lightly over adding OCI
> support to PVE, maybe he got some time to think over this and
> spearhead the initial effort.
> If you're still interested into tackling this we naturally will try
> to help you on any specific question, I still appreciate you wanting
> to move this forward, but I also wanted to manage expectations, as
> this might be quite the task, especially for one not accustomed to
> our project and its code basis.
>
> best regards
> Thomas
>