Weekly status #237


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

Introduction

This past week we have merged the Event Hub feature from our LXD roadmap, as well as making significant progress on our File Streaming API roadmap item. Additionally we have added the ability for the VM lxd-agent to rename network interfaces inside the guest using the LXD device config names.

Additionally @stgraber has created a video on the new token based authentication for LXD remotes.

https://www.youtube.com/watch?v=4iNpiL-lrXU

LXD

New features:

  • Event Hub - added the ability to specify certain cluster members act as “hubs” for LXD event streams. The purpose for this is to reduce intra-member connections and interrupts in larger clusters caused by the full-mesh connections opened between every member. This can be achieved by adding the event-hub role to at least 2 members in a cluster. This will reorganise the cluster member event connections so that rather than every member connecting to every other member (“full-mesh” mode) to instead have each non-event-hub member connect to every event-hub member. These event-hub members will then redistribute the events they receive to every other event-hub member (which in turn will distribute the events to their non-hub member listeners).
  • VM lxd-agent network interface rename and MTU applied from LXD device config.

Improvements:

  • File Streaming API: Replace forkfile with Go implementation of SFTP - this should instance file operation performance (especially when making multiple requests in quick succession) by avoiding the need to fork a new process for each file operation, and instead maintain a persistent process inside the instance that can provide access to the instance’s filesystem and expose that over an SFTP connection back to the LXD server.
  • VM detect io_uring support in QEMU and use it for improved performance.
  • Harden calls to image unpackers by leveraging AppArmor profiles running the unpacker commands.

Bug fixes:

  • Further refinements on device name validation to relax the recently device name restrictions added to allow ., / and : in device names, and several fixes to handle escaping / in names for subsystems that do not support them.
  • Support --allow-inconsistent flag when refreshing an instance.
  • Fixed static DHCP allocation reservation bug when using multiple NICs inside a single instance connected to the same parent bridge.
  • Fixed logic problem in matching Entity ID when resolving an deleting persistent warnings.

LXC

Bug fixes:

  • Ensure container_ttys environment variable is set correctly.
  • Fixes to modify cgroup2 attach logic to support recent kernel permission checks.

Dqlite (Go bindings)

Improvements:

  • Adds WithUnixSocket to app to allow setting a specific socket path.

LXD Charm

Improvements:

  • Add prometheus2 charm to all-in-one bundle.
  • Added grafana-dashboard support.

YouTube videos

The LXD team is running a YouTube channel with live streams covering LXD releases and weekly videos on different aspects of LXD. You may want to give it a watch and/or subscribe for more content in the coming weeks.

https://www.youtube.com/lxd-videos

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 planned currently.

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.

  • Reworked cluster event distribution mechanism
  • New unified P2C/P2V tooling
  • Token based remote add
  • Network ACL log API
  • Prometheus & grafana integration with the LXD charm
  • 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.

LXD

LXC

LXCFS

  • Nothing to report this week

Distrobuilder

  • Nothing to report this week

Dqlite (RAFT library)

  • Nothing to report this week

Dqlite (database)

  • Nothing to report this week

Dqlite (Go bindings)

LXD Charm

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.

Ubuntu

  • Nothing to report this week

Snap

  • lxd: Cherry-pick upstream bugfixes
  • lxc: Cherry-pick upstream bugfixes
  • qemu: Build with io_uring
2 Likes

Above mentioned network mesh might work with very limited number Hosts, all in one rack.or even immediate neighbours.
Though it is not easy cross connecting servers by those set of tp cables and even more difficult when hosts in some distance.
We have implemented a private network throughout data center with dedicated 10g/40g switches.

Problem is, lxd either listening on all ( ip4/22, ip6/48) which is not desirable or only one dedicated ip.
So, servers need to go through congested public net, despite being privately connected as well.
Lxd listen on multiple defined IPs or NIC based would solve that problen.

What traffic are you referring to? LXD API traffic?

lxd core.https.address
takes either 1 dedicated ip address or wildcard.
Wildcard binds on *:8443 causes an open port an all available host NIC and IPs.

In order to enable neighbor hosts communicating privately as well as allowing public secure connections:

Choice of NIC:
lxd core.https.address eno1:8443,eno4:8443

or multiple selected IP’s
lxd core.https.address 192.168.1.1:8443,127.0.0.1:8443,8.8.8.8:8443
Which limits LXD API public listen address.

In a cluster I believe you can set the cluster.https_address setting to a different IP (and thus network) than the core.https.address and that the former would be use for private intra-cluster communication.

As for binding core.https.address onto multiple addresses (and not the wildcard) please could you log a feature request at https://github.com/lxc/lxd/issues

https://github.com/lxc/lxd/issues/9996