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

[Lennart Poettering]

On Wed, 22.04.15 13:41, Spencer Baugh (sbaugh at catern.com) wrote:

> Lennart Poettering <lennart at poettering.net> writes:
> > On Tue, 21.04.15 15:22, Spencer Baugh (sbaugh at catern.com) wrote:
> >
> >> > 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.
> >
> > Well, again, I doubt that configuration exclusivel at
> > interface-creation-time will be useful for more than the most trivial
> > cases, already because as mentioned it would not cover DNS server
> > configuration and thelike.
> 
> Sure, I'm in agreement, but there are things that can only be
> "configured" at interface-creation-time. As a trivial example, the type
> of the interface. And it looks like for ipvlan you can only choose L2 or
> L3 mode at creation-time.
> 
> Additionally, it seems to me that the MAC address, at least, is
> something that you might want to configure only at creation-time and not
> change later.

networkd considers the MAC address that can be changed for the network
you connect to, and can hence change dynamically depending on the
network you pick.

Hmm, there's indeed a gap here though: as .link files are applied by
udev, not by networkd, and udev is not available in containers, .link
files are currently not applied at all in containers. It might be an
option to do this within networkd instead of udev when it is run in a
container.

Of course, this will then only cover the props that can be changed
with .link files, not the ones that have to be specified at link
creation time.

For those, things are nasty. I mean, for things like ipvlan which
relate to an interface outside of the container, this means we need to
create them outside of the container, and thus they need to be
configured initially outside of the container.

So far we handled all this inside .netdev files, that are processed by
networkd. We have limited support for creating these devices also with
nspawn (i.e. the --network-veth, --network-macvlan and
--network-ipvlan switches), but I'd be really careful with turning
them into more than just basic switches, I'd really leave more complex
cases with networkd.

Now, I am not really sure how would could hook this up... After all
as you say it will not be sufficient to create the netdevs once before
nspawn uses them, they need to be created before each time before
nspawn uses them.

As soon as networkd gains a bus interface maybe an option could be to
hook up nspawn's --network-interface= with it: if the specified
interface doesn't exist, nspawn could synchronously ask networkd to
create it. With that in place you could then configure .netdev files
outside of the container, and neatly pass them on into the container,
without races. Would that fix your issue?

> > If you really want fixed IP addresses, I think this could work:
> >
> > We add configurability for the DHCP server address range in networkd,
> > including taking ranges that contain a single IP address. You could
> > then assign fixed addresses to your containers simply by dropping a
> > .network snippet for them, that only contains a single dhcp range IP
> > address for it. THat should work, no?
> 
> This would be a nice feature and would work for many use cases.
> 
> My problem with this solution is that I'm using IPv6. With IPv6, I can
> set up stateless autoconfiguration to "assign" IPs to interfaces.  In
> that case the IP is directly determined by the MAC address, so it is not
> possible (AFAIK?) to specify a range of IPs of length 1 to force that
> single IP to be assigned to a specific interface.
> 
> I would somewhat prefer to be using this feature of IPv6, rather than
> using DHCPv6; and anyway, networkd doesn't support DHCPv6 right now,
> right? So this doesn't necessarily work for me.

True. It's certainly our plan to support it eventually.

Lennart

-- 
Lennart Poettering, Red Hat