No swap in containers after upgrading to Jammy

Hi team.

I am experiencing issues with swap within containers after upgrading from Ubuntu 20.04 Focal to 22.04 Jammy. I am using the default AWS cloud images (ami-0300dc03c13eb7660 and ami-0e040c48614ad1327).

When I create a new 20.04 instance, setup swap and perform the usual setup via lxd init and then create a container, the container will have usable swap.

However, when I create a 22.04 instance and perform the same steps as above then the container will have no usable swap.

I have already googled extensively regarding this but the only semi-related discussions I could find were regarding swap account kernel flags, which is not what I am after.

I was even attempting to migrate my containers back to a 20.04 host, but this doesn’t seem to work due to the incompatibility of the LXD versions.

Is there anything obvious that I am missing?

Thank you in advance.

See https://github.com/lxc/lxcfs#swap-handling

The likely difference between your systems is the use of cgroup2 on 22.04.
The swap is still present and will be used, but its reporting is the issue.

Hi Stephane. Thank you for your response. The only reason that we started noticing this is that we suddenly had an influx in OOM during peak hours, before the upgrade this would have usually been prevented with temporary swapping.

In the article you linked it states:
If the swappiness is set to 0 and there is no SWAP usage, no SWAP is reported. However if there is SWAP usage, then a SWAP device of the size of the usage (100% full) is reported. This provides adequate reporting of the memory consumption while preventing applications from assuming more SWAP is available.

Does this apply when swappiness is set to 0 on host and/or container? I am happy to perform some testing with this, but as I mentioned I never saw any swap usage within containers, always 0% and then received OOM messages as soon as RAM is full, still at 0% swap in the container.

EDIT: Would it be worth downgrading to CGROUPS v1 via systemd.unified_cgroup_hierarchy=0 kernel flag?

Downgrading to cgroup1 would definitely be interesting to try.