remove some squeeze-specific notes for clarity (moved to subpage)
addition of page
|Deletions are marked like this.||Additions are marked like this.|
|Line 133:||Line 133:|
|* Detailed explanation and discussion on Masqueraded Bridge (NAT) /MasqueradedBridge|
Linux Containers (LXC) provide a Free Software virtualization system for computers running GNU/Linux. This is accomplished through kernel level isolation. It allows one to run multiple virtual units simultaneously. Those units, similar to chroots, are sufficiently isolated to guarantee the required security, but utilize available resources efficiently, as they run on the same kernel.
For all related information visit : http://lxc.sourceforge.net/
Full support for LXC (including userspace tools) is available since the Debian 6.0 "Squeeze" release.
You can also read some sub pages :
- Install required packages
aptitude install lxc
- Install optional packages
aptitude install bridge-utils libvirt-bin debootstrap
Prepare the host
On a Debian Jessie host, there is nothing to do.
For older releases:
Add this line to /etc/fstab. This is not necessary if libvirt-bin is installed as init.d/libvirt-bin will mount /sys/fs/cgroup automatically)
cgroup /sys/fs/cgroup cgroup defaults 0 0
Try to mount it (a reboot solves an eventual "resource busy problem" in any case)
Check kernel configuration :
# lxc-checkconfig Kernel config /proc/config.gz not found, looking in other places... Found kernel config file /boot/config-2.6.32-5-amd64 --- Namespaces --- Namespaces: enabled Utsname namespace: enabled Ipc namespace: enabled Pid namespace: enabled User namespace: enabled Network namespace: enabled Multiple /dev/pts instances: enabled --- Control groups --- Cgroup: enabled Cgroup namespace: enabled Cgroup device: enabled Cgroup sched: enabled Cgroup cpu account: enabled Cgroup memory controller: missing Cgroup cpuset: enabled --- Misc --- Veth pair device: enabled Macvlan: enabled Vlan: enabled File capabilities: enabled Note : Before booting a new kernel, you can check its configuration usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig
Above the lxc-checkconfig program is reporting "Cgroup memory controller: missing". If you want memory control via cgroups then you need to recompile the linux kernel (or simply add cgroup_enable=memory to the kernel command line on jessie or later).
Debian 8 "Jessie"
LANG=C SUITE=jessie MIRROR=http://httpredir.debian.org/debian lxc-create -n debian8 -t debian
Alternatively you can use this command line:
lxc-create -n debian8 -t debian -- -r jessie
Debian 7 "Wheezy"
LXC installs correctly on "Wheezy" (including a working Debian template since 7.4).
lxc-create -n myvm -t debian
which will prompt you on what distribution to install.
Then adapt network configuration in /var/lib/lxc/myvm/config, e.g. to plug it on libvirt's bridge:
lxc.utsname = myvm lxc.network.type = veth lxc.network.flags = up lxc.network.link = virbr0 lxc.network.ipv4 = 0.0.0.0/24 lxc.network.hwaddr = 00:1E:62:CH:NG:ME
Other templates can be downloaded, before 7.4 we recommended the one referenced on the LXC container mailing list:
lxc-create -n myvm -t debian-wheezy # or for a 32-bit container: linux32 lxc-create -n myvm -t debian-wheezy
Issues in Debian 7 "Wheezy":
LXC may not provide sufficient isolation at this time, allowing guest systems to compromise the host system under certain conditions
Apparently this is progressing in 3.12/lxc-beta2: https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/
lxc-halt times-out (see Start and stop containers below)
Setup networked containers
Create a bridge on the host (natted/routed), /SimpleBridge
Detailed explanation and discussion on Masqueraded Bridge (NAT) /MasqueradedBridge
VLAN + bridge setup description, see /VlanNetworking
Use libvirt package for easy network setup (/LibVirtDefaultNetwork)
Start and stop containers
Notes/warnings on starting and stopping containers:
When you connect to a container console, lxc will let you know how to quit it. The first time you log in however, getty will clear the screen, so you'll probably miss this bit of information:
Type <Ctrl+a q> to exit the console, <Ctrl+a Ctrl+a> to enter Ctrl+a itself
If you're using screen and also use the Ctrl+a command prefix, type <Ctrl+a a q> to exit the console.
When you start the container in foreground mode (without -d), there's apparently no way to quit the terminal (<Ctrl+a q> doesn't work). Make sure you start the containers in background mode with -d, unless you need to debug why a container didn't start.
To start a container in the background and attached to the console at any time later run (by default, login/password is root/root):
lxc-start -n myvm -d lxc-console -n myvm
To start a container in foregroup mode and stay attached to the console run (see warning above):
lxc-start -n myvm
To stop a container without proper halt inside the container:
lxc-stop -n myvm
For versions newer than in Jessie, you can instead instruct the container's init system to cleanly halt (see timeout note above):
lxc-halt -n myvm
For some versions, the above may yield telinit: timeout opening/writing control channel /run/initctl. Work-around: use lxc.cap.drop = sys_admin in the container config file.
To have containers automatically started on booting the host, edit their config file and add:
lxc.start.auto = 1
If your container is defined in a non-default path (e.g. you used the -P option to lxc-create), you must symlink your container into /var/lib/lxc for this to work.
On hosts running a version of Debian/LXC newer than that in jessie, instead you should link their config file in /etc/lxc/auto/:
ln -s /var/lib/lxc/mycontainer/config /etc/lxc/auto/mycontainer
Bind mounts inside the container
By default only the container's filesystem is mounted inside the container (even if on the host, /var/lib/lxc/mycontainer/rootfs has other mount points).
To mount another filesystem in the container, add to /var/lib/lxc/mycontainer/config:
lxc.mount.entry=/path/in/host/mount_point /var/lib/lxc/mycontainer/rootfs/mount_point none bind 0 0
and restart the container. The mount point will now be visible inside the container as well.
Both paths can be identical if necessary.
As of 2015-September-30 The recent security patches to fix CVE-2015-1335 have broken the use of absolute container mount points as shown above on some Debian derived systems. The use of relative container mount points still work and provide a workaround.
SO: for the near future you can use:
lxc.mount.entry=/path/in/host/mount_point mount_point none bind 0 0
instead of the suggestion above. NOTE that it is critical to have no leading "/" in the container mount point (making it a relative mount point).
Incompatibility with systemd
* The version in Wheezy (0.8.0~rc1-8+deb7u2) is not compatible with running systemd inside the container. See 766216 * The versions in both jessie and stretch support systemd in the container just fine for Debian guests. ** YMMV for other types of guests
Upgrading container from "Wheezy" to "Jessie"
When upgrading an lxc guest running "Wheezy" to "Jessie", the lxc VM will stop working, because at the time of writing (23.11.2014) systems will automatically be migrated to systemd. See 766233. This behaviour is being reviewed in 762194.
Switch back to sysv
If the VM was migrated to systemd automatically via an upgrade then you can switch back to sysvinit:
lxc-stop -n myvm # stop the vm # or, if that doesn't work use lxc-kill # the next step requires the VM to be mounted at /var/lib/lxc/myvm/root chroot /var/lib/lxc/myvm/root # chroot into the vm apt-get install sysvinit-core # reinstall old sysvinit
Alternatively you can try to start the container in the foreground and do the same via the container's console as described in section Debian 8 "Jessie"/testing.
Not letting your system be updated to systemd during the upgrade
Before upgrade, run:
apt-get install sysvinit-core
or run the following command in place of a usual dist-upgrade:
apt-get dist-upgrade sysvinit-core
Reconfiguring updated VMs
Note that the following recipe only works on hosts running jessie. It will not work on hosts still running wheezy.
Add the following to your container config:
lxc.autodev = 1 lxc.kmsg = 0
Do the following in the guest.
cp /lib/systemd/system/getty@.service /etc/systemd/system # Comment out the line ConditionPathExists=/dev/tty0 in the copied getty@.service
The udev service (which is a hard dependency of systemd in Jessie) won't run in a container, however the systemd config will detect that sysfs is mounted read-only and will automatically skip udev startup. Apparently this was not the case with earlier versions of systemd and this page used to advise using systemctl to mask the udev and systemd-udev services - this is no longer necessary and may cause problems later (see 812932).
Creating new "Jessie" VMs
Creating new Jessie containers should work without issue.
See also :
http://blog.rot13.org/2010/03/lxc-watchdog_missing_bits_for_openvz_-_linux_containers_migration.html which describes a tool that allows controlling the guest's startup/shutdown through power signals, and also some more setup for consoles.
Known bugs and "got to know issues"
600466 - "Respawning too fast" messages and can't connect to console due to missing tty(1234) nodes in generated container rootfs. Workaround: remove from container's /etc/inittab or start container in interactive mode and mknod -m 660 dev/tty1 c 5 1 for each required tty.
Some bugs that might apply to non-official containers - read the follow-ups for solutions.
"telinit: /run/initctl: No such file or directory" running lxc-halt?
mknod -m 600 /var/lib/lxc/myvm/rootfs/run/initctl p
and add "sys_admin" to the lxc.cap.drop line in /var/lib/lxc/myvm/config? See http://wiki.deimos.fr/LXC_:_Install_and_configure_the_Linux_Containers#telinit:_.2Frun.2Finitctl:_No_such_file_or_directory
761197 - "systemd-journald eats CPU in lxc jessie container"
As noted in the bug report, setting "lxc.kmsg=0" in "/var/lib/lxc/myvm/root" and removing "/dev/kmsg" inside the container seems to fix the problem.
if you encounter a "Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted", then you might consider this advice. The author of these lines here has not verified the accuracy of the proposed configuration settings - be it with respect to security or to other side effects, so please use your own judgement.