Introduction

This article is useable, but not complete. What's missing,

Translation table of commands from LXC to LXD
Some more key basics of using LXD covered in LXC
Network discussion differences
Advanced Networking as a second article

In this version, you must finish the LXC and LXC with Advanced Networking before starting this article.

Intro to go here explaining LXD versus LXC and why you want to use it. For now, key bullets,

LXD sits on top of LXC and uses a higher level set of commands
REST API to orchestrates containers locally and remotely
Allows moving and copying between hosts
Takes advantage of advanced file systems (in particular ZFS)
Improves on security specifically running as unprivileged hence root inside container does not get root on host

...

Setup

Don't mix. Either install LXC or install LXD which adds LXC Underlying Components. I found installing just LXC results in components which are different than those packaged with LXD.

A key feature of virtualization technology is taking snapshots. With traditional file systems, this is expensive in terms of storage and speed. Next generation ZFS solves many of theses problems and it is recommended by Ubuntu to install and use with LXD,

sudo apt-get install bridge-utils zfsutils-linux # must be using Ubuntu 16.04 or higher.
sudo apt-get install lxd

Next configure LXD,

sudo lxd init

Pretty much first set are defaults. Will add notes about ZFS. Should explain loop device here too. Note Roderick using Azure Ubuntu 16.10 has simpler following screens,

Name of the storage backend to use (dir or zfs) [default=zfs]: zfs
Create a new ZFS pool (yes/no) [default=yes]? yes
Name of the new ZFS pool [default=lxd]: lxd
Would you like to use an existing block device (yes/no) [default=no]? no
Size in GB of the new loop device (1GB minimum) [default=15]: 15
Would you like LXD to be available over the network (yes/no) [default=no]? no
Would you like stale cached images to be updated automatically (yes/no) [default=yes]? yes
Would you like to create a new network bridge (yes/no) [default=yes]? yes
What should the new bridge be called [default=lxdbr0]? lxdbr0
What IPv4 subnet should be used (CIDR notation, "auto" or "none") [default=auto]? auto
What IPv6 subnet should be used (CIDR notation, "auto" or "none") [default=auto]? auto
LXD has been successfully configured.

Tin using Ubuntu 16.04.1

Name of the new ZFS pool [default=lxd]: lxd
Would you like to use an existing block device (yes/no) [default=no]? no
Size in GB of the new loop device (1GB minimum) [default=15]: 15
Would you like LXD to be available over the network (yes/no) [default=no]? no
Would you like stale cached images to be updated automatically (yes/no) [default=yes]? yes
Would you like to create a new network bridge (yes/no) [default=yes]? yes
What should the new bridge be called [default=lxdbr0]? lxdbr0
What IPv4 subnet should be used (CIDR notation, "auto" or "none") [default=auto]? auto
What IPv6 subnet should be used (CIDR notation, "auto" or "none") [default=auto]? auto
LXD has been successfully configured.

After saying yes to the new network bridge here are the answers to the texts graphical sub prompts,

Would you like to create a new network bridge (yes/no) [default=yes]? <yes>
What should the new bridge be called [default=lxdbr0]? <Ok>
Do you want to setup an IPv4 subnet? <yes>

This subnet was selected for your convenience and next questions have been pre-answered accodingly. Please make sure this subnet isn't already in use somewhere on your network, if it is, change it to one which isn't. If you later notice network connectivity issues, re-configure lxd and pick a different subnet.
<Ok>

# resulting IPv4 address will vary in this example using VMWare fusion it is 10.232.27.1
<Ok>
... all sorts of things... need to redo this.

If you need to reconfigure the bridge you can by using this command.

sudo dpkg-reconfigure -p medium lxd

You no longer need root, but users must be added to the lxd group to run the lxc commands.

sudo usermod -a -G lxd username

To view your bridge information.

lxc profile edit default

name: default
config: {}
description: Default LXD profile
devices:
  eth0:
    nictype: bridged
    parent: lxdbr0
    type: nic

Images

...

Cached Images in Image Store

List images currently cached in the image store. There should be none to start,

lxc image list

Image Servers

LXD has 3 image server lists by default,

