From what I gather, LXD support will be removed from images.linuxcontainers.org entirely. If you look at the dates 2024/05/01 all LXD users will lose access.
1 Like
Yeah, that’s right, it’s about the images: remote for LXD users. Those who use ubuntu: or ubuntu-daily: won’t be affected, neither will users of any other software using our image servers (LXC, Incus, OpenNebula, …).
For each set of users (per timeline above), we’ll first do a week where only the top 4 most popular images will be offered then after that week all images will disappear for those users.
2 Likes
A brief update from Canonical can be found here: An update on the licence change and community image server - News - Ubuntu Community Hub
2 Likes
Just a quick note that we have updated the roll out plan a tiny bit.
Due to LXD 5.20 still not having rolled out to stable snap users, we were concerned that LXD 5.19 users would get quite surprised when they’d lose image server access completely on February 1st.
So we’ve now added an intermediate step, kicking in on the 22nd of January which will have those same users get restricted to the top images, same as what happened to LXD 5.20 users on January 1st.
So week before last, I used LXD and images:ubuntu without issue, now I come back and everything is broken, I try to switch to ubuntu: and they behave differently to the images:ubuntu and it seems like I have a lot of work ahead of me to try and fix, not something I really have time for.
I am using lxd on arch 
Also seeing similar problems… We have been using images: with LXD (LTS and non-LTS) until now. Was working on some infrastructure changes for our LXD-based CI runners and discovered this weirdness with LTS-based LXD and “normal” LXD seeing a different set of images… until I found this thread half an hour ago. 
My problem is that LXD LTS does not work for our use case, because we use functionality which got released as part of LXD 5.1 (LXD 5.1 has been released), specifically the lxd image copy --profile flag…
So I’m currently stuck with an LXD LTS which doesn’t work (because we can’t differentiate the profile being used on Ubuntu and Rocky Linux-based guests, which is needed for proper operation) but can access the images, or an LXD non-LTS which works but can’t access the required images. 
Or, we can switch to Incus which is not released as a stable version yet. I’m not sure I’m willing to put this on our CI infrastructure just yet.
Sorry of this sounds very negative, I’m just frustrated after wasting some time on this today. I know this is not the fault of LinuxContainers.org. It’s just so incredibly sad to see all the extra work and pain this incurs on a lot of people in the community. 
Incus 0.x releases are as stable and on a similar schedule to LXD 5.x releases.
The reason to stick to 0.x until the first LTS isn’t too denote a lack of stability or support but simply to avoid misaligned versions with other Linux Containers projects.
Incus will jump straight to 6.0 at the same time we release LXC and LXCFS 6.0.
2 Likes
Great point @stgraber, thanks for clarifying this part. 
We have some scripts setup which currently rely on LXD, both for use in CI but also for running LXD-based testing locally. I’ll take this further internally to discuss if we want to move our setup over to use Incus or stay on LXD (and wait on Canonical’s support for other distros, An update on the licence change and community image server - News - Ubuntu Community Hub)
Thanks for the rundown @stgraber. (I also just learned of all the Canonical LXD hi-jinx, your resignation, and now, Incus.) My question is, Is there documentation on the recommended course of action for a) existing LXD installations (in order to maintain them) and b) new installations? I was planning on a major upgrade of my LXD server to new hardware and was going to migrate containers using your excellent documentation on the topic, but now I may want to reconsider. I certainly do not want to be stuck in a no-images window (although migration may not require images?) Should I wait for Incus 1.0/6.0 and will server-server LXD-Incus migration be possible? TIA,
-brmiller
Indeed the image server restrictions will not affect any existing instance or their future transfer to another server, so you’d be fine there.
Also, assuming you’re on LXD LTS, this will be the last set of users to be blocked from accessing the image server, by which point, Incus LTS will be out.
For migrations, you have two main options:
- Directly transfer instances between LXD and Incus by adding the Incus server as a LXD remote on the source server or the LXD server as an Incus remote on the destination server. This only works using normal TLS token based authentication but is otherwise functional as the migration protocol used by both LXD and Incus is currently the same.
- Install Incus on the server, run
lxd-to-incusto move everything to Incus on that server, and then, if you want to move those instances somewhere else, you’ll be dealing with normal Incus to Incus instance migration.
To repeat a comment made earlier in this thread, if you’re already using non-LTS LXD (5.x instead of 5.0.x), then you can already switch to Incus as our 0.x as the equivalent of a LXD 5.x. It’s monthly stable releases with support available.
It’s really just the LTS builds for which you’d want to wait another couple of months before we have Incus 6.0 LTS out.
1 Like
I am pretty sure this is all you need.
I don’t think there is any reason to wait. Incus 0.5 is coming out this week, and 6.0 will come at the same time as the other LXC projects.
Incus is stable and can be used in production.
1 Like
Running LXD 5.19-8635f82 via snap. I take it this is a non-LTS version? I’ll get busy on my migration then!
Indeed, that’s not an LTS build. Supported LTS builds would be 4.0.x or 5.0.x (currently 5.0.2).
I’m running Ubuntu 23.10 (Edited, original post mistakenly said 23.04) with lxd from snap - it seems that my access to the images is now limited. Am I correct in assuming there will be no incus package for this distribution (and no snap) so my only option is to build from source?
I bet the apt packages from Zabbly will work for you.
Have you tried them yet?
Also, Ubuntu 24.04 will be out in a few months. If the packages don’t work on 23.04, I am sure they will work on 24.04.
1 Like
I bet the apt packages from Zabbly will work for you.
Looks like the packages for 22.04/jammy work on mantic as well, thanks - I have to admit I didn’t even try them, assuming they won’t work with my version of Ubuntu. So far my existing instances work with incus.
1 Like
Hey there,
Yeah, while I only provide support for those packages on Ubuntu LTS (due to the short support lifespan of non-LTS), there’s a very good chance that those packages will just work with more recent versions.
In general, you should always make sure to use the packages for the closest LTS prior to your release. So if you’re on 23.10, then you want to use the 22.04 packages, even once 24.04 packages become available.
I’ll add a note to that effect to the package repository instructions.
1 Like
Hi Thre, I migrated from LXD to Incus today, including the UI, etc. I was still seeing the dreaded images that were not available message. After I deleted the /var/cache/incus/ and restarted incus, it seemed to start working. Just putting this here incase anyone else migrating over from lxd faces the same issue.
Thanks for all the work linuxcontainers do.
2 Likes
I can confirm that they work fine on Ubuntu 23.10. I downloaded the debs from https://pkgs.zabbly.com/incus/stable/pool/main/i/incus.
A bit of a side track, but what’s the plan re. GitHub - zabbly/incus: Incus package repository moving forward? Will the stable repository there switch over to the LTS releases once they are available, or do you anticipate some new lts repository for that or something?