Lxd bridge and static ip confusion

LXD
1

Hello everybody!

Im well into week 4 of my exploration of lxd and somehow feel really confident in using it locally (host only networking) but also very confused when it comes to networking with public ips.
I have used a manually created bridge already to have IPs assigned via dhcp to new containers (which works great!) at home for testing purposes.

Now I want to transfer this setup to a root server, which is where I really struggle I cannot get IP addresses of an additional subnet assigned to my containers and all the available information is ether outdated, outright wrong or doesn’t resemble what I am trying to do.

I already read some of simos’ tutorials, found a couple of questions at stackoverflow that were answered by Stéphane… But this just problem just makes me feel like beeing completely out of my league… :slight_smile:

I guess my setup is not that far away from Alejandro over here: Give public ip one container with custom bridge but I can’t seem to find and follow the necessary steps

Given are the following restrictions:

  • I have a public static IP for the lxd host (say 100.100.100.65)
  • I have a subnet available for containers (say 100.200.200.48/29) giving me 6 addresses for containers, or even 8 if I use gateway and broadcasting IP too (which would be bonus points).
  • All IPs of the subnet are statical routed to the host IP.
  • Virtual Mac Addresses would be available to get dhcp static leases, but I’d rather avoid the additional cost + they are only available for single ips, hence not giving me the freedom of adding another subnet to the host if need be.

I read, that I cannot use the managed lxdbr0 interface for the subnet to automagically assign “ipv4.address” to containers.
So now I wonder how to configure static IP addresses for the containers without

  • editing an pushing an interfaces-file to the container
  • entering the container and editing said file manually?

Also I wonder about how I would route the ips to the containers (after assigning them to the interface)

I just magine I had 40 hosts, running a plethora of small containers, but with mentioned restrictions (no dhcp for mac adresses, etc…).

What would be a manageable way to configure these to begin with, and maybe even add additional IP adresses to single containers (if need be)?

I read Stéphane mentioning lxc network set lxdbr0 ipv4.routes which is not available in my version (2.21) of lxd and then post-up and pre-down ing the ip addresses in the container itself.
But this seems so impractical even if you are just spinning up a few containers every day.

I know this would still be somehow scriptable, but just does not feel right.
Seeing how openVZ seeminigly easily manages to assign an IP to a container this just boggles me.
How would something alike be possible with lxd ?

Happy to give further information if need be.

best
Oliver

2

Right, in your setup, assuming you want to use that entire subnet for your containers, you would do:

lxc network set lxdbr0 ipv4.routes 100.200.200.48/29

Which will setup a static route for that subnet to go to your lxdbr0 bridge.
Now for actually having containers use an IP in that subnet, you’d indeed need manual configuration in the container. For just a few containers (you mentioned 8 or so), then that’s probably fine to do by hand.

For people dealing with much larger number of containers, they’d probably just run the entire bridge on the public subnet (setting ipv4.address to the first IP of the subnet). That effectively eats 3 IPs off that subnet (network, gateway and broadcast), leaving the rest to be assigned by dnsmasq to containers. In that case, the ipv4.address property on the nic device of the container can be used to setup static DHCP assignments.

There is no venet (openvz layer 3) equivalent in the Linux kernel, at least not that work in the way you’d want (ipvlan is close). So in practice everyone has to deal with bridges or similar layer 2 constructs which make dealing with that case of only a subset of your containers getting public IPs a bit more complex than it feels it should be.

3

Ah, right! I totally forgot about that.
And also thanks a ton for explaining both options.
I tested them and went for the manual modification since I found out, that the IP will still be displayed in lxc list output.
Works like a charm!