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. 1)
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:
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:
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 systems6), LXC doesn't waste memory due to VM 7) 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. 8)
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.
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. 9)
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:
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 10) rules hide the LXC virtual network from the outside world.
|Issue||LXC Simple Bridging||LXC NAT Routing||Comment|
|LXC Containers visible from outside||Yes||No (hidden)||1|
|LXC Container IP-address||Outside IP-address||Inside IP-address||2|
|Outside access to LXC services||Direct||Via DNAT rules|
|Services operate on real IP-addresses||Yes||No||3|
|Wireless LAN support||No||yes||4|
|Firewall support (Shorewall)||Complex||Host central||5|
|https://wiki.debian.org/LXC||Debian Wiki: LXC|
|https://www.stgraber.org/2013/12/20/lxc-1-0-blog-post-series/||Stephane Graber's Blog post series LXC 1.0|
|https://wiki.deimos.fr/LXC_:_Install_and_configure_the_Linux_Containers||Deimosfr: LXC: install and configure Containers|
|http://www.vislab.uq.edu.au/howto/lxc/lxcnetwork.html||UQVislab LXC networking|
|https://wiki.archlinux.org/index.php/Linux_Containers#Virtual_Network_Types||Archlinux Wiki: LCX: Virtual Network Types|
Copyright © 2014 Integrated Services; Tux4u.nl
Author: Marjan Waldorp; lxc/lxc-introduction 2014-08-13