LXD 3.8 has been released

Introduction

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

This is the last release for 2018 and is a pretty feature packed one, improving on a lot of previously introduced features.

Enjoy!

New features

Automated container snapshots

Three configuration keys were introduced to control automated snapshots and configure how they will be named.

  • snapshots.schedule takes a CRON pattern to determine when to perform the snapshot
  • snapshots.schedule.stopped is a boolean used to control whether to snapshot stopped containers too
  • snapshots.pattern is a format string with pongo2 templating support used to set what the name of the snapshots should be when none is specified. This applies both to automated snapshots and to manually created snapshots where no name is provided.

Support for copy/move between projects

A new --target-project option has been added to both lxc copy and lxc move, making it possible to copy or move containers between projects.

stgraber@castiana:~$ lxc move test1 test1 --target-project blah
stgraber@castiana:~$ lxc list --project blah
+-------+---------+------+------+------------+-----------+
| NAME  |  STATE  | IPV4 | IPV6 |    TYPE    | SNAPSHOTS |
+-------+---------+------+------+------------+-----------+
| test1 | STOPPED |      |      | PERSISTENT |           |
+-------+---------+------+------+------------+-----------+

cluster.https_address server option

Up till now, clustered LXD servers had to be configured to listen on a single IPv4 or IPv6 address with both internal cluster traffic and regular client traffic all using that same address.

LXD 3.8 changes that by introducing a new cluster.https_address option.
This write-once key holds the address used for cluster communication and cannot currently be changed without having to remove the node from the cluster.

With this separate key in place, it’s now possible to change the regular core.https_address on clustered nodes to any address you want, including to wildcard patterns like :8443.

This makes it possible to use a completely different network for internal cluster communication, making it easy to prioritize and filter cluster traffic.

Cluster image replication

Another improvement for our cluster users is the introduction of automatic image replication.
Prior to LXD 3.8, images would only get copied to other cluster members as containers on those systems request them.

While good for performance, bandwidth and disk usage, this had the obvious downside that if the image is only present on a single system and that system goes offline, then there is no way for that image to be used until the system recovers.

LXD 3.8 changes this by having all manually created or imported images be replicated on at least 3 systems. Images that are stored in the image store only as a cache entry do not get replicated.

The behavior can be configured through cluster.images_minimal_replica with 3 being the new default behavior, 1 being the previous behavior and -1 used to replicate on all cluster members.

security.protection.shift container option

Until such time as we get shiftfs into Linux distributions and land support for it in LXD, LXD has to rely on slow rewriting of all uid/gid on the filesystem whenever the container’s idmap changes.

This can be a dangerous operation when run on systems that are prone to sudden power less or shutdown as this operation cannot be safely resumed if interrupted partway.

When set, the new security,protection.shift configuration option will prevent any such remapping, instead making any action that would result in one fail until the key is unset.

Support for passing all USB devices

Similar to how you can pass all GPUs to a container by not specifying any filter, it is now possible to do the same with USB devices by not specifying any vendorid or productid filter.

In such cases, every USB device will be made visible to the container, including any device hotplugged after the fact.

CLI override of default project

Many users reported that interacting with multiple projects can be tedious due to having to constantly use lxc project switch to switch the client between projects. This is especially true when all you want to do in a particular project is a simple action like starting a container.

LXD 3.8 now has a --project option available throughout the command line client, which lets you override the project for a particular operation.

stgraber@castiana:~$ lxc project list
+-------------------+--------+----------+---------+
|       NAME        | IMAGES | PROFILES | USED BY |
+-------------------+--------+----------+---------+
| blah              | NO     | NO       | 2       |
+-------------------+--------+----------+---------+
| default (current) | YES    | YES      | 14      |
+-------------------+--------+----------+---------+

stgraber@castiana:~$ lxc list test
+-------+---------+------+------+------------+-----------+
| NAME  |  STATE  | IPV4 | IPV6 |    TYPE    | SNAPSHOTS |
+-------+---------+------+------+------------+-----------+
| test1 | STOPPED |      |      | PERSISTENT | 0         |
+-------+---------+------+------+------------+-----------+

stgraber@castiana:~$ lxc list test --project blah
+-------+---------+------+------+------------+-----------+
| NAME  |  STATE  | IPV4 | IPV6 |    TYPE    | SNAPSHOTS |
+-------+---------+------+------+------------+-----------+
| test2 | STOPPED |      |      | PERSISTENT | 0         |
+-------+---------+------+------+------------+-----------+

Bi-directional rsync negotiation

