True that. ^
Canonicals support (on discussion forum mainly) not at par.
I am back to LXD after long long time. A client requirement. They want LXD for now. (told them about incus already).
1 What are the odds of getting any (minimum) support here around LXD here? Not like in depth but about general stuff.
2 Also, I understand there is migration possible from LXD to incus. How similar is incus with LXD (I understand it still uses LXC) Just trting to undrstand how much efforts will be needed to actual migration for full configured LXD system. Assuming we are using Ubu 20 LTS. Incus comes via apt?
I would consider Incus to be a continuation of LXD. What you had prior, is obviously still present in Incus. In addition, Incus has new features including the recent support for OCI images (i.e. Docker). That is, you can run Docker images directly through Incus.
In Incus, the command-line utility is incus (instead of the confusing lxc).
In Incus, the admin functions are available under the incus admin command. Hence, you run sudo incus admin init to perform the initialization.
You probably want to read testimonials. Here’s mine, Migrating to Incus from LXD – Mi blog lah!
Migration is really easy. It is good if you pin your LXD package so that it stays at a stable version. That is, if you are on latest/stable, switch to a suitable numbered stable version (i.e. 5.20/stable). This would depend on what you are running on latest/stable. You switch with something like snap refresh lxd --channel 5.21/stable and in that case you do not upgrade by accident to a diverged version of LXD (like version 6.x).
For Debian/Ubuntu, Incus is available as an apt/DEB package. You can find the stable version of Incus in the repositories of Ubuntu 24.04 and Debian 12 (or newer for both). For prior versions of Debian/Ubuntu, or if you want to try the very latest version, you can use the Zabbly repositories, GitHub - zabbly/incus: Incus package repository (also referenced in the official documentation).
You will get support for Incus and LXC here, and other software under the umbrella of Linux Containers.
That’s what we’ve been doing for the past year, but we’re not doing that anymore.
Any topic about LXD gets closed now.
You’re obviously welcome to reproduce anything that they may be doing with LXD on Incus first, then ask questions about that, but we won’t be answering anything about LXD directly at this point.
The lxd-to-incus tool handles migrating from LXD up till version 5.21.x (LTS), the tool detects the use of any LXD feature which was removed from Incus, mostly things like MAAS integration, core.trust_password, Ubuntu Fan networking, …
Incus is a fork of LXD so a lot of the logic, behavior, … is the same, the migration is generally quite seamless with the main change being that the CLI is now incus rather than lxc and a couple of commands have changed, specifically incus admin init rather than lxd init, incus snapshot XYZ and incus storage volume snapshot XYZ.
Incus can be installed as a deb on Ubuntu 20.04, 22.04 or 24.04 LTS.
Canonical drove away the open-source community and developers when they changed the license for lxd, which is why you won’t find much clue in the lxd forums.
You can of course pay Canonical for support. Perhaps that was their plan all along - I don’t know. I’ve never used Canonical commercial support, so I can’t comment on its quality.
For me, pragmatically the huge benefit of incus over lxd is the fact that it doesn’t install via snapd. Running a containerisation system inside (effectively) another containerisation system is not a great idea. I’ve had enormous problems with lxd inside snap with ZFS, because snapd forces its own namespaces on every application. I also don’t want snapd automatically upgrading key system components behind my back at random times, although thankfully that can now be disabled. And snapd forces a different way of managing applications rather than the standard systemctl [start|stop|status] foo.
Switching from lxd to incus has allowed me to remove snapd completely, which is a huge benefit for server systems. snapd is probably fine for desktop applications, where you want to sandbox them to the hilt, but not so much for system tools.
The migration, from lxd 5.21 to incus 6.0, was seamless apart from having to unset one obsolete lxd setting (which the migration tool told me I needed to do)
