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

[Spencer Baugh]

Lennart Poettering <lennart at poettering.net> writes:
> On Wed, 22.04.15 13:41, Spencer Baugh (sbaugh at catern.com) wrote:
> > Lennart Poettering <lennart at poettering.net> writes:
> > > 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?

Yes, that sounds like it would work. This would destroy and recreate the
interface on reboot, which is fine for my use case.

There might at some point be a desire by someone else to have the
interface not be destroyed on reboot. At that point it would just
require teaching networkd something about network namespaces, which
shouldn't be hard. I don't want that myself, of course.

As a stopgap measure until the feature you described is ready, I'll use
the .service with PrivateNetwork= and JoinsNamespaceOf= suggestion you
made earlier.

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

That's in reference to just DHCPv6, right? What about stateless
autoconfiguration, out of curiosity?