Stéphane Graber

Seccomp has supported a notify target for a little while now. This can be used to delegate system call handling to a userspace process. Using this, it's possible to intercept any syscall (even a non-existing one) and have it be handled by a potentially more privileged userspace process.

In LXD, we like running very safe containers. For that we use user namespaces by default, combined with both AppArmor and Seccomp policies. The result are very very safe containers but because of all that security, a number of actions just aren't possible or return odd values.

System call interception gives us a way out there as we can selectively intercept system calls such as mount, sysinfo, ebpf, ... then run them through policies and if found to be safe, run them again with elevated privileges. We have been progressively growing the list of system calls that can be handled in that way with our eventual goal to complete deprecate the use of privileged containers.

In this presentation, we'll be covering the general concept behind system call interception through the seccomp notify mechanism, some of the things to be extremely careful about and show the ones we have implemented to this day.

Want the smallest setup with fully redundant storage, networking and compute that's capable of running both containers and virtual machines? Well, this is it. This talk will go over the journey of building a 3 nodes redundant cluster meant to host public web services.

The setup boils down to Ceph for storage, OVN for networking, LXD for compute/management and some fancy BGP networking for external network redundancy. All of that running on 3 identical machines bought on eBay and some reasonable SSD/HDD bought new.

Finding cloud computing a bit too expensive for your taste? Whether it's because of storage, network or compute costs, the convenience of having instances running within seconds can easily be outweighed by the bill at the end of the month.

In this case, cloud hosting already wasn't an option and instead renting dedicated servers from the likes of Hetzner and OVH was done. This is already a lot more affordable but gets problematic when you'd like a cluster of them as fast interconnect between rental servers is uncommon and/or gets expensive quite quickly.

So wanting to move from standalone servers to a small redundant cluster, the only option that made financial sense ended up going with buying servers and finding a local co-location facility to host them. Not wanting to have to pay on-site staff or go onsite whenever something fails, the setup is quite focused on resiliency, allowing for the loss of an entire server or the loss of components from many servers without significant impact on the cluster.

The end result is effectively a tiny personal cloud, capable of running most common workloads, running on used server hardware in a colo facility with an estimated price per month, assuming a 5 years lifespan on the hardware roughly equivalent to renting just two reasonably sized machines from a dedicated server provider.

LXD is most known as a system container manager, offering a simple user experience and images for most Linux distributions. It also offers a simple REST API, network and storage management, project views and easy clustering to dozen of hosts.

Over the past few months, LXD has now grown the ability to run virtual machines alongside containers, using the exact same REST API and configuration. This presentation will cover that new feature, why it was done, where it's at now and where we're going with it, as well as provide a quick demo of setting up a small LXD cluster and running both containers and virtual machines on it.

LXD is an open source system container manager, developed by the team behind LXC, written in Go and that's been around for over 5 years now. It's widely used both on servers, running the backend of services such as Travis-CI and on everyday devices like Chromebooks. Containers are created from images with prebuilt images available for most Linux distributions.

Multiple hosts can easily be clustered together to form one large virtual host, exposing the exact same API as a single host would. Storage pools and networks can also be created and managed through LXD and resources can be segmented into projects.

With the addition of virtual machine support (through qemu), it is now possible to manage a mixed deployment of virtual machines and containers, sharing the same configuration, storage and networks. With the use of our built-in agent, the exact same operations that are normally possible against a container also become possible against virtual machines, including executing commands, transferring files, ...

Existing API clients for LXD can also now drive both containers and virtual machines without any API changes required.

LXD is a system container manager, its goal is to safely run full Linux systems at very high density and low overhead. Containers may be created from pre-made images, covering most Linux distributions, or by importing an existing virtual machine or physical system.

Advanced resource control and device passthrough is available to expose as much or as little system resources to those containers. Snapshot and backup tooling is available to safeguard those containers and data. Storage pools and networks can be used to offer a variety of storage and network options to the containers.

Management happens through a REST API with a default CLI client. LXD has built-in support for clustering which makes it trivial to scale a deployment to dozens of servers, all acting as one virtual LXD server.

In this presentation, we'll go over LXD's main features through a demonstration including usage of LXD's clustering abilities, running a variety of Linux distributions and converting existing systems to containers.

Over 2018, LXD's userbase grew significantly, partly thanks to it shipping on all Chromebooks. But other than merely getting more users, we've still been very hard at work introducing a number of exciting new features.

The main one of those has certainly been LXD clustering which released alongside our second LTS release back in April.

We've also been adding a wide variety of storage related features, simplified networking, better support for GPUs, ...

In this presentation, we'll go over the past year and highlight the most interesting changes, then look a bit further for what to expect in 2019.

System containers such as those that LXD can run are effectively Linux systems but without a Linux kernel. So wouldn't it be nice to just be able to take an existing physical system or virtual machine and transfer it over the network to a LXD host, then boot it as a container without needing any manual transfer process?

This is what I'll be demoing in this short talk, using a small piece of software that uses the LXD migration API to stream a system over the network to a remote LXD server, turning it into a container.

Introduction to the containers devroom.

LXD is a modern container manager and REST API written by LXC upstream and built on top of the LXC library. Its goal is to offer the same features you would expect from a Virtual Machine hypervisor but using Linux Containers rather than VMs. This makes it a very light and fast alternative to virtual machines and an ideal option when running Linux in both guest and host. Some of the main features include: - User friendly command line experience - Entirely built on top of a REST API (easy remote management) - Fine grained resource management for containers - Support for device passthrough (network, disk, unix char devices and unix block devices) - Helpers to ease GPU and USB passthrough - Network management API (create bridges, setup tunnels between hosts, ...) - Storage management API (create storage pools for containers, use any of btrfs/lvm/zfs/directory backends) - Support for live migration (through CRIU) The presentation will go over what LXD is in greater details, include a brief overview of its API and be followed by a demonstration of its various features. LXD is available for Debian users through snapd with native packaging being worked on. A number of Debian images for LXD are built and published daily.

Introduction to LXD, the container lightervisor by its project leader.

LXD is a container management tool built on top of LXC and offering a REST API to manage and interact with multiple container hosts over the network.

This talk will go over the main features of LXD, a pretty thorough demonstration of its abilities, a run through the work currently being done and end with questions.

LXD is a project which began a bit over a year ago, by the same team who built LXC.

It's building on top of the very stable LXC library and adds a whole network layer to it through a simple and clean REST API.

It's user experience was rethought from the ground up, favoring security and reliability, using every single kernel security feature available to provide a safe, yet extremely fast environment. Reliability is achieved through extended error handling and the use of container images in place of locally built container templates.

LXD focuses on infrastructure containers, that is, containers running a full Linux distribution exactly as you would in a virtual machine. It doesn't know about nor care about application containers (docker, rocket, ...). Those technologies are great to manage micro-services and are a good way to distribute software, as such they make a lot of sense, inside a LXD container.

More information on the LXD project can be found at: https://linuxcontainers.org/lxd The code may be found at: https://github.com/lxc/lxd And a fully feature, interactive demo of its capabilities here: https://linuxcontainers.org/lxd/try-it