Recent LXD releases have introduced rsync feature negotiation where the source could tell the server what rsync features it’s using so that the server can match them on the receiving end.

LXD 3.8 introduces the reverse of that by having the LXD server indicate what it supports as part of the migration protocol, allowing for the source to restrict the features it uses.

This should provide very robust migration in the future where a newer LXD will be able to migrate containers out to an older LXD without running into rsync feature mismatches.

ZFS compression support

Another improvement to our migration protocol is the detection and use of ZFS compression support when available.

When combined with zpool compression, this can very significantly reduce the size of the migration stream.

Bugs fixed

  • client: convert EventListener to use api.Event
  • client: Fix crash on missing ProgressTracker
  • doc: Add kernel.keys.maxkeys to production-setup
  • doc: Add project documentation
  • doc: Updated documentation of /cluster/members/ to have correct keys
  • i18n: Update translations from weblate
  • i18n: Update translation templates
  • lxc/image: Fix rootfs file handling on snap
  • lxc/import: gzip is the default
  • lxc/project: Check existence on switch
  • lxd: Finish converting events to api.Event
  • lxd: Fix AppArmor cache policy version check
  • lxd: Handle AppArmor policy cache directory
  • lxd/cluster: Tweak error messages
  • lxd/containers: Drop needless function
  • lxd/containers: Fix snapshot URLs in projects
  • lxd/containers: Hide duplicate log entries
  • lxd/containers: Improve hwaddr retry logic
  • lxd/containers: Properly clear static leases
  • lxd/containers: Respect optional=true for disks
  • lxd/db: Avoid un-needed query on container move
  • lxd/db: Fix typo in existing docstring
  • lxd/db: Fix unit test not actually checking error
  • lxd/db: Make ContainerSetState use single query
  • lxd/images: Fix bad project handling
  • lxd/init: Better handle disk sizes
  • lxd/init: Checks if a zfs storage pool or dataset exists
  • lxd/init: Fix typo
  • lxd/migration: Cleanup feature negotiation
  • lxd/migration: Fix CRIU rsync option negotiation
  • lxd/migration: Fix rsync project prefix
  • lxd/migration: Fix shutdown race
  • lxd/migration: Remove leftover debugging
  • lxd/migration: Re-spawn proxy devices
  • lxd/migration: Simplify MigrationSink
  • lxd/migration: Simplify MigrationSource
  • lxd/migration: Simplify StorageMigrationSink
  • lxd/networks: Fix projects in dnsmasq.hosts
  • lxd/projects: Add config validation
  • lxd/projects: Fix copy of snapshots
  • lxd/proxy: Improve shutdown code
  • lxd/storage: Fix broken error handling
  • lxd/storage: Fix check for custom volume restore
  • lxd/storage: Fix custom volume copies
  • lxd/storage: Fix more project copy issues
  • lxd/storage: Fix snapshot migration with projects
  • lxd/storage: Freeze containers during rsync
  • lxd/storage: user_subvol_rm_allowed for btrfs
  • lxd/storage/btrfs: Fix project migrations
  • lxd/storage/btrfs: Tweak errors
  • lxd/storage/ceph: Fix copies within project
  • lxd/storage/ceph: Fix project migration
  • lxd/storage/dir: Don’t fail when quota are set
  • lxd/storage/dir: Fix project snapshot symlink
  • lxd/storage/lvm: Fix project handling
  • lxd/storage/lvm: Run pvremove on VG deletion
  • lxd/storage/zfs: Add zfsPoolVolumeExists
  • lxd/storage/zfs: Detect tool version on Ubuntu
  • lxd/storage/zfs: Fix missing dir on copy
  • lxd/storage/zfs: Fix project copies
  • lxd/storage/zfs: Fix project migrations
  • lxd/storage/zfs: Fix setting quotas on project
  • shared: Fix import order
  • shared: Fix windows cert handling
  • shared/idmap: Workaround Go tip change
  • shared/termios: Add shim for non-cgo builds
  • storage/zfs: Fix arguments in function call
  • tests: Always pass -w to iptables
  • tests: Bump size to 120MB for btrfs
  • tests: Fix leftover file
  • tests: Improve live-migration tests
  • tests: Test migration in projects
  • test: Support AppArmor policy cache directory

Try it for yourself

This new LXD release is already available for you to try on our demo service.

Downloads

The release tarballs can be found on our download page.

4 Likes

Great news!

I’m on LXD snap version 3.7 now.
What is the proper way to upgrade to 3.8?

Thank you

If you run the following,

