Ubuntu Server Guide Changes, errors and bugs

Container configuration
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.
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.
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:
l x c c o n f i g d e v i c e add c1 opt d i s k s o u r c e=/opt path=opt
See:
l x c h e l p c o n f i g
for more information about editing container configurations. You may also use:
115

---

l x c c o n f i g e d i t c1
to edit the whole of c1’s configuration. 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 the editor will be restarted.
Profiles
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.
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’:
l x c c o n f i g d e v i c e add c1 e t h 1 none
Nesting
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:
l x c c o n f i g s e t c o n t a i n e r 1 s e c u r i t y . n e s t i n g t r u e
Once this is done, container1 will be able to start sub-containers.
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.
Limits
LXD supports flexible constraints on the resources which containers can consume. The limits come in the
following categories:
• CPU: limit cpu available to the container in several ways.
• Disk: configure the priority of I/O requests under load
• RAM: configure memory and swap availability
• Network: configure the network priority under load
• Processes: limit the number of concurrent processes in the container.
For a full list of limits known to LXD, see the configuration documentation.