netavark
netavark copied to clipboard
containers
Feature Request: add subinterface creation
/kind feature
Description
docker network create allows automated creation of trunk bridge mode vitual IPs that map to each created container if you call a new subinterface name, such as "eth0.2". This is useful for running services under podman that might normally get their own virtual IP, such as serving DNS.
It would be nice to have this option in podman as well, particularly for folks who are moving services from native executables to podman containers.
Realistically, it will take a significant amount of work to make this happen since CNI is more complicated than whatever docker is doing, but I wanted to get this in the queue in case someone was looking for networky things to hack on.
While you're implementing this, it would be nice to have podman support the --parent switch for syntax compatibility with docker network create
References
- https://docs.docker.com/network/macvlan/
- https://github.com/containers/libpod/blob/master/docs/source/markdown/podman-network-create.1.md
I know we do support macvlan mode right now, but the flags (and overall functionality) are very different from what I'm seeing in the Docker docs.
if there is a way to create the virtual IP from podman generate network, then maybe this just requires a doc patch. tell me how to do it and I'll write the docs
I don't think we can now - our macvlan support is primarily intended to source IPs from an external DHCP server
if there is a way to create the virtual IP from podman generate network
podman run support --ip string lets the interface get a static IPv4 (from host-local IPAM) which can be used for such things as DNS Server, web server, etc. Would this suffice? There is also the CNI static IPAM too, which (iirc) lets you avoid the need for --ip string
I'm talking about a virtual interface on the host, not just an internal IP address in the podman network.
A friendly reminder that this issue had no activity for 30 days.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
I'm talking about a virtual interface on the host, not just an internal IP address in the podman network.
Has anyone tried / considered adding the virtual interface on the host first, then using the host-device CNI plugin? You can put a real interface inside the container this way. CNI just moves the netdev so virtual interface should work as if it was a real one.
CNI itself expects to find the "host-device" already exists before it can be used. podman network create could possibly have a flag to create sub-interface (eth0.2) first, then use host-device instead of bridge plugin.
A friendly reminder that this issue had no activity for 30 days.
A friendly reminder that this issue had no activity for 30 days.
@mheon @baude As we come out of Bug fix mode, is this a feature we should prioritize?
I think other parts of networking have priority over this (improvements to dnsname, for example)
A friendly reminder that this issue had no activity for 30 days.
A friendly reminder that this issue had no activity for 30 days.
A friendly reminder that this issue had no activity for 30 days.
Potentially - if nothing else, it puts us in a much better position to implement this.
A friendly reminder that this issue had no activity for 30 days.
Hi, I'm new to PodMan.
I am wondering, why don't we just create the subinterface eth2.1 if it doesn't exists,
when we call podman network create --driver macvlan -o parent=eth2.1.
As far as I know, the job of creating a network should be to create a CNI configuration file, and then CNI is responsible for the processing of the corresponding network stack. It would be better if it could be more compatible with docker's usage habits.
OK, I get it. Is this a WIP rewrite or should we wait for a long time? I'd like to join and do some work for a deeper understanding of PodMan.
The early stages have already been done by @Luap99 and we're now finalizing the architecture for the remaining bits; target is to have it ready for Podman 4.0 in January.
A friendly reminder that this issue had no activity for 30 days.
A friendly reminder that this issue had no activity for 30 days.