LXC 1.0

Lean and Quick

Limiting Resources

CGroups look after limiting and accounting a container's resources; cgmanager [6] has been used for this since Ubuntu 14.04. Before then, you could access these values via /sys/fs/cgroup/.

The lxc-info command provides a good overview of the current usage (Figure 4). lxc-cgroup requests the CGroup values:

root@ubuntu:~# lxc-cgroup -n debian_test memory.usage_in_bytes 3985408
root@ubuntu:~# lxc-cgroup -n debian_test  memory.failcnt 0

Figure 4: The lxc-info command provides an overview of the resources used by the container.

To enable swap accounting, a boot option has to be passed to the kernel (Listing 3). Memory.failcnt and memory.memsw.failcnt get increased if the container hits the memory limitations. In addition to the RAM, you can also limit the used swap space per container.

Listing 3

Including Swap Space

root@ubuntu:~# cat /etc/default/grub | grep LINUX_DEFAULT
GRUB_CMDLINE_LINUX_DEFAULT=""
root@ubuntu:~# vi /etc/default/grub
root@ubuntu:~# cat /etc/default/grub | grep LINUX_DEFAULT
GRUB_CMDLINE_LINUX_DEFAULT="swapaccount=1"
root@ubuntu:~# update-grub2
[...]
root@ubuntu:~# reboot

The memory.memsw. limit_in_bytes CGroup control file contains the total limit for RAM, including swap. You can set the desired limits in the container configuration. The following example allows 100MB of RAM and 100MB of swap space:

lxc.cgroup.memory.limit_in_bytes = 100M
lxc.cgroup.memory.memsw.limit_in_bytes = 200M

Table 2 [7] provides an overview of the available CGroup subsystems. The online documentation [8] is comprehensive and up to date. In addition to RAM, the parameters in Table 3 also prove to be relevant.

Table 2

CGroup Subsystems

Subsystem	Function
`cpuset`	Limits CPU and memory placement for a group of tasks.
`blkio`	Limits for I/O access to and from block devices.
`cpuacct`	Generates automatic reports on CPU resources used by tasks in a CGroup.
`devices`	Allows or disallows access to devices by tasks in a CGroup.
`freezer`	Suspends or resumes tasks in a CGroup.
`hugetl`	`b`Limits VM page usage per CGroup.
`memory`	Limits memory use by tasks in a CGroup.
`net_cls`	Tags network packets with a class identifier.
`cpu`	Schedules CPU access to cgroups.
`perf_event`	Monitors threads of a task group on a CPU.

Table 3

Relevant CGroup Parameters

Parameter	Function
`cpuset.cpus`	CPU core pinning.
`cpu.shares`	The higher the value, the more CPU time the container receives.
`devices.allow/deny`	Access to the base system's devices.
`blkio.throttle.read_bps_device/write_bps_device`	Limits write and read throughput.
`net_cls`	Controls network throughput using `tc`.

However, the CGroup feature doesn't limit a container's disk space. Either a unique logical volume per container, a separate image file, or an XFS directory tree quota can implement such a limitation. The recommended route is a unique logical volume because the LXC tools already provide good support for the logical volume manager.

Command Bridge

Until now you've probably gotten by with just a few lxc-* commands. For example, you can create containers with lxc-create, start and stop them with lxc-start and lxc-stop, or delete them with lxc-destroy. For all of these commands, you can specify the container name with the -n option. To get a full list of lxc-* commands, enter:

ls /usr/bin/lxc-*.

The commands shown in Table 4 are among the lesser known.

Table 4

LXC Exotics

Command	Function
`lxc-autostart`	Controls containers that are configured for an autostart.
`lxc-checkconfig`	Checks the kernel's requirements.
`lxc-device`	Passes on a device to the container.
`lxc-execute`	Executes an individual command in a container.
`lxc-freeze/lxc-unfreeze`	Freezes the processes in a container and wakes them up again.
`lxc-monitor`	Monitors status changes.
`lxc-start-ephemeral`	Starts a temporary container clone that LXC then automatically destroys when stopping a container.

New with LXC

The first stable version of LXC offers some important new features:

Container nesting
Hooks
Unprivileged containers
Prebuilt containers
Liblxc-API

If you want to use nested containers, first allocate the AppArmor profile lxc-container-default-with-nesting to the parent container. If you share the host system's /var/cache/lxc/ folder with the container, even creating will work quickly. Then, install the LXC package in the container and create the nested container as usual. The base system lists the nested containers (Listing 4).

Listing 4

Container in a Container

root:/# echo "/var/cache/lxc var/cache/lxc none bind,create=dir" >> /var/lib/lxc/ubuntu_test/fstab
root:/# echo "lxc.aa_profile = lxc-container-default-with-nesting" >> /var/lib/lxc/ubuntu_test/config
root:/# echo "lxc.mount.auto = cgroup" >> /var/lib/lxc/ubuntu_test/config
root@ubuntu:/# lxc-ls --fancy --nesting
NAME               STATE    IPV4                  IPV6  AUTOSTART
-----------------------------------------------------------------
debian_test        RUNNING  10.0.3.190            -     NO
debian_test2       STOPPED  -                     -     NO
ubuntu_test        RUNNING  10.0.3.191, 10.0.4.1  -     NO
 \_ ubuntu_nested  RUNNING  10.0.4.197            -     NO

With the use of hooks, you can automate container use. The following hooks, prefixed by lxc.hook, are available: .pre-start, .pre-mount, .mount, .autodev, .start, .post-stop and .clone.

The developers worked on the unprivileged containers for a long time. Since version 1.0, it has been possible to run containers on the base system without root access. The developers implement it via the user namespace and separate UID and GID ranges per container. Prebuilt containers make the installation easier because unprivileged containers do not allow some operations. Matching templates are on a Jenkins server [9], although the technology is still in its infancy. The LXC C API is lxccontainer.h, and the Python bindings are similar [10].

« Previous 1 2 3 4 Next »