Heads up, planning to tag LXC/LXCFS 4.0 next week

We’re planning on releasing LXC and LXCFS 4.0 during the LXD team gathering in Frankfurt.

We’d strongly encourage those able and willing to test the current upstream versions of both lxc and lxcfs, checking that things work properly for you.

Those will be LTS versions, supported in 5 years and the prime target for our production users.
We will be releasing bugfix and security releases on those.

Note that the LXD snap in the edge channel is also built using current lxc and lxcfs, so testing that on a spare system may be useful too.


Please use this to vigorously test both LXC and LXCFS on your various workloads. Quite a lot has changed for both projects. Both now support cgroup2 workloads which is a big enough change on its own.

1 Like

Any api breaking changes being made on the way up?

Not that I’m aware of. The on-disk cgroup layout has been changed, i.e. the cgroups are named differently and the hierarchy is kept as flat as possible because of how expensive in-kernel cgroup-based scheduling is. The monitor and container have separate cgroups now. So if you’re scripting relies on on-disk cgroup layout knowledge then they’ll likely break.

All of these changes being necessary because of cgroup2.

Any comment on the issue: https://github.com/lxc/lxcfs/issues/334


Responded but there’s not really a lot we can do about it other than showing it as 0 on cgroup2 systems.

Release status?

LXCFS done, LXC planned for this week now

@stgraber @brauner congrats on the release. I see couple of commits in master since 4.0 release. Anything critical to backport or any know issues that we should hold off upgrade?

Also I have been conflicted about whether to use lxcfs on embedded systems. While I have not seen any issues by excluding lxcfs in previous releases, is there any hard dependency on lxcfs in 4.0?

No, there is no hard dependency on lxcfs.

As for backports, that commit fixing some of the cgroup logic on attach would be good to include.