System container manager LXD has been pushed out in version 4.5, fitting the Canonical-sponsored project with the capability to work with OVN virtual networks, a way to intercept specific syscalls and native terminal device allocation.

LXD promises a “user experience similar to virtual machines but using Linux containers”. It makes use of LXC, which is an interface for the containment features of the Linux kernel that can also be used to create application containers. However LXD aims for better usability and is controllable over the network. 

The new version is the first to let operations teams use the Open Virtual Network (OVN) project for managed networks, though the approach is about to play a bigger role in the coming releases. According to the announcement post, OVN is planned to become “the basis for networks inside LXD projects in the next release”. This could prove especially useful for multi-tenancy environments, since it for example allows using the same logical subnets in multiple discrete networks.

For now, only managed bridges are allowed to take over the role of parent managed networks for the OVN use-case, but support for SR-IOV and macvlan are scheduled to hit in the next version. The setup is meant to work similarly to using a normal bridge, but of course OVN and OpenVswitch have to be present to make the thing work.

To make working with external devices a bit easier, LXD now supports native terminal device allocation. In earlier versions, it used the host’s devpts for this, which tended to lead to “confusion” with things like software doing isatty checks, which test if a file descriptor refers to a terminal. 

Another improvement comes in the form of a new database design, which is supposed to help with the handling of remote storage pools by keeping single volume entries instead of using one record for every member of the cluster. The latter approach proved to be especially problematic when creating snapshots, which are now distributed across a cluster via a hash mechanism.

Users who were wondering about ways to intercept bpf syscalls can take an initial implementation for a spin, which lets them load bpf programs tied to device cgroups from within a container. Since this isn’t without risks, a look into the documentation along with some careful planning is advised before giving it a go, though. 

Speaking of security LXD now runs forkdns and forkproxy under AppArmor confinement. This was already done for dnsmasq in v4.4, and helps to reduce the chances of these tools being maliciously used for accessing critical data or infrastructure.

A full list of changes can be found in the announcement.