Added support for additional lxc.network settings

[krschwab]

Signed-off-by: Kerry Schwab [email protected]

[stgraber]

Hi,

So actually those options were intentionally left out from LXD.
It's still possible to set them through raw.lxc if you have an odd setup where you really really need them but in that case, you have to acknowledge that things may break, especially features like migration, copies, renames, ...

The main reason for this decision is that almost all workloads will unset any pre-configured network configuration. So instead of pre-configuring the network namespace, LXD just lets the client do DHCP or alternatively provides configuration through userdata exposed to the container (and through the upcoming /dev/lxd device).

As for the up/down scripts, they are a bit of a nightmare when you have to support live migration as if they are inside the container, they are a security risk (as they run partly in the host namespace) and if they are outside the container, then they're not migrated, making the container configuration invalid.

The current LXD design is to never execute untrusted code outside of a trusted environment, which is why our image format supports templating, but not hooks and why we haven't implemented hook scripts anywhere else. We also find executing scripts to be generally brittle and hard to extend without breaking existing users.

There's however a plan that moving forward we'll support global hooks with a hook API so that those hooks can talk cross-server during live migration. Designing this is rather tricky and so far hasn't really been a priority.

With all that, I unfortunately have to decline this, otherwise perfectly good pull request.

If you have very specific use cases that aren't covered with current LXD, please let us know and we'll check how that fits with our planned work and whether there's something we missed.

Thanks!

[krschwab]

Sure. The specific use case is a traditional VPS, with public facing IP addresses.

The supplied dnsmasq and veth setup works terrific with nat ips, but doesn't work well with real, routable ipv4s.

But, in this case, we can likely manage in a different way. I'll see if there's some way we can use DHCP. It's a bit tricky in that the servers are ours, but the network is not.

Thank you.

[stgraber]

Right, so in your case you can usually go one of two ways:

• Bridge the WAN interface, stick the containers into that bridge and configure the network inside the container (/etc/network/interfaces or equivalent) to use the static IP you want for it
• Keep the containers on lxcbr0, configure the network in the container to add the public IP as an extra address on eth0 (ip addr add ADDRESS/32 dev eth0) and then add a static route for the IP on the host (ip route add ADDRESS/32 via 10.0.3.X dev lxcbr0).

[krschwab]

Yes, thanks. It's the assigning an ip part that's a little tricky. We do have the WAN interface bridged, and are using these additional options to set the ip, default gateway, etc, for the containers.

DHCP isn't ideal, as the packets leak onto a network that isn't ours, with DHCP servers on it. We can, of course, alter the files in the container to set the ip address there, but then we lose the "remote control" benefit of lxd.

The idea was to leverage the lxd remote api...allowing us a simple, central web-based panel for customers to spin up a VPS on any of the available servers. Something like the way Wable works. We give them not a specific VPS, but a pool of a specific number of ips, memory, and storage. They can make one big VPS, with all the ips/memory/storage, or several small ones, etc.

But then, that's not really your issue :) We'll either have to keep our local mods, or take an entirely different approach than lxd.

I can say that I like the lxd approach. The code is very easy to follow.