In the lxd init setup, for the question “What IPv4 address should be used?”:
Is there any performance difference or any pros/cons in relation to using something like 10.0.0.1/16 (with 65,536 IPs) versus 10.0.0.1/24 (with 256 IPs) ?
I am guessing this question relates to the default lxdbr0 bridge that gets setup as part of lxd init.
But this is more like a general networking question. LXD works fine with either of those.
Just keep in mind that having too many devices in a single network will cause a lot of noise at some point so in general picking smaller networks should be the preferred option.
Yes, in relation to lxdbr0.
I would have a relatively small number of containers, probably no more than 20-30 on a single machine.
Main goal I have with this is to better organize the private IPs I use on different machines. And also to enable easier export-import between them when necessary so I don’t have to deal with any IP conflicts (with static IPs). I’ll use a unique 3rd octet /24 on each computer, but will setup lxdbr0 with the full range on each so the containers will easily import between them if/when I move things around. /16 is probably overkill, but /20 would give me 0-15 on the 3rd octet so maybe I’ll go with that.
I just wanted to make sure that if I went with /16 IPs it wouldn’t cause some sort of performance degradation of lxdbr0 or something like that.
I’m not quite clear on what you’re trying to achieve here.
Will the aim include the ability for containers on each host to communicate with containers on the other hosts?
Will you be using NAT on each lxdbr0 or planning to use routes?
The way I’m thinking about organizing this may not be idea, not really sure.
The LXD servers that I currently use are: 1 dev & 1 production. That will probably change to 2 dev & 2 production. Who knows, maybe more eventually. I am using NAT on each system and the containers do not need to communicate across systems.
So I got to thinking about how I should handle things when/if I decide to move copies of containers to my local system, maybe for testing things out, etc. Or even just for testing backups, etc. For whatever reason.
My 2 current LXD systems both use 10.0.0.1/24 on lxdbr0
I can fit everything on to 10.0.0.1/24 on both. And so that I can move containers with static IPs between them I could (mentally) reserve the lower half of the 10.0.0.1/24 IP for one system and the upper half for the other system. But they both would be configured for the full 10.0.0.1/24
What I found while testing exports/imports of containers is that dynamically assigned IP containers import fine and use the same IP it had or gets assigned a new IP.
Containers with static IPs don’t always import without issue, it depends. If the IP isn’t already used on the other system then they import fine. If the IP is used, the container will import but it will not start due to the IP already being used. In that case the IP needs to be changed to an available IP before it will start. And the last thing I tested was importing a container with a static IP which is outside the range of IPs that the receiving system is configured for. In that test, the receiving system had 10.0.0.1/24 on lxdbr0 and the container being exported/imported had a static IP of 10.7.7.251 - with that the import failed, would not import at all.
So, what I was thinking of doing was using static IPs on my LXD systems with 10.0.0.1/24 on my dev box, 10.0.1.1/24 on my web server and something like 10.0.2to15.1/24 on any other systems.
Then with all those systems each having configured 10.0.0.1/20 on lxdbr0 I would have zero issues exporting/importing containers (with static IPs) around as they would always work on each of the systems and there would never be an IP type conflict.
Also, would be easier to keep track of local IPs for different things since the IPs would not change when I move the containers between systems.
Additionally, the 3rd octet would tell me at a glance the primary LXD system for a container just by looking at it. Any containers with 10.0.0.# would be intended for my laptop, so if they are on another system that means they were just there as backups and are only copies. 10.0.1.# on my laptop would tell me at a glance that those containers were for my web server, that they are backup copies on my laptop and/or I was doing development work or testing on them on my laptop. Then maybe I pickup a client project, I could set their local IPs to .11. or something, work on them on my laptop but they aren’t mixed up with the IP range that I use for other things (but still can export/import between those systems).
I suppose I could just let LXD use random private IPs for everything, or most things, but then there’s the concern if somehow those IPs get changed. Then that would mean all the IPs in my setup notes would no longer be the correct IPs…
Some other IP organization that I’m doing on my web server, although not really related to the specific issues here, would be for example, using 10.0.1.5* IPs for containers related to a specific website. So not only would the container names tell me what they are for, but also the IPs so whenever I would see a 10.0.1.50-59 IP I would know which website right away.
Sorry for such a long winded post. Just wanted to be sure my thought process on this is clear on why I’m considering these things. By the way, if after all that you understand what I’m pretty much doing and if you know of a better more ideal way, please do let me know.