now, i am curious. with a few containers, or more. can i build a multi-node multi-LAN -like network and do some complex routing, like maybe with OSPF?
Depends on what you had in mind. I am using ospf inside some containers provided by frr. The containers are attached to multiple vlans, which I have created with openvswitch on the host. Works nicely even across openvpn tunnels.
Outside of Ubuntu, it’s a bit easier to deploy LXC than LXD on distros completely outside the Debian/Ubuntu ecosystem, because it has fewer dependencies on kernel features and patches. However, with the proper kernel, it is possible to get a fully working LXD on non-Ubuntu, non-Debian distros. Support for LXD out of the box may improve in the future on some non-Ubuntu distros, but we’ll have to wait and see.
We do actively test LXD on quite a wide variety of distributions, at least all the major ones where the upstream snap package can be installed:
A number of other Linux distributions (Alpine Linux, Gentoo, …) also have their own native packages which aren’t part of that automated testing effort.
It’s also worth noting that our biggest source of users these days, isn’t coming from Ubuntu but from Chromebooks which all come with LXD as part of the Linux App feature.
That particular environment is some kind of modified Gentoo.
The opening post is really good, but the title is misleading, you can’t really compare LXC with LXD just as you can’t compare a boat with the sea.
Personally I found LXD to be an excellent enabler for LXC.
LXC is the sea (of containers), LXD just makes your experience much better, like sailing on a boat!
fan vxlan driver not work correctly on centos, so the cluster function on centos was broken with lxdfan networking.
I wrote an article summarizing the differences,
Don’t you mean, “Basically I could say there no single situation where person should prefer LXC over LXD”?
Did you (or someone else) take the opportunity to write an article about LXD container networking scenarios? I think this would be a popular and helpful topic. Network configuration in virtual machines and containers is quite challenging.
I think there is an issue regarding the “usefulness” of this post. Although it provides useful information in other areas, having lxc and lxc- distinguish between interacting with LXD vs LXC is not intuitive and should not need to have a special post explaining the difference. This post is not the first thing a new user finds or knows to look for even after many years of experience. It should really be taken into consideration to change the command line interface name from lxc to lxd, so that its not so easily confused. Sometimes making an effort to reduce mental work on users goes a long way to making substantial progress.
While I agree with you, this discussion has been there for years.
Somewhere stgraber mentioned that it wasn’t their choice, whatever that means and who makes these decisions (maybe Ubuntu/Canonical?), I don’t know.
As some people ask specifically for LXC:
- Are there any relevant feature differences between LXD and LXC?
Or can someone in theory apply everything (for example every config option, network etc.) to both as well, and it’s just more complicated with LXC?
Really ? how to configure VSwitch on LXC/LXD?
I have a question about configuring the LXD network bridge to allow LXC containers to send and receive packets over HTTP/HTTPS. For context, I have been using the two command line tools, for example I used the lxd intit command to initiate a storage pool with the default settings. As I navigated the Arch Wikis, I found myself creating yet another network bridge via the lxc-net configuration, that kinda seems unnecessary for my case since I already have the lxd daemon taking care of that. The problem I am currently deep in a rabbit hole trying to debug is being able to connect a running Arch Linux LXC container to the internet via the network bridge intermediary link to the host’s wireless device. I need some guidance navigating this rabbit hole…
Your case may be an example of confusion between LXD and LXC. If you are new to this you should use only LXD containers, which means use “lxd” and “lxc” commands, not “lxc-*” commands. If you use the default LXD network settings (with “lxd init”) and then create an LXD container (using “lxc launch …”), then it should be able to connect to the internet without any additional configuration. It will automatically use the host internet connectivity. If you continue having questions about LXD containers, you should continue this discussion on a separate topic or a different forum (such as LXD - Ubuntu Community Hub).
LXC vs LXD vs Incus
Now that Incus has been added to the mix, it will either add to the confusion or help clear things up. Incus is a fork of LXD which is currently almost identical to LXD. It replaces the “lxd” and “lxc” commands with a single “incus” command, so it will likely fix the confusion with lxc- commands. LXD, LXC and Incus are all competing technologies that do very similar things. They may have common parts, but the end user sees entirely different commands, and should not mix them, unless there are special reasons (such as migrating between them). LXC is the oldest, and it is superceded by LXD and Incus. I’m not sure why people use LXC, except for backward compatibility. New users should go directly to LXD or Incus (when Incus is released). LXD and Incus offer a higher level, better-integrated API-friendly environment. The way Incus will differ from LXD remains to be seen.