4 min read
LXD, also known as ‘ Linux Daemon’ system container manager. It offers a user experience similar to virtual machines but using Linux containers instead. LXD is written in Go which is a free software and is developed under the Apache 2 license.
LXD is secure by design in terms of unprivileged containers, resource restrictions and much more. Customers can use LXD from containers on their laptop to thousands of compute nodes. WIth advanced resource control and support for multiple storage backends, storage pools and storage volumes, LXD has been well received by the community.
Features of LXD 3.8
#1 Automated container snapshots
The new release includes three configuration keys to control automated snapshots and configure how their naming convention.
- snapshots.schedule uses a CRON pattern to determine when to perform the snapshot
- snapshots.schedule.stopped is a boolean used to control whether to snapshot stopped containers
- snapshots.pattern is a format string with pongo2 templating support used to set what the name of the snapshots should be when no name is given to a snapshot. This applicable to both, automated and unnamed, manually created snapshots.
#2 Support for copy/move between projects
Users can now copy or move containers between projects using the newly available –target-project option added to both lxc copy and lxc move
#3 cluster.https_address server option
LXD 3.8 includes a new cluster.https_address option. This option will help users facilitate internal cluster communication, making it easy to prioritize and filter cluster traffic.
Until recently, clustered LXD servers had to be configured to listen on a single IPv4 or IPv6 address and both the internal cluster traffic and regular client traffic used the same address.
This new option with a write-once key holds the address used for cluster communication and cannot currently be changed without having to remove the node from the cluster.
Users can now change the regular core.https_address on clustered nodes to any address they want, making it possible to use a completely different network for internal cluster communication.
#4 Cluster image replication
LXD 3.8 introduces automatic image replication. Prior to this update, images would only get copied to other cluster members as containers on those systems request them.
The downside of this method was that if the image is only present on a single system and that system goes offline, then the image cannot be used until the system recovers.
In LXD 3.8, all manually created or imported images will be replicated on at least 3 systems. Images that are stored in the image store only as a cache entry do not get replicated.
#5 security.protection.shift container option
In previous versions, LXD had to rely on slow rewriting of all uid/gid on the filesystem whenever the container’s idmap changes. This can be dangerous when run on systems that are prone to sudden shutdowns as the operation cannot be safely resumed if interrupted partway.
The newly introduced 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.
#6 Support for passing all USB devices
All USB devices can be passed to a container by not specifying any filter, without specifying any vendorid or productid filter. Every USB device will be made visible to the container, including any device hotplugged after the fact.
#7 CLI override of default project
After reports from users that interacting with multiple projects can be tedious due to having to constantly use lxc project switch to switch the client between projects, LXD 3.8 now has made available a –project option available throughout the command line client, which lets users override the project for a particular operation.
#8 Bi-directional rsync negotiation
Recent LXD releases use the rsync feature negotiation where the source could tell the server what rsync features it’s using for the server to 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 will provide a robust migration when a newer LXD will be able to migrate containers out to an older LXD without running into rsync feature mismatches.
#9 ZFS compression support
The LXD migration protocol implements a detection and use of ZFS compression support when available. On combining with zpool compression, this can very significantly reduce the size of the migration stream.
HackerNews was buzzing with positive remarks for this release, with users requesting more documentation on how to use LXD containers. Some users also have compared LXD containers to Docker and Kubernetes, preferring the former over the latter.
In addition to these new upgrades, the release also fixes multiple bugs from the previous version. You can head over to Linuxcontainers.org for more insights on this news.
Linux 4.20 kernel slower than its previous stable releases, Spectre flaw to be blamed, according to Phoronix
An update on Bcachefs- the “next generation Linux filesystem”
The Ceph Foundation has been launched by the Linux Foundation to support the open source storage project