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

[Spencer Baugh]

Lennart Poettering <lennart at poettering.net> writes:
> 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.

It is about stable names, but I believe those names need to be usable
from off the host.

>> >> 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.

All that I want to do is configuration that can be done at the time of
first creating the interface - like setting the MAC address. That is all
the script that I am using at the moment does, everything else is done
by networkd.

> 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.

Hmm, yes, but I think the problem is the configuration done at
interface-creation-time. It seems to me that that configuration
currently does not fit naturally in either the host networkd or the
container networkd.

>> "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...

Yes, but what else can configure the interfaces at creation time?