The LXD team is very excited to announce the release of LXD 3.22!

This release comes with quite a few improvements for containers and virtual machines alike. The addition of the nftables support also makes it much more compatible with some modern Linux distributions that have now switched away from xtables.

Somewhat separate from this release, we have also now added quite a few VM images to our image server. You’ll now find VM images for Ubuntu, Debian, Fedora, CentOS, OpenSUSE and ArchLinux.



Resource limits for projects

Projects grew a new set of configuration keys that can be used to restrict the amount of resources used by a project:

limits.containers limits.virtual-machines limits.cpu limits.memory limits.processes There are a few special restrictions that apply when using the limits for cpu, memory or processes. More details can be found here:

nftables backend for firewalling

Recent LXD releases introduced an internal abstraction layer for firewalling requests. This covers anything from LXD networks firewalling and NAT, proxy devices for containers, IP and MAC filtering, …

With this release of LXD, a new backend, nft joins our existing xtables implementation. On startup, LXD will detect which is currently in use by your system and then go on using that one.

The existing backend can be found in lxc info.

stgraber@castiana:~$ lxc info | grep firewall: firewall: nftables Container: Hugepages in unprivileged containers

It is now possible to allow unpriivleged containers access to hugepages. This is done with two things:

Mount interception of the hugetlbfs filesystem New limits for hugepages A configuration on x86_64 would look something like:

security.syscalls.intercept.mount=true security.syscalls.intercept.mount.allowed=hugetlbfs limits.hugepages.1MB=1GB Note the the allocation of hugepages is in addition to whatever regular memory the container already has access too. Also note that similar to other limits, not setting the limit will allow an unlimited amount of hugepages to be used.

root@edfu:~# lxc init ubuntu:18.04 c1 Creating c1 root@edfu:~# lxc config set c1 security.syscalls.intercept.mount true root@edfu:~# lxc config set c1 security.syscalls.intercept.mount.allowed hugetlbfs root@edfu:~# lxc config set c1 limits.hugepages.2MB 1GB root@edfu:~# lxc start c1

root@edfu:~# lxc exec c1 bash root@c1:~# mkdir /dev/hugepages ; mount -t hugetlbfs hugetlbfs /dev/hugepages root@c1:~# ls -lh /dev/hugepages/ total 0 VM: Support for 9p disk devices

One long awaited feature of LXD virtual machines was the ability to pass arbitrary paths from the host into the virtual machine.

LXD 3.22 now supports that through a combination of logic in LXD itself and in the agent.

This can then be used by both containers and virtual machines through profiles.

root@edfu:~# lxc profile create shared-data Profile shared-data created root@edfu:~# lxc profile device add shared-data home disk source=/home path=/mnt/home Device home added to shared-data root@edfu:~# lxc profile device add shared-data srv disk source=/srv path=/mnt/srv Device srv added to shared-data

root@edfu:~# lxc launch images:fedora/31 f31-ctn -p default -p shared-data Creating f31-ctn Starting f31-ctn root@edfu:~# lxc launch images:fedora/31 f31-vm -p default -p shared-data –vm Creating f31-vm Starting f31-vm

root@edfu:~# lxc exec f31-ctn – df -ah | grep /mnt /dev/sdb1 220G 12G 197G 6% /mnt/home /dev/sdb1 220G 12G 197G 6% /mnt/srv root@edfu:~# lxc exec f31-vm – df -ah | grep /mnt lxd_home 220G 12G 197G 6% /mnt/home lxd_srv 220G 12G 197G 6% /mnt/srv VM: File templating support

The template files in images are now used for virtual machines too. The templates are rendered by LXD on the host using the metadata available in the configuration, the rendered files are then passed on to the agent for installation into the virtual machine.

Adding templates to custom images now works identicallty to containers and can be seen in use by our own VM images on the images: remote.

Mike Halvorsen

Mike Halvorsen has been building things with open source software since 1997. As an early adopter of linux container technology, Mike has deep experience using linux containers at scale.