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