Weekly status #158

Weekly status for the week of the 20th of July to the 26th of July.



This past week has been focused on networking.

We have added two new network types of macvlan and sriov. These pseudo-networks can be created using:

lxc network add <net name> --type=<net type> parent=<physical NIC name>

They can then be used as the argument for the network option for adding macvlan and sriov NIC types. E.g.

lxc config device add <instance> eth0 nic network=<net name>

This will then add a NIC of the associated network’s type and use the network’s parent property as the parent of the instance’s NIC.

Why is this useful? When in a clustered environment, LXD networks support the concept of per-node configuration keys. Until now the only per-node network key was for bridge network types, called bridge.external_interfaces. However now, with the addition of macvlan and sriov network types, we have added the parent option as a per-node key. This, combined with the ability to specify a network for NICs of the same types, means it now becomes possible to use macvlan and sriov type NICs in a clustered environment where the physical parent network interfaces are named differently on each node.

A full example:

lxc network add mynet --type=macvlan parent=enp3s0 --target=node1
lxc network add mynet --type=macvlan parent=enp4s0 --target=node2
lxc network add mynet --type=macvlan parent=enp5s0 --target=node3
lxc network add mynet --type=macvlan
lxc init images:ubuntu/focal c1
lxc config device add c1 eth0 nic network=mynet name=eth0

The container will then use the correct physical parent interface for the node it is actually running on, either enp3s0, enp4s0 or enp5s0.

As part of this work we have also been improving the editing of network configuration in the clustered environment.

Bridge networking also saw some improvements. We are now generating a stable MAC address for bridge interfaces which is stored in a volatile configuration key. This means that bridge interfaces will get the same MAC address between reboots of the LXD host. This also means that the bridge interface’s MAC address will not change when an instance is connected to it (which happens in some cases if the MAC address is considered to be lower then the current bridge interface’s MAC address).

However there is a scenario that we are still generating a per-node random MAC address for bridge interfaces, and this is when the bridge.external_interfaces setting is in use with both ipv4.address and ipv6.address set to none. This is because we cannot be sure that the bridge interface on multiple nodes (in a clustered environment) is not connected to the same physical network segment. And using a stable MAC in that scenario would cause conflicts.

Other developments this past week include adding support for using LXD Go packages in other projects when using Go modules and vendoring.


In LXC this past week, there have been improvements to the AppAmor profile to allow read only remount of /proc/sys/kernel/random/boot_id as well as removal of SELinux security_context_t usage as it has been deprecated.

We have also been making changes to the entire LXC tree to hide unnecessary symbols.

Upcoming events

  • Nothing to report this week

Ongoing projects

The list below is feature or refactoring work which will span several weeks/months and can’t be tied directly to a single Github issue or pull request.

  • Virtual machine support
  • Distrobuilder Windows support
  • Various kernel work
  • Stable release work for LXC, LXCFS and LXD

Upstream changes

The items listed below are highlights of the work which happened upstream over the past week and which will be included in the next release.




  • Nothing to report this week


  • Nothing to report this week

Distribution work

This section is used to track the work done in downstream Linux distributions to ship the latest LXC, LXD and LXCFS as well as work to get various software to work properly inside containers.


  • Nothing to report this week


  • Updated to Seccomp 2.5.0