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

[Spencer Baugh]

Lennart Poettering <lennart at poettering.net> writes:

> On Mon, 20.04.15 22:50, Spencer Baugh (sbaugh at catern.com) wrote:
>> Yes, in that case, it is of course very simple, but it is not at all
>> configurable. I have one thing and one thing only that I want to
>> configure: The IP address that a given container receives. This seems
>> like a reasonable thing to want to configure; ultimately there have to
>> be fixed IP addresses somewhere, and I have a use for containers that
>> would benefit from having fixed IP addresses.
>> 
>> The way I currently fix the IP address that the container receives is by
>> fixing the MAC address of the veth; since I am using IPv6 and radvd, the
>> IP address is deterministically generated from the MAC address. So it
>> would be helpful if there was a way to do fix the MAC address in
>> nspawn. Would you accept a patch to add an option to nspawn to specify a
>> MAC address for the veth? Or is there a better way to go about this?
>
> 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.

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

>> > Another option could be to use write a service that sets up the
>> > interface, uses PrivateNetwork= and then use JoinsNamespaceOf= on the
>> > container service towards that service, and turn off nspawn's own
>> > private networking switch. That way PID1 would already set up the
>> > joint namespace for your container, and ensure it is set up properly
>> > by your setup service. And as long as either the setup service or the
>> > container is running the network namespace will stay referenced.
>> 
>> Hmm, that is an interesting approach... it would be nice to be able to
>> have networkd be setting up the interface here, though.
>
> Well, it can, but only if you run it inside of the container. I am
> pretty sure the networkd of the host should not configure the
> interfaces inside of it...
>
>> 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.

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.

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