Linux containers is a kernel based lightweight virtual system mechanism sometimes described as “chroot on steroids”.
It is part of the mainstream kernel, and is based on kernel cgroups.
root@apollo# lxc-create -t ubuntu -n cn3 -B lvm --vgname vg0 --fstype ext4
No config file specified, using the default config
Logical volume "cn3" created
mke2fs 1.42 (29-Nov-2011)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
65536 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=268435456
8 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376
Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
debootstrap is /usr/sbin/debootstrap
Checking cache download in /var/cache/lxc/precise/rootfs-i386 ...
Copy /var/cache/lxc/precise/rootfs-i386 to /var/lib/lxc/cn3/rootfs ...
Copying rootfs to /var/lib/lxc/cn3/rootfs ...
##
# The default user is 'ubuntu' with password 'ubuntu'!
# Use the 'sudo' command to run tasks as root in the container.
##
'ubuntu' template installed
Unmounting LVM
'cn3' created
The lxc-cgroup allows you to set controls (constraints) on the container.
From the man page:
DESCRIPTION
lxc-cgroup get or set value from the control group associated with the container name.
If no [value] is specified, the value of the subsystem is displayed, otherwise it is set.
The lxc-cgroup does not assume the correctness of the subsystem name, it is up to the user to specify
the right subsystem name.
The funny thing is that you can set these things on the fly. So for example try to do a ls -l / while logged in the container, and the set the blkio.throttle.read_bps_device to something like 1000, you immediately see the thing slowing down dramatically.
You can see the available subsystem in /sys/fs/cgroup filesystem :
We want to be able to have remote backup of the containers.
A very simple straight-forward way is :
on the target host, remove (or rename temporary) /var/lib/lxc/cn1/rootfs
on the source host, issue :
root@apollo:/var/lib/lxc/cn1# tar -c rootfs | ssh 10.0.0.164 tar -x -C /var/lib/lxc/cn1
This will copy the complete root filesystem of container cn1 to the other host at 10.0.0.164.
There is always at least one file to change after this action, and that is the ip address in /etc/network/interfaces
lxc#
Table of Contents
Linux containers is a kernel based lightweight virtual system mechanism sometimes described as “chroot on steroids”.
It is part of the mainstream kernel, and is based on kernel cgroups.
Resources#
Install and setup#
First install the package lxc. This will introduce some new directories and files :
Creating your first container#
Well, this is very simple :
A new directory is created and has contents for a minimal ubuntu system:
Create container on it's own lv.#
Operating the container#
Show what is running#
And (after starting a conainer) :
Check config for a container#
Starting the container#
The -d option is for daemonize. If you omit this option you get a console
You can also grab a console afterwards
(press <Ctrl-a q> to quit the console).Stopping the container#
You can, of course, shutdown the container itself when you are logged by issuing the shutdown command.
From the host you can issue:
Cloning the container #
Cloning container ubuntu1 to ubuntu2 :
Destroying a container#
control groups#
The lxc-cgroup allows you to set controls (constraints) on the container.
From the man page:
DESCRIPTION lxc-cgroup get or set value from the control group associated with the container name. If no [value] is specified, the value of the subsystem is displayed, otherwise it is set. The lxc-cgroup does not assume the correctness of the subsystem name, it is up to the user to specify the right subsystem name.A few examples :
- show used cpu :
or ? :- limit/show blkio read bytes per second:
The funny thing is that you can set these things on the fly. So for example try to do a ls -l / while logged in the container, and the set the blkio.throttle.read_bps_device to something like 1000, you immediately see the thing slowing down dramatically.You can see the available subsystem in /sys/fs/cgroup filesystem :
Networking#
A virtual bridge is used for networking :
athena ~ # ifconfig eth0 Link encap:Ethernet HWaddr e8:03:9a:e8:75:86 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:41921 errors:0 dropped:0 overruns:0 frame:0 TX packets:41921 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:37262180 (37.2 MB) TX bytes:37262180 (37.2 MB) lxcbr0 Link encap:Ethernet HWaddr fe:e8:17:00:6d:05 inet addr:10.0.3.1 Bcast:10.0.3.255 Mask:255.255.255.0 inet6 addr: fe80::d046:f4ff:feb8:f8c0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1041 errors:0 dropped:0 overruns:0 frame:0 TX packets:1530 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:190653 (190.6 KB) TX bytes:164137 (164.1 KB) vethYMtsPw Link encap:Ethernet HWaddr fe:e8:17:00:6d:05 inet6 addr: fe80::fce8:17ff:fe00:6d05/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6 errors:0 dropped:0 overruns:0 frame:0 TX packets:25 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:468 (468.0 B) TX bytes:5186 (5.1 KB) wlan0 Link encap:Ethernet HWaddr c4:85:08:52:76:78 inet addr:10.0.0.164 Bcast:10.255.255.255 Mask:255.0.0.0 inet6 addr: fe80::c685:8ff:fe52:7678/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:24077 errors:0 dropped:0 overruns:0 frame:0 TX packets:19514 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:18875484 (18.8 MB) TX bytes:5204192 (5.2 MB)Do not specify an lxc.network.ipv4 in /var/lib/lxc/<cn>/config, and specify the following in /etc/network/interfaces:
Now we have another private network for our containers. You can only reach these containers from the host itself.
If you want to reach them from another laptop over wifi, you have two options:
- (better), use the firewall on the container host to forward ports:
This results in the following iptables:root@apollo:/var/lib/lxc/cn1# iptables -vnL -t nat Chain PREROUTING (policy ACCEPT 54 packets, 7138 bytes) pkts bytes target prot opt in out source destination 0 0 DNAT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1180 to:10.0.3.11:80 0 0 DNAT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1280 to:10.0.3.12:80 2 120 DNAT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1122 to:10.0.3.11:22 1 60 DNAT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1222 to:10.0.3.12:22 Chain INPUT (policy ACCEPT 17 packets, 2581 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 3 packets, 180 bytes) pkts bytes target prot opt in out source destination 29 2037 MASQUERADE all -- * * 10.0.3.0/24 !10.0.3.0/24 root@apollo:/var/lib/lxc/cn1#This last NATing can also be used to direct traffic from the wireless modem, for example the 22 and 80 ports :
Remote "copying" containers.#
We want to be able to have remote backup of the containers.
A very simple straight-forward way is :
- on the target host, remove (or rename temporary) /var/lib/lxc/cn1/rootfs
- on the source host, issue :
This will copy the complete root filesystem of container cn1 to the other host at 10.0.0.164. There is always at least one file to change after this action, and that is the ip address in /etc/network/interfaces