Lennart Poettering <lenn...@poettering.net> writes: > On Mon, 20.04.15 15:25, Spencer Baugh (sba...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel