lxd server guide section
Simon Quigley
tsimonq2 at ubuntu.com
Wed Mar 30 22:42:47 UTC 2016
I'll find a way to add a signed-off-by and push for you, if you don't
mind. Thanks again! :)
On 03/30/16 17:22, Serge Hallyn wrote:
> Attached is the diff to C/serverguide/virtualization.xml in lp:serverguide.
> I've also tossed it into my same git tree as serverguide.lxd.diff. (bzr
> push is failing for me and the sun finally came out so I'm not dealing with
> that now :)
>
> === modified file 'serverguide/C/virtualization.xml'
> --- serverguide/C/virtualization.xml 2016-02-07 19:02:01 +0000
> +++ serverguide/C/virtualization.xml 2016-03-30 21:52:58 +0000
> @@ -771,6 +771,880 @@
>
> </sect1>
>
> + <sect1 id="lxd" status="review">
> + <title>LXD</title>
> +
> + <para>
> + LXD (pronounced lex-dee) is the lightervisor, or lightweight container
> + hypervisor. While this claim has been controversial, it has been <ulink
> + url="http://blog.dustinkirkland.com/2015/09/container-summit-presentation-and-live.html">quite
> + well justified]</ulink> based on the original academic paper. It also
> + nicely distinguishes LXD from <ulink
> + url="https://help.ubuntu.com/lts/serverguide/lxc.html">LXC</ulink>.
> + </para>
> +
> + <para>
> + LXC (lex-see) is a program which creates and administers "containers" on a
> + local system. It also provides an API to allow higher level managers, such
> + as LXD, to administer containers. In a sense, one could compare LXC to
> + QEMU, while comparing LXD to libvirt.
> + </para>
> +
> + <para>
> + The LXC API deals with a 'container'. The LXD API deals with 'remotes,'
> + which serve images and containers. This extends the LXC functionality over
> + the network, and allows concise management of tasks like container
> + migration and container image publishing.
> + </para>
> +
> + <para>
> + LXD uses LXC under the covers for some container management tasks.
> + However, it keeps its own container configuration information and has its
> + own conventions, so that it is best not to use classic LXC commands by hand
> + with LXD containers. This document will focus on how to configure and
> + administer LXD on Ubuntu systems.
> + </para>
> +
> + <sect2 id="lxd-resources"> <title>Online Resources</title>
> +
> + <para>
> + There is excellent documentation for <ulink url="http://github.com/lxc/lxd">getting started with LXD</ulink> in the online LXD README. There is also an online server allowing you to <ulink url="http://linuxcontainers.org/lxd/try-it">try out LXD remotely</ulink>. Stéphane Graber also has an <ulink url="https://www.stgraber.org/2016/03/11/lxd-2-0-blog-post-series-012/">excellent blog series</ulink> on LXD 2.0. Finally, there is great documentation on how to <ulink url="https://jujucharms.com/docs/devel/config-LXD">drive lxd using juju</ulink>.
> + </para>
> +
> + <para>
> + This document will offer an Ubuntu Server-specific view of LXD, focusing
> + on administration.
> + </para>
> + </sect2>
> +
> + <sect2 id="lxd-installation"> <title>Installation</title>
> +
> + <para>
> + LXD is pre-installed on Ubuntu Server cloud images. On other systems, the lxd
> + package can be installed using:
> + </para>
> +
> +<screen>
> +<command>
> +sudo apt install lxd
> +</command>
> +</screen>
> +
> + <para>
> + This will install LXD as well as the recommended dependencies, including the LXC
> + library and lxcfs.
> + </para>
> + </sect2>
> +
> + <sect2 id="lxd-kernel-prep"> <title> Kernel preparation </title>
> +
> + <para>
> + In general, Ubuntu 16.04 should have all the desired features enabled by
> + default. One exception to this is that in order to enable swap
> + accounting the boot argument <command>swapaccount=1</command> must be set. This can be
> + done by appending it to the <command>GRUB_CMDLINE_LINUX_DEFAULT=</command>variable in
> + /etc/default/grub, then running 'update-grub' as root and rebooting.
> + </para>
> +
> + </sect2>
> +
> + <sect2 id="lxd-configuration"> <title> Configuration </title>
> +
> + <para>
> + By default, LXD is installed listening on a local UNIX socket, which
> + members of group LXD can talk to. It has no trust password setup. And
> + it uses the filesystem at <filename>/var/lib/lxd</filename> to store
> + containers. To configure LXD with different settings, use <command>lxd
> + init</command>. This will allow you to choose:
> + </para>
> +
> + <itemizedlist>
> + <listitem>
> + Directory or <ulink url="http://open-zfs.org">ZFS</ulink> container
> + backend. If you choose ZFS, you can choose which block devices to use,
> + or the size of a file to use as backing store.
> + </listitem>
> + <listitem> Availability over the network
> + </listitem>
> + <listitem> A 'trust password' used by remote clients to vouch for their client certificate
> + </listitem>
> + </itemizedlist>
> +
> + <para>
> + You must run 'lxd init' as root. 'lxc' commands can be run as any
> + user who is member of group lxd. If user joe is not a member of group 'lxd',
> + you may run:
> + </para>
> +
> +<screen>
> +<command>
> +adduser joe lxd
> +</command>
> +</screen>
> +
> + <para>
> + as root to change it. The new membership will take effect on the next login, or after
> + running 'newgrp lxd' from an existing login.
> + </para>
> +
> + <para>
> + For more information on server, container, profile, and device configuration,
> + please refer to the definitive configuration provided with the source code,
> + which can be found <ulink url="https://github.com/lxc/lxd/blob/master/doc/configuration.md">online</ulink>
> + </para>
> +
> + </sect2>
> +
> + <sect2 id="lxd-first-container"> <title> Creating your first container </title>
> +
> + <para>
> + This section will describe the simplest container tasks.
> + </para>
> +
> + <sect3> <title> Creating a container </title>
> +
> + <para>
> + Every new container is created based on either an image, an existing container,
> + or a container snapshot. At install time, LXD is configured with the following
> + image servers:
> + </para>
> +
> + <itemizedlist>
> + <listitem>
> + <filename>ubuntu</filename>: this serves official Ubuntu server cloud image releases.
> + </listitem>
> + <listitem>
> + <filename>ubuntu-daily</filename>: this serves official Ubuntu server cloud images of the daily
> + development releases.
> + </listitem>
> + <listitem>
> + <filename>images</filename>: this is a default-installed alias for images.linuxcontainers.org.
> + This is serves classical lxc images built using the same images which the
> + LXC 'download' template uses. This includes various distributions and
> + minimal custom-made Ubuntu images. This is not the recommended
> + server for Ubuntu images.
> + </listitem>
> + </itemizedlist>
> +
> + <para>
> + The command to create and start a container is
> + </para>
> +
> +<screen>
> +<command>
> +lxc launch remote:image containername
> +</command>
> +</screen>
> +
> + <para>
> + Images are identified by their hash, but are also aliased. The 'ubuntu'
> + server knows many aliases such as '16.04' and 'xenial'. A list of all
> + images available from the Ubuntu Server can be seen using:
> + </para>
> +
> +<screen>
> +<command>
> +lxc image list ubuntu:
> +</command>
> +</screen>
> +
> + <para>
> + To see more information about a particular image, including all the aliases it
> + is known by, you can use:
> + </para>
> +
> +<screen>
> +<command>
> +lxc image info ubuntu:xenial
> +</command>
> +</screen>
> +
> + <para>
> + You can generally refer to an Ubuntu image using the release name ('xenial') or
> + the release number (16.04). In addition, 'lts' is an alias for the latest
> + supported LTS release. To choose a different architecture, you can specify the
> + desired architecture:
> + </para>
> +
> +<screen>
> +<command>
> +lxc image info ubuntu:lts/arm64
> +</command>
> +</screen>
> +
> + <para>
> + Now, let's start our first container:
> + </para>
> +
> +<screen>
> +<command>
> +lxc launch ubuntu:xenial x1
> +</command>
> +</screen>
> +
> + <para>
> + This will download the official current Xenial cloud image for your current
> + architecture, then create a container using that image, and finally start it.
> + Once the command returns, you can see it using:
> + </para>
> +
> +<screen>
> +<command>
> +lxc list
> +lxc info x1
> +</command>
> +</screen>
> +
> + <para>
> + and open a shell in it using:
> + </para>
> +
> +<screen>
> +<command>
> +lxc exec x1 bash
> +</command>
> +</screen>
> +
> + <para>
> + The try-it page gives a full synopsis of the commands you can use to administer
> + containers.
> + </para>
> +
> + <para>
> + Now that the 'xenial' image has been downloaded, it will be kept in sync until
> + no new containers have been created based on it for (by default) 10 days. After
> + that, it will be deleted.
> + </para>
> + </sect3>
> + </sect2>
> +
> + <sect2 id="lxd-server-config"> <title> LXD Server Configuration </title>
> +
> + <para>
> + By default, LXD is socket activated and configured to listen only on a
> + local UNIX socket. While LXD may not be running when you first look at the
> + process listing, any LXC command will start it up. For instance:
> + </para>
> +
> +<screen>
> +<command>
> +lxc list
> +</command>
> +</screen>
> +
> + <para>
> + This will create your client certificate and contact the LXD server for a
> + list of containers. To make the server accessible over the network you can
> + set the http port using:
> + </para>
> +
> +<screen>
> +<command>
> +lxc config set core.https_address :8443
> +</command>
> +</screen>
> +
> + <para>
> + This will tell LXD to listen to port 8843 on all addresses.
> + </para>
> +
> + <sect3> <title> Authentication</title>
> +
> + <para>
> + By default, LXD will allow all members of group 'lxd' (which by default includes
> + all members of group admin) to talk to it over the UNIX socket. Communication
> + over the network is authorized using server and client certificates.
> + </para>
> +
> + <para>
> + Before client c1 wishes to use remote r1, r1 must be registered using:
> + </para>
> +
> +<screen>
> +<command>
> +lxc remote add r1 r1.example.com:8443
> +</command>
> +</screen>
> +
> + <para>
> + The fingerprint of r1's certificate will be shown, to allow the user at
> + c1 to reject a false certificate. The server in turn will verify that
> + c1 may be trusted in one of two ways. The first is to register it in advance
> + from any already-registered client, using:
> + </para>
> +
> +<screen>
> +<command>
> +lxc config trust add r1 certfile.crt
> +</command>
> +</screen>
> +
> + <para>
> + Now when the client adds r1 as a known remote, it will not need to provide
> + a password as it is already trusted by the server.
> + </para>
> +
> + <para>
> + The other is to configure a 'trust password' with r1, either at initial
> + configuration using 'lxd init', or after the fact using
> + </para>
> +
> +<screen>
> +<command>
> +lxc config set core.trust_password PASSWORD
> +</command>
> +</screen>
> +
> + <para>
> + The password can then be provided when the client registers
> + r1 as a known remote.
> + </para>
> +
> + </sect3>
> +
> + <sect3> <title> Backing store </title>
> +
> + <para>
> +LXD supports several backing stores. The recommended backing store is ZFS,
> +however this is not available on all platforms. Supported backing stores
> +include:
> + </para>
> +
> + <itemizedlist>
> + <listitem>
> + <para>
> + ext4: this is the default, and easiest to use. With an ext4 backing store,
> + containers and images are simply stored as directories on the host filesystem.
> + Launching new containers requires copying a whole filesystem, and 10 containers
> + will take up 10 times as much space as one container.
> + </para>
> + </listitem>
> +
> + <listitem>
> + <para>
> + ZFS: if ZFS is supported on your architecture (amd64, arm64, or ppc64le), you
> + can set LXD up to use it using 'lxd init'. If you already have a ZFS pool
> + configured, you can tell LXD to use it by setting the zfs_pool_name configuration
> + key:
> + </para>
> +
> +<screen>
> +<command>
> +lxc config set storage.zfs_pool_name lxd
> +</command>
> +</screen>
> +
> + <para>
> + With ZFS, launching a new container
> + is fast because the filesystem starts as a copy on write clone of the images'
> + filesystem. Note that unless the container is privileged (see below) LXD will
> + need to change ownership of all files before the container can start, however
> + this is fast and change very little of the actual filesystem data.
> + </para>
> + </listitem>
> +
> + <listitem>
> + <para>
> + Btrfs: btrfs can be used with many of the same advantages as
> + ZFS. To use BTRFS as a LXD backing store, simply mount a Btrfs
> + filesystem under <filename>/var/lib/lxd</filename>. LXD will detect
> + this and exploit the Btrfs subvolume feature whenever launching a new
> + container or snapshotting a container.
> + </para>
> + </listitem>
> +
> + <listitem>
> + <para>
> + LVM: To use a LVM volume group called 'lxd', you may tell LXD to use that
> + for containers and images using the command
> + </para>
> +
> +<screen>
> +<command>
> + lxc config set storage.lvm_vg_name lxd
> +</command>
> +</screen>
> +
> + <para>
> + When launching a new container, its rootfs will start as a lv clone. It is
> + immediately mounted so that the file uids can be shifted, then unmounted.
> + Container snapshots also are created as lv snapshots.
> + </para>
> + </listitem>
> + </itemizedlist>
> + </sect3>
> + </sect2>
> +
> + <sect2 id="lxd-container-config"> <title> Container configuration </title>
> +
> + <para>
> + Containers are configured according to a set of profiles, described in the
> + next section, and a set of container-specific configuration. Profiles are
> + applied first, so that container specific configuration can override profile
> + configuration.
> + </para>
> +
> + <para>
> + Container configuration includes properties like the architecture, limits
> + on resources such as CPU and RAM, security details including apparmor
> + restriction overrides, and devices to apply to the container.
> + </para>
> +
> + <para>
> + Devices can be of several types, including UNIX character, UNIX block,
> + network interface, or 'disk'. In order to insert a host mount into a
> + container, a 'disk' device type would be used. For instance, to mount
> + /opt in container c1 at /opt, you could use:
> + </para>
> +
> +<screen>
> +<command>
> +lxc config device add c1 opt disk source=/opt path=opt
> +</command>
> +</screen>
> +
> + <para>
> + See:
> + </para>
> +
> +<screen>
> +<command>
> +lxc help config
> +</command>
> +</screen>
> +
> + <para>
> + for more information about editing container configurations. You may
> + also use:
> + </para>
> +
> +<screen>
> +<command>
> +lxc config edit c1
> +</command>
> +</screen>
> +
> + <para>
> + to edit the whole of c1's configuration in your specified $EDITOR.
> + Comments at the top of the configuration will show examples of
> + correct syntax to help administrators hit the ground running. If
> + the edited configuration is not valid when the $EDITOR is exited,
> + then $EDITOR will be restarted.
> + </para>
> +
> + </sect2>
> +
> + <sect2 id="lxd-profiles"> <title> Profiles </title>
> +
> + <para>
> + Profiles are named collections of configurations which may be applied
> + to more than one container. For instance, all containers created with
> + 'lxc launch', by default, include the 'default' profile, which provides a
> + network interface 'eth0'.
> + </para>
> +
> + <para>
> + To mask a device which would be inherited from a profile but which should
> + not be in the final container, define a device by the same name but of
> + type 'none':
> + </para>
> +
> +<screen>
> +<command>
> +lxc config device add c1 eth1 none
> +</command>
> +</screen>
> +
> + </sect2>
> + <sect2 id="lxd-nesting"> <title> Nesting </title>
> +
> + <para>
> + Containers all share the same host kernel. This means that there is always
> + an inherent trade-off between features exposed to the container and host
> + security from malicious containers. Containers by default are therefore
> + restricted from features needed to nest child containers. In order to
> + run lxc or lxd containers under a lxd container, the
> + 'security.nesting' feature must be set to true:
> + </para>
> +
> +<screen>
> +<command>
> +lxc config set container1 security.nesting true
> +</command>
> +</screen>
> +
> + <para>
> + Once this is done, container1 will be able to start sub-containers.
> + </para>
> +
> + <para>
> + In order to run unprivileged (the default in LXD) containers nested under an
> + unprivileged container, you will need to ensure a wide enough UID mapping.
> + Please see the 'UID mapping' section below.
> + </para>
> +
> + <sect3> <title> Docker </title>
> +
> + <para>
> + In order to facilitate running docker containers inside a LXD container,
> + a 'docker' profile is provided. To launch a new container with the
> + docker profile, you can run:
> + </para>
> +
> +<screen>
> +<command>
> +lxc launch xenial container1 -p default -p docker
> +</command>
> +</screen>
> +
> + <para>
> + Note that currently the docker package in Ubuntu 16.04 is patched to
> + facilitate running in a container. This support is expected to land
> + upstream soon.
> + </para>
> +
> + <para>
> + Note that 'cgroup namespace' support is also required. This is
> + available in the 16.04 kernel as well as in the 4.6 upstream
> + source.
> + </para>
> +
> + </sect3>
> + </sect2>
> +
> + <sect2 id="lxd-limits"> <title> Limits </title>
> +
> + <para>
> + LXD supports flexible constraints on the resources which containers
> + can consume. The limits come in the following categories:
> + </para>
> +
> + <itemizedlist>
> + <listitem>
> + CPU: limit cpu available to the container in several ways.
> + </listitem>
> + <listitem>
> + Disk: configure the priority of I/O requests under load
> + </listitem>
> + <listitem>
> + RAM: configure memory and swap availability
> + </listitem>
> + <listitem>
> + Network: configure the network priority under load
> + </listitem>
> + <listitem>
> + Processes: limit the number of concurrent processes in the container.
> + </listitem>
> + </itemizedlist>
> +
> + <para>
> + For a full list of limits known to LXD, see
> + <ulink url="https://github.com/lxc/lxd/blob/master/doc/configuration.md">
> + the configuration documentation</ulink>.
> + </para>
> +
> + </sect2>
> +
> + <sect2 id="lxd-uid"> <title> UID mappings and Privileged containers </title>
> +
> + <para>
> + By default, LXD creates unprivileged containers. This means that root
> + in the container is a non-root UID on the host. It is privileged against
> + the resources owned by the container, but unprivileged with respect to
> + the host, making root in a container roughly equivalent to an unprivileged
> + user on the host. (The main exception is the increased attack surface
> + exposed through the system call interface)
> + </para>
> +
> + <para>
> + Briefly, in an unprivileged container, 65536 UIDs are 'shifted' into the
> + container. For instance, UID 0 in the container may be 100000 on the host,
> + UID 1 in the container is 100001, etc, up to 165535. The starting value
> + for UIDs and GIDs, respectively, is determined by the 'root' entry the
> + <filename>/etc/subuid</filename> and <filename>/etc/subgid</filename> files. (See the
> + <ulink url="http://manpages.ubuntu.com/manpages/xenial/en/man5/subuid.5.html">
> + subuid(5) manual page</ulink>.
> + </para>
> +
> + <para>
> + It is possible to request a container to run without a UID mapping by
> + setting the security.privileged flag to true:
> + </para>
> +
> +<screen>
> +<command>
> +lxc config set c1 security.privileged true
> +</command>
> +</screen>
> +
> + <para>
> + Note however that in this case the root user in the container is the
> + root user on the host.
> + </para>
> +
> + </sect2>
> +
> + <sect2 id="lxd-aa"> <title> Apparmor </title>
> +
> + <para>
> + LXD confines containers by default with an apparmor profile which protects
> + containers from each other and the host from containers. For instance
> + this will prevent root in one container from signaling root in another
> + container, even though they have the same uid mapping. It also prevents
> + writing to dangerous, un-namespaced files such as many sysctls and
> + <filename> /proc/sysrq-trigger</filename>.
> + </para>
> +
> + <para>
> + If the apparmor policy for a container needs to be modified for a container
> + c1, specific apparmor policy lines can be added in the 'raw.apparmor'
> + configuration key.
> + </para>
> +
> + </sect2>
> +
> + <sect2 id="lxd-seccomp"> <title> Seccomp </title>
> +
> + <para>
> + All containers are confined by a default seccomp policy. This policy
> + prevents some dangerous actions such as forced umounts, kernel module
> + loading and unloading, kexec, and the open_by_handle_at system call.
> + The seccomp configuration cannot be modified, however a completely
> + different seccomp policy - or none - can be requested using raw.lxc
> + (see below).
> + </para>
> +
> + </sect2>
> + <sect2> <title> Raw LXC configuration </title>
> +
> + <para>
> + LXD configures containers for the best balance of host safety and
> + container usability. Whenever possible it is highly recommended to
> + use the defaults, and use the LXD configuration keys to request LXD
> + to modify as needed. Sometimes, however, it may be necessary to talk
> + to the underlying lxc driver itself. This can be done by specifying
> + LXC configuration items in the 'raw.lxc' LXD configuration key. These
> + must be valid items as documented in
> + <ulink url="http://manpages.ubuntu.com/manpages/xenial/en/man5/lxc.container.conf.5.html">
> + the lxc.container.conf(5) manual page</ulink>.
> + </para>
> +
> + </sect2>
> +<!-- TODO
> +[//]: # (## Networking)
> +
> +[//]: # (Todo Once the ipv6 changes are implemented.)
> +-->
> +
> + <sect2> <title> Images and containers </title>
> +
> + <para>
> +LXD is image based. When you create your first container, you will
> +generally do so using an existing image. LXD comes pre-configured
> +with three default image remotes:
> + </para>
> +
> + <itemizedlist>
> + <listitem>
> + ubuntu: This is a <ulink url="https://launchpad.net/simplestreams">simplestreams-based</ulink>
> + remote serving released ubuntu cloud images.
> + </listitem>
> +
> + <listitem>
> + ubuntu-daily: This is another simplestreams based remote which serves
> + 'daily' ubuntu cloud images. These provide quicker but potentially less
> + stable images.
> + </listitem>
> +
> + <listitem>
> + images: This is a remote publishing best-effort container images for
> + many distributions, created using community-provided build scripts.
> + </listitem>
> + </itemizedlist>
> +
> + <para>
> + To view the images available on one of these servers, you can use:
> + </para>
> +
> +<screen>
> +<command>
> +lxc image list ubuntu:
> +</command>
> +</screen>
> +
> + <para>
> + Most of the images are known by several aliases for easier reference. To
> + see the full list of aliases, you can use
> + </para>
> +
> +<screen>
> +<command>
> +lxc image alias list images:
> +</command>
> +</screen>
> +
> + <para>
> + Any alias or image fingerprint can be used to specify how to create the new
> + container. For instance, to create an amd64 Ubuntu 14.04 container, some
> + options are:
> + </para>
> +
> +<screen>
> +<command>
> +lxc launch ubuntu:14.04 trusty1
> +lxc launch ubuntu:trusty trusty1
> +lxc launch ubuntu:trusty/amd64 trusty1
> +lxc launch ubuntu:lts trusty1
> +</command>
> +</screen>
> +
> + <para>
> + The 'lts' alias always refers to the latest released LTS image.
> + </para>
> +
> + <sect3> <title> Snapshots </title>
> +
> + <para>
> + Containers can be renamed and live-migrated using the 'lxc move' command:
> + </para>
> +
> +<screen>
> +<command>
> +lxc move c1 final-beta
> +</command>
> +</screen>
> +
> + <para>
> + They can also be snapshotted:
> + </para>
> +
> +<screen>
> +<command>
> +lxc snapshot c1 YYYY-MM-DD
> +</command>
> +</screen>
> +
> + <para>
> + Later changes to c1 can then be reverted by restoring the snapshot:
> + </para>
> +
> +<screen>
> +<command>
> +lxc restore u1 YYYY-MM-DD
> +</command>
> +</screen>
> +
> + <para>
> + New containers can also be created by copying a container or snapshot:
> + </para>
> +
> +<screen>
> +<command>
> +lxc copy u1/YYYY-MM-DD testcontainer
> +</command>
> +</screen>
> +
> + </sect3>
> +
> + <sect3> <title> Publishing images </title>
> +
> + <para>
> + When a container or container snapshot is ready for consumption by others,
> + it can be published as a new image using;
> + </para>
> +
> +<screen>
> +<command>
> +lxc publish u1/YYYY-MM-DD --alias foo-2.0
> +</command>
> +</screen>
> +
> + <para>
> + The published image will be private by default, meaning that LXD will not
> + allow clients without a trusted certificate to see them. If the image
> + is safe for public viewing (i.e. contains no private information), then
> + the 'public' flag can be set, either at publish time using
> + </para>
> +
> +<screen>
> +<command>
> +lxc publish u1/YYYY-MM-DD --alias foo-2.0 public=true
> +</command>
> +</screen>
> +
> + <para>
> + or after the fact using
> + </para>
> +
> +<screen>
> +<command>
> +lxc image edit foo-2.0
> +</command>
> +</screen>
> +
> + <para>
> + and changing the value of the public field.
> + </para>
> +
> + </sect3>
> +
> + <sect3> <title> Image export and import </title>
> +
> + <para>
> + Image can be exported as, and imported from, tarballs:
> + </para>
> +
> +<screen>
> +<command>
> +lxc image export foo-2.0 foo-2.0.tar.gz
> +lxc image import foo-2.0.tar.gz --alias foo-2.0 --public
> +</command>
> +</screen>
> +
> + </sect3>
> + </sect2>
> +
> + <sect2 id="lxd-troubleshooting"> <title> Troubleshooting </title>
> +
> + <para>
> + To view debug information about LXD itself, on a systemd based host use
> + </para>
> +
> +<screen>
> +<command>
> +journalctl -u LXD
> +</command>
> +</screen>
> +
> + <para>
> + On an Upstart-based system, you can find the log in
> + <filename>/var/log/upstart/lxd.log</filename>. To make LXD provide
> + much more information about requests it is serving, add '--debug' to
> + LXD's arguments. In systemd, append '--debug' to the 'ExecStart=' line
> + in <filename>/lib/systemd/system/lxd.service</filename>. In Upstart,
> + append it to the <command>exec /usr/bin/lxd</command> line in
> + <filename>/etc/init/lxd.conf</filename>.
> + </para>
> +
> + <para>
> + Container logfiles for container c1 may be seen using:
> + </para>
> +
> +<screen>
> +<command>
> +lxc info c1 --show-log
> +</command>
> +</screen>
> +
> + <para>
> + The configuration file which was used may be found under <filename> /var/log/lxd/c1/lxc.conf</filename>
> + while apparmor profiles can be found in <filename> /var/lib/lxd/security/apparmor/profiles/c1</filename>
> + and seccomp profiles in <filename> /var/lib/lxd/security/seccomp/c1</filename>.
> + </para>
> + </sect2>
> +
> + </sect1>
> +
> <sect1 id="lxc" status="review">
> <title>LXC</title>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x99412C79.asc
Type: application/pgp-keys
Size: 3108 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-server/attachments/20160330/02258ce1/attachment.key>
More information about the ubuntu-server
mailing list