Weekly status #167

Weekly status for the week of the 21st of September to the 27th of September.



There were two new features added to LXD in the past week.

Custom volume backups

Firstly you can now create custom volume backups and restore them. This is achieved by the introduction of two new CLI commands:

lxc storage volume export <pool> <volume> <backup file>
lxc storage volume import <pool> <backup file>


lxc storage volume export default myvol /home/user/myvol_backup.tar.gz
lxc storage volume delete default myvol
lxc storage volume import default /home/user/myvol_backup.tar.gz

There are also option flags on the export command to create an optimised backup format (if the the storage pool supports it, although like instance exports this means you can only import the backup into the same pool type) and to export only the volume (and not the snapshots if there are any).

Also on the back front, the storage location for backup files has been moved from $LXD_DIR/backups to $LXD_DIR/backups/instances for instance backups and $LXD_DIR/backups/custom for custom volume backups, so as to avoid any conflicts when exporting a custom volume that has same name as an instance.

OVN network restrictions

The second feature added this past week was the addition of a new project option restricted.networks.uplinks to enforce which parent networks can be used as the uplink for OVN networks. This feature requires the project to have the restricted setting set to true, and by default will prevent OVN networks from using all parent networks (those that are in the default project). The setting accepts a comma delimited list of allowed parent networks that can be used.

We have also added three user experience improvements when creating OVN networks inside projects. Firstly if you are in the non-default project then when running lxc network create we now assume you mean to create an OVN network (i.e --type=ovn) as this is the only type of network allowed in projects. Secondly when creating an OVN network, the uplink parent network is guessed based on the available networks in the default project or those specified in the project’s restricted.networks.uplinks setting. If only one network is available then it is automatically used to populate the network=<parent network> setting. If there are multiple networks available you are still required to specify it as normal. Finally when creating an OVN network in a LXD cluster, as there are no per-node settings, you now do not need to create the pending network on each node first (using the --target flag).

The sum of those changes means that inside projects one can now create a network simply using lxc network create <name> and a private OVN network will be created with an uplink network selected based on the project’s settings.

Also on the OVN networking front, we have added detection of the underlay network’s MTU size and now select automatically set the overlay network’s bridge.mtu setting when creating a new network (if not specified). The MTU detection takes into account both the MTU of the network interface used by the underlay network as well as the IP protocol used by the geneve tunnels between each node (as IPv6 packets are larger than IPv4 packets and so the maximum supported MTU for overlay networks must be smaller if IPv6 is used for the geneve tunnels).

There have also been the usual selection of bug fixes and smaller improvements:

  • Cephfs storage volume quotas were not being applied when specified on new volumes (rather than set after initial creation).
  • An issue that meant the local mount path was not created correctly for ceph volumes used inside projects when being moved has been fixed.
  • memory.swappiness wasn’t being properly detected, this is now fixed on cgroupv1 systems.
  • Project selection has been improved when using lxc remote add to automatically pick the correct project to use (when there is only one project available).


We have removed the deprecated settings of StandardOutput and StandardError from the lxc systemd units.

Contribute to LXD

Ever wanted to contribute to LXD but not sure where to start?
We’ve recently gone through some effort to properly tag issues suitable for new contributors on Github: Easy issues for new contributors

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.

  • Distrobuilder Windows support
  • Virtual networks in LXD
  • 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


  • Cherry-picked a large amount of LXD bugfixes
1 Like