Image Server LIst	Purpose	Comment
ubuntu:	Ubuntu stable images.	We'll be working with this one.
ubuntu-daily:
images:	All Linux distributions.	For example you can load a RedHat Linux alternative distrobution.

Pulling Image Server Lists

Let's look at the ubuntu: list,

lxc image list ubuntu: | less
+--------------------+--------------+--------+-------------------------------------------------+---------+----------+-------------------------------+
|       ALIAS        | FINGERPRINT  | PUBLIC |                   DESCRIPTION                   |  ARCH   |   SIZE   |          UPLOAD DATE          |
+--------------------+--------------+--------+-------------------------------------------------+---------+----------+-------------------------------+
| p (5 more)         | 6041c5e200b6 | yes    | ubuntu 12.04 LTS amd64 (release) (20161205)     | x86_64  | 156.47MB | Dec 5, 2016 at 12:00am (UTC)  |
+--------------------+--------------+--------+-------------------------------------------------+---------+----------+-------------------------------+
| p/armhf (2 more)   | c19b1fff3336 | yes    | ubuntu 12.04 LTS armhf (release) (20161205)     | armv7l  | 135.19MB | Dec 5, 2016 at 12:00am (UTC)  |
+--------------------+--------------+--------+-------------------------------------------------+---------+----------+-------------------------------+
| p/i386 (2 more)    | ce5c6821eebb | yes    | ubuntu 12.04 LTS i386 (release) (20161205)      | i686    | 139.28MB | Dec 5, 2016 at 12:00am (UTC)  |
+--------------------+--------------+--------+-------------------------------------------------+---------+----------+-------------------------------+
...

The output table from list is not very clear. I don't understand what to reference to use the "launch" command. Will put explanation here once figured out. Here is what I can tell,

Example "launch" Command Reference	Column	Note
ubuntu:16.04		This will download from the Ubuntu image server grabbing the latest 16.04 matching your machines architecture, win my case amd64.
ubuntu:6041c5e200b6	FINGERPRINT	Will specifically reference the specific image in the list.
images:centos/7		Go against the "images" image server, download the latest cantos version 7 matching your machines architecture.
images:centos/6/amd64		In this example, specifies latest version 6 and specifies the architecture.

At this point LXD is all setup and ready to use.

Spinning Up an LXD Container

Creating and starting a container can be done with one command,

lxc launch ubuntu:16.04 container01

This command does the following simultaneously,

