LXC (LinuX Containers) is an operating system level virtualization method for running multiple isolated Linux systems (containers) on a single control host.

The Linux kernel comprises cgroups for resource isolation (CPU, memory, block I/O, network, etc.) that does not require starting any virtual machines. Cgroups also provides namespace isolation to completely isolate application's view of the operating environment, including process trees, network, user ids and mounted file systems. ¹⁾

To put it into other words: LXC is “chroot” on steroids. A “chroot” jail provides the ablility to run programs in an isolated Root directory environment. Process and network environments are not isolated from the host however. ²⁾

LXC takes the isolation approach a big step further. LXC offers application environments completely isolated from the host and from each other.

The LXC virtualization technique offers a wide spread of applications:

• Consolidation of several Linux machines on a one hardware server.
• running services in an isolated environment: webserver, database server, etc.
• Virtual Private Servers
• application sandboxes
• application appliances (e.g. Docker)³⁾
• developing/testing software in an isolated environment
• running a different release of a Linux distribution
• providing a different Linux distribution on the same host

LXC containers use (by nature) the Linux kernel of the host.
This limits the application environments to those which are compatible with the hosts Linux kernel version:

• The Linux distribution release in the LXC container may differ from the host, but must be able to run under the hosts Linux kernel version.
  E.g. this might be accomplished by installing a recent (backported) kernel on the host.
• You cannot run a non-Linux OS in a LXC container.
  (Use a VMM ⁴⁾ instead: Xen, Virtual Box, KVM, etc.)

Since LXC simply runs processes in another Namespace ⁵⁾ and doesn't rely on a virtual machine, LXC containers run virtually without overhead.
The overall performance of the computer is determined by the total load the running processes impose to the system.
Using “cgroups” (Control Groups) resource limits (RAM, CPU, etc.) can be set on containers.

In contrast to VMM systems⁶⁾, LXC doesn't waste memory due to VM ⁷⁾ memory reservation. The memory footprint of a LXC container is just determined by the total memory footprint of the running processes in the container. So even on hardware with limited amount of RAM multiple LXC containers can be operated simultaneously.

From a security standpoint providing unprivileged (non-Root) user accounts on LXC containers doesn't differ from providing unprivileged accounts on the host system.
Allowing Root access to privileged (running as Root) LXC containers is not safe however. Under certain conditions the host system might be compromised. ⁸⁾

Starting from Linux kernel 3.14 and LXC 1.0.5 it is possible to configure and operate unprivileged LXC containers. This is accomplished by mapping LXC container “UID=0” (Root) to a non-zero (unprivileged) UID on the host.

An important step in implementing LXC is choosing the appropriate network scenario for the application.
This section discusses the most popular networking scenarios.

LXC offers several network types, amongst these a “none” type. When using the “none” network type the LXC container simply shares all the network resources with the host. This network setup type is well suited for simple tests or to run a (graphical) application in a sandbox.

• Note that since UDP/TCP ports are shared with the host the allocation of listening ports in the LXC container may conflict with those allocations in the host and vice versa.

For most applications the “none” network type is inappropriate, since the LXC container has unlimited access to the network resources of the host. There is nothing to stop the container from compromizing the hosts live network configuration. ⁹⁾

• Don't confuse the “none” setup type with “empty”.
  The “empty” setup configures the loopback interface only. The container won't have any network access to/from the outside world.

• More info about LXC network types:
  $ man lxc.container.conf

For most applications the LXC network setup comprises the creation of a virtual Ethernet network centered around a virtual Ethernet bridging device. Each LXC container is linked to this Ethernet bridging device via a virtual Ethernet device pair of which one halve is located inside the container and the other halve outside the container. The outside halve of these virtual Ethernet devices are visible in the hosts network configuration (ifconfig).

There are two ways to connect the LXC virtual network to the outside world:

• Bridging
• (NAT) Routing

In the “Bridging” scenario the Virtual Ethernet Bridge is directly connected to the physical networking interface of the host.
Since the physical networking interface has to pass all Ethernet frames to the according virtual LXC Ethernet interfaces, it has to operate in “promiscuous mode”.
The hosts IP-address is configured on the virtual Ethernet Bridge.

In the “NAT Routing” scenario the Virtual Ethernet Bridge operates its own (private) IP network. All trafic to/from the outside world is routed by the Linux kernel.
Since in most cases we don't want to deal with an extra IP network, Linux “iptables” NAT ¹⁰⁾ rules hide the LXC virtual network from the outside world.

1. Bridging: Containers show up as separate hosts.
2. Bridging: Each Container needs an outside IP-address!
3. NAT Routing: Service processes may need extra configuration to make them aware of the outside world they are serving (e.g. sendmail).
4. Most wireless network interfaces won't operate in promiscuous mode.
5. Bridging: Firewalling is complex. Choose from:
   1. iptables firewalling in each Container and the host
   2. Host MAC layer firewalling

Copyright © 2014 Integrated Services; Tux4u.nl
Author: Marjan Waldorp; lxc/lxc-introduction 2014-08-13