- What is LXC?
- For what it is useful?
- What are the differences between LXC and common virtualization?
closed as off topic by Chris S Jun 1 '13 at 16:32
Questions on Server Fault are expected to relate to server, networking, or related infrastructure administration within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here. If this question can be reworded to fit the rules in the help center, please edit the question.
If by "Plain English" you mean untechnical people, the difference can't be explained easily. That hair is too fine to split without very careful consideration.
If by "Plain English" you mean managerial types who talk to technical people, and thus have at least a passing understanding of technical topics, I submit the following verbage:
It is a different form of virtualization.
If you look at VMWare ESXi, that's a full hypervisor running what is called full virtualization. There is a very small layer between the virtualized systems running on top of the hardware. There is full hardware virtualization, where the OS running in the virtual machine is fully independent from the hypervisor itself and is presented with all the hardware it is expecting.
Take another step up, and look at something like VMWare Player, Workstation, ESX (not ESXi), or VMWare Server, and you have a full operating system providing the hypervisor role. However, virtual machines are still presented with a full array of virtual hardware.
Another approach is para-virtualization, which Xen followed for quite some time. In this form of virtualization, the guest operating system is aware that it is virtualized and has been modified to work in that environment. Sometimes all this needs is special para-virtualization drivers. Other times, outright kernel changes are needed.
LXC, or Linux Containers, is yet another step up. In this case it is running multiple instances of the exact same operating system. The kernel may be the same, but multiple userspaces are running for each OS container. Each container may or may not have a different file-system.
Containers offer a way to provide strong security separation between processes in a way that isn't available in systems that have the same userspace. Unix-like operating systems have had the 'chroot jail' for quite some time, but it doesn't provide process separation or an ability to limit the resources consumed by processes in the jail. By containerizing such processes, resource usage can be limited, discrete IP addresses can be assigned to them, and security vulnerabilities exploiting userspace are contained from the rest of the system.
Where would you use LXC versus some other type of virtualization? It depends, but LXC should provide less virtualization-penalty than any other vitualization method as it is the same kernel mediating all userspace calls rather than a hypervisor pretending to be hardware to a bunch of OS images expecting to talk to physical hardware. So if you have a bunch of processing that needs the same OS version, and can be rebooted at the same time for updates, LXC could provide a low-cost way to run all of that securely and with resource management.
LXC is a means by which to isolate systems/processes at the kernel. The system is locked in a "container" so that it cannot interact with anything outside of that container. Thus the name Linux Containers.
It could be useful for many things, one of which would be to isolate services running on a machine. If one of these services is compromised, the host system itself (along with the other services running in their own LXCs) would be unaffected. It could even be used as a dumb means to give each user root access to their own system, with no worries of them interacting with each other.
Most other "common" virtualizations impose a large overhead of resource usage because of the need to emulate hardware devices. LXC does not require any sort of emulation for hardware devices, as each LXC is given limited/no direct access to the hardware. Each system is "running" on the host, but cannot affect anything outside of its container. This type of virtualization has been called OS-level virtualization (google it). Which essentially means very little/non-existent overhead for running a Linux Container. So you can have hundreds of LXCs on a given machine, but you would run out of resources quite quickly using "common" virtual machine software.
I am actually more familiar with Linux-Vserver but the theory is very much the same.
The simplest way to understand it is to learn what chroot does. chroot lets you "log into" a folder of a unix-like system, as if it was the full system in its own right. In other words:
if you have:
etc., then you can add a some_new_install directory:
and log into /some_new_install. Then /some_new_install/etc is the new /etc, for instance, and the original /etc is hidden, and (mostly) inaccessable. /usr/bin could be different from the original, with different programs. MySQL could be the same program in /usr/bin/mysql, but with different data in /var/lib/mysql.
The filesystem has been virtualised; you've split your original filesystem up, sharing its resources, isolating those resources from other virtualised resources.
This is pretty great. Instead of running a whole new, virtual copy of unix, just to run one extra program, you can jump into a virtual filesystem and run it on the same kernel, same libraries (if you used symlinks), etc. It's MUCH more efficient than something like Xen, or VirtualBox.
The problem is that, if one of those programs, say, MySQL, goes nuts and starts using all your CPU and swapping on disk, then it's still going to affect the rest of the machine, because only the filesystem was virtualised, not the CPU or underlying disk performance. IP addresses and ports aren't virtualised either, so if two programs send information on the network, then they will do so from the same IPs, potentially causing conflicts. Likewise, if two copies of mysql try to listen on a port, the second will fail, because the port is in use.
LXC solves this by virtualising not just the filesystem, but also the network ips/ports/interfaces, the CPU, memory usage, etc.
LXC isn't quite as secure as full virtual machines, but generally, it's the superior solution. After all, operating systems are all about sharing resources securely. Most of the time, it's silly to run multiple OS's to do that -- we just need a better OS with better isolation. That is what LXC and similar tools provide.