$ snap info lxd
name:      lxd
summary:   System container manager and API
publisher: canonical
contact:   https://github.com/lxc/lxd/issues
license:   Apache-2.0
description: |
  LXD is a system container manager.
  
  With LXD you can run hundreds of containers of a variety of Linux
  distributions, apply resource limits, pass in directories, USB devices
  or GPUs and setup any network and storage you want.
  
  Pre-made images are available for Ubuntu, Alpine Linux, ArchLinux,
  CentOS, Debian, Fedora, Gentoo, OpenSUSE and more.
  
  LXD is network aware and all interactions go through a simple REST API,
  making it possible to remotely interact with containers on remote
  systems, copying and moving them as you wish.
  
  Want to go big? LXD also has built-in clustering support,
  letting you turn dozens of servers into one big LXD server.
  
  LXD containers are lightweight, secure by default and a great
  alternative to running Linux virtual machines.
  
  Supported options for the LXD snap (snap set lxd [<key>=<value>...]):
   - criu.enable: Enable experimental live-migration support [default=false]
   - daemon.debug: Increases logging to debug level [default=false]
   - daemon.group: Group of users that can interact with LXD [default=lxd]
   - ceph.builtin: Use snap-specific ceph configuration [default=false]
   - openvswitch.builtin: Run a snap-specific OVS daemon [default=false]
  
  LXD documentation can be found at: https://lxd.readthedocs.io
snap-id: J60k4JY0HppjwOjW8dZdYc8obXKxujRu
channels:                                
  stable:        3.7         (9664) 53MB -
  candidate:     3.8         (9786) 54MB -
  beta:          ↑                       
  edge:          git-ae0a670 (9788) 54MB -
  3.0/stable:    3.0.3       (9663) 53MB -
  3.0/candidate: 3.0.3       (9663) 53MB -
  3.0/beta:      ↑                       
  3.0/edge:      git-18c9b88 (9673) 53MB -
  2.0/stable:    2.0.11      (8023) 28MB -
  2.0/candidate: 2.0.11      (8023) 28MB -
  2.0/beta:      ↑                       
  2.0/edge:      git-c7c4cc8 (9257) 26MB -
$ 

you will notice that, currently, the 3.8 version is in the candidate channel.
When the 3.8 version gets into the stable channel, your LXD will get updated automatically within a day.
In previous new versions, the new version would get released to the stable channel early next week (Monday or Tuesday as long there have been no issues).

If, however, you really want to try now the candidate version of 3.8, you can switch your LXD snap installation to the candidate channel and therefore get the chance to test it before everyone else.
However, if you do that, you will need to remember next week to switch back to the stable channel when the stable version becomes 3.8.

$ lxc version 
Client version: 3.7
Server version: 3.7
$ snap switch lxd --channel=candidate
"lxd" switched to the "candidate" channel
$ snap refresh
Download snap "lxd" (9786) from channel "candidate"                            /
Download snap "lxd" (9786) from channel "candidate"           50% 3.39MB/s 4.25s
Fetch and check assertions for snap "lxd" (9786)                               -
Stop snap "lxd" services                                                       \
Copy snap "lxd" data                                                           -
Setup snap "lxd" (9786) security profiles                                      |
Start snap "lxd" (9786) services                                               \
Remove snap "lxd" (9564) from the system                                       /
lxd (candidate) 3.8 from Canonicalâś“ refreshed
$ lxc version
Client version: 3.8
Server version: 3.8
$ 

Above I pressed Enter a few times in order to capture the snap package messages and show them here. Normally they all appear on the same line.

1 Like

Plan is to release 3.8 to stable on Monday as we usually do with new releases to allow for a bit of testing.

Ok, I will probably wait until 3.8 gets to the stable channel.

Thankls for the explanation.

Awesomeness, this fixed my copy issue I was having.

The LXD 3.8 snap is now in the stable track.
This also includes updating the bundled liblxc up to 3.1 which we just announced.

If anyone has been tracking the candidate channel in order to get LXD 3.8 a few days earlier,
you can now switch back to the stable channel.

In the following I switch back to the stable channel because LXD 3.8 has been released to the stable channel (you can verify with snap info lxd). After the switch, I run snap refresh in order to refresh any pending snaps. There are no refreshes pending which means that LXD 3.8 in the candidate channel is the identical package that was released in the stable channel.

$ snap switch lxd --channel=stable
"lxd" switched to the "stable" channel
$ snap refresh
All snaps up to date.
$ 

I assume it does not handle retention?

@monstermunchkin is currently working on adding an expiry field to snapshots with a configurable default expiry, this should let you manage snapshot retention without having to run a separate API client to clean things up.

1 Like

Awesome!