[systemd-devel] Setting up network interfaces for containers with --private-network

[Lennart Poettering]

On Tue, 21.04.15 10:58, Spencer Baugh (sbaugh at catern.com) wrote:

> > The MAC address is currently generated as hash value from the
> > container name, it hence should be completely stable already as long
> > as you keep using the same name for the container?
> 
> Well, generally I want to know what MAC/IP address a machine/container
> will receive in advance of actually starting it. I could start it once
> and immediately stop it to see and record what MAC address is generated
> for a given name, or copy the code to generate the MAC address out of
> nspawn.c, but neither of those seem like good options.

Sidenote: if this is about having stable names to refer to containers,
note that nss-mycontainers adds those automatically. If enabled, then
all local container names will be resolvable, automatically. It's
often hence unnecessary to have fixed IP addresses for this at all.

> > maybe the ipvlan stuff could work for you?
> 
> It's possible, but then I'd be back to the situation where I need to
> write a script to keep bringing up the ipvlan devices before starting
> the container. Unless ipvlan devices don't disappear when the namespace
> disappears?

Nope, this is the same for ipvlan, macvlan, veth links.

> >> I am interested in using networkd to do these things, but at the moment
> >> it doesn't seem to have the required level of power.
> >
> > what do you mean precisely with this?
> 
> I mean that instead of writing another service (probably a shell script)
> to set up the interface on the host, using the PrivateNetwork= and
> JoinsNamespaceOf= trick, instead have networkd set up the interface on
> the host inside a network namespace and use the same kind of trick.

Well, I mean how useful would this actually be? THis would only work
for static configuration, everything more complex requires a daemon
watching the interface continously and that's really hard to do for a
set of network interfaces in a different network namespace.

Also, trivial static IP configuration is seldom sufficient, you at
least need to also provide DNS configuration, and if you don't use
DHCP or something similar then you need to configure that inside the
container anyway. But if you do that you might as well configure the
static IP addresses in it too, so what is gained by doing this from a
networkd outside of the cotnainer?

> Or am I misunderstanding the role of networkd? It seems like if I am
> writing a service that represents "the network interface and namespace
> for this container", I am doing something that networkd should
> ultimately do.

Sure, absolutely. But our idea so far was that networkd should run
inside the container to configure the container's network, and on the
host to configure the host's network, but not to cross this boundary
and have the host networkd configure the container's network.

> "Set up the interface" here just means "create the interface with a
> specific MAC address", of course.

Well, of course, we could beef up systemd-nspawn and allow it to take
configurable IP or MAC addresses on the command line, and then it
would become a second networkd, and we already have one of those...

Lennart

-- 
Lennart Poettering, Red Hat