[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 15:25, Spencer Baugh (sbaugh at catern.com) wrote:
> So far I'd recommend running networkd on the host and in the
> container. If you run it on the host, then it will automatically
> configure the hos side of each of nspawn's veth links with a new IP
> range, and be a DHCP server on it, as well as do IP
> masquerading. Connectivity will hence "just work", if you use networkd
> in most cases.

This is in the case where I use --network-bridge, right? Because
otherwise there is no veth to be automatically configured.

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?

> Of course, if you want to manually set up things, without networkd or
> an equivalent service, then a lot of things will be more manual: one
> way could be to add some script to ExecStartPre= of the service to set
> things up for you each time you start the container.
>
> 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.

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.