References the ubuntu: Image Server List
1. Looks for 16.01 images
2. Matches the current architecture of the machine you are on (in my example
Checks the cache Image Store for the required image
Download (if not in Image Store) the target image
Setup Container called container01 with default settings
Install the target image into container01
Start container01

Replace launch with init if you would like the container to not start by itself.

We can see the downloaded target image,

lxc image list
+-------+--------------+--------+---------------------------------------------+--------+----------+------------------------------+
| ALIAS | FINGERPRINT  | PUBLIC |                 DESCRIPTION                 |  ARCH  |   SIZE   |         UPLOAD DATE          |
+-------+--------------+--------+---------------------------------------------+--------+----------+------------------------------+
|       | f4c9feb3e401 | no     | ubuntu 16.04 LTS amd64 (release) (20161205) | x86_64 | 143.53MB | Dec 22, 2016 at 3:37am (UTC) |
+-------+--------------+--------+---------------------------------------------+--------+----------+------------------------------+

Now instead of empty, we see the downloaded image which matches our architecture.

Also, let's look at the running container. The commands are only slightly different than using straight LXC,

lxc list
+-------------+---------+----------------------+------+------------+-----------+
|    NAME     |  STATE  |         IPV4         | IPV6 |    TYPE    | SNAPSHOTS |
+-------------+---------+----------------------+------+------------+-----------+
| container01 | RUNNING | 10.94.217.171 (eth0) |      | PERSISTENT | 0         |
+-------------+---------+----------------------+------+------------+-----------+

# Inspect the container,
lxc info container01

Name: container01
Remote: unix:/var/lib/lxd/unix.socket
Architecture: x86_64
Created: 2016/12/22 03:37 UTC
Status: Running
Type: persistent
Profiles: default
Pid: 19681
Ips:
  eth0:	inet	10.94.217.171	vethDXUYOE
  eth0:	inet6	fe80::216:3eff:fe07:69ea	vethDXUYOE
  lo:	inet	127.0.0.1
  lo:	inet6	::1
Resources:
  Processes: 26
  Disk usage:
    root: 144.32MB
  Memory usage:
    Memory (current): 23.24MB
    Memory (peak): 45.28MB
# ...

For illustration of flexiblity and preparing for the next section, we will update and setup Apache inside of container01.

Remotely execute update of the container from the host which are run as root,

lxc exec container01 apt-get update
lxc exec container01 apt-get dist-upgrade

And now we'll actually create a bash to simulate going in as a console. Notice the prompt change indicating you are root inside of container01,

lxc exec container01 bash
root@container01:~#

Now we install Apache and then exit back to our host,

apt install apache2
exit # Takes you back to your host.

Managing Containers Between Hosts

The most compelling reason to use LXD is ability to transport between containers. Setup a second LXD host on the same network. In this example we end up with two hosts,

Host	Containers	Comment
myhost01	Where we setup container01 with Apache running inside.	This will be the host we can to copy the container from also called remote host.
myhost02	Just empty at the moment.	This will be the client also called the local machine.

Expose Remote Host

In order for the local machine to connect, the remote host needs to be setup to be exposed on the network with a password. Following the instructions here, that work has been done while initializing LXD.

Configure Local Machine

myhost02 (local machine) needs to be made aware of the remote host. I suppose there are multiple ways of doing this and interested in if there is automatic discovery. For now, I'm going to use direct IP address.

lxc remote add myhost01 192.168.0.109
Certificate fingerprint: 7344c171bdc30a20e215e536a7959353b55ab6243a019819fb62385fa02d26b2
ok (y/n)? y   
Admin password for myhost01: 
Client certificate stored at server:  myhost01

Now the list has been updated to have myhost02 as an entry,

lxc remote list
+-----------------+------------------------------------------+---------------+--------+--------+
|      NAME       |                   URL                    |   PROTOCOL    | PUBLIC | STATIC |
+-----------------+------------------------------------------+---------------+--------+--------+
| images          | https://images.linuxcontainers.org       | simplestreams | YES    | NO     |
+-----------------+------------------------------------------+---------------+--------+--------+
| local (default) | unix://                                  | lxd           | NO     | YES    |
+-----------------+------------------------------------------+---------------+--------+--------+
| myhost01        | https://192.168.0.109:8443               | lxd           | NO     | NO     |
+-----------------+------------------------------------------+---------------+--------+--------+
| ubuntu          | https://cloud-images.ubuntu.com/releases | simplestreams | YES    | YES    |
+-----------------+------------------------------------------+---------------+--------+--------+
| ubuntu-daily    | https://cloud-images.ubuntu.com/daily    | simplestreams | YES    | YES    |
+-----------------+------------------------------------------+---------------+--------+--------+

Interacting with Remote Host

Interaction is exactly the same as a local container except you specify the registered lxd host name,

lxc list myhost01: # Notice myhost01 has container01 which we had setup.
+-------------+---------+----------------------+------+------------+-----------+
|    NAME     |  STATE  |         IPV4         | IPV6 |    TYPE    | SNAPSHOTS |
+-------------+---------+----------------------+------+------------+-----------+
| container01 | RUNNING | 10.94.217.171 (eth0) |      | PERSISTENT | 0         |
+-------------+---------+----------------------+------+------------+-----------+


lxc info myhost01:container01
lxc info myhost01:container01

Name: container01
Remote: https://192.168.0.109:8443
Architecture: x86_64
Created: 2016/12/22 03:37 UTC
Status: Running
Type: persistent
Profiles: default
Pid: 22659
Ips:
  eth0:	inet	10.94.217.171	vethCIJK85
  eth0:	inet6	fe80::216:3eff:fe07:69ea	vethCIJK85
  lo:	inet	127.0.0.1
  lo:	inet6	::1

Resources:
  Processes: 81
  Disk usage:
    root: 147.63MB

  Memory usage:
    Memory (current): 20.07MB
    Memory (peak): 42.18MB
# ....


# While local machine has no containers.
lxc list
+------+-------+------+------+------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------+-------+------+------+------+-----------+

Also keep this concept in mind even when referencing cached images.

Copying Containers Between Hosts

We will now copy myhost01, container01 (which is running Apache into) into myhost02. The copy is identical except no snapshots and volatile keys are regenerated. For example, the MAC address will be reset and a new host name embedded.

There are two key methods. Clone semi-live using snapshots and shutting down first.

Shutdown Approach

Log into myhost02

lxc stop myhost01:container01
# Verify container stopped
lxc list myhost01:
+-------------+---------+------+------+------------+-----------+
|    NAME     |  STATE  | IPV4 | IPV6 |    TYPE    | SNAPSHOTS |
+-------------+---------+------+------+------------+-----------+
| container01 | STOPPED |      |      | PERSISTENT | 0         |
+-------------+---------+------+------+------------+-----------+

lxc copy myhost01:container01 web01

A copy of container01 has been copied to myhost02 and given the container name web01. Everything is the same except for (...),

lxc list
+-------+---------+------+------+------------+-----------+
| NAME  |  STATE  | IPV4 | IPV6 |    TYPE    | SNAPSHOTS |
+-------+---------+------+------+------------+-----------+
| web01 | STOPPED |      |      | PERSISTENT | 0         |
+-------+---------+------+------+------------+-----------+

...

Semi-Live Approach

...

Taking Snapshots

Snapshots are a great way to backup a container before upgrading or changing any files that will break a container.

lxc snapshot container01 snapshotname01

Using lxc list will show that your container now has a snapshot.

lxc list
+-------------+---------+------+------+------------+-----------+
|    NAME     |  STATE  | IPV4 | IPV6 |    TYPE    | SNAPSHOTS |
+-------------+---------+------+------+------------+-----------+
| container01 | STOPPED |      |      | PERSISTENT | 1         |
+-------------+---------+------+------+------------+-----------+

The snapshot name can be viewed using the lxc info command

lxc info container01
Name: container01
Remote: https://192.168.0.109:8443
Architecture: x86_64
...
Snapshots:
  snapshotname01 (taken at 2017/02/02 15:33 UTC) (stateless)

To restore a snapshot

lxc restore container01 snapshotname01

Renaming a snapshot

lxc move container01/snapshotname01 container01/snaptestname01
lxc info container01
...
Snapshots:
  snaptestname01 (taken at 2017/02/02 15:33 UTC) (stateless)

Creating a container from a snapshot

lxc copy container01/snaptestname01 container02

Deleting a snapshot

lxc delete container01/snaptestname01

Moving Containers

With copy, the new container is identical in every way except no snapshots and volatile keys (ie MAC address and hostnames) will be regenerated.

Creating an exact duplicate or moving a container is a different concept but just as easy.

Current Limitations and Considerations

Consistency of host IDs which impact containers
Architecture
Baselining host patches and OS layer
No concept yet or documentation on Sparse Containers like Solaris...

Advanced Tuning of Containers

Depending on your needs there are advanced configurations options with LXD. Below are key considerations I think about,

Security
Advanced Networking
1. Tunnelling ect... as covered in LXC with Advanced Networking
2. Joining LXD host networks together
Capping Resource Utilization
Sparse Containers like Solaris...
Permissions Inside and Outside of Containers

File Transfer with Containers

Files can now be transferred from host to containers or container to container with the new lxc push and pull commands.

lxc file push sourcefile container/path/to/directory/
lxc file pull container/path/to/file directory

Reference

Initializing LXD - https://insights.ubuntu.com/2016/03/16/lxd-2-0-installing-and-configuring-lxd-212/

Official Ubuntu Documentation - https://linuxcontainers.org/lxd/getting-started-cli/

Try Online Interactive Tutorial - https://linuxcontainers.org/lxd/try-it/

Remote Container Management - https://www.stgraber.org/2016/03/19/lxd-2-0-your-first-lxd-container-312/

Possible Sparse Containers Approach - https://www.hastexo.com/blogs/florian/2016/02/21/containers-just-because-everyone-else/

Live Container Migrations - https://bobcares.com/blog/lxc-live-migration-to-minimize-business-downtime/

Page tree

5.2 LXD