LXC containers in practical use on the desktop

Conclusion

The rapid development of Docker in the past 18 months has put LXC containers into the spotlight. Before that, LXC was a little-noticed tool. LXC got a noticeable development push thanks to the fact that Docker became easily available to end users. Users who only occasionally start VirtualBox or KVM to manage a distribution are likely to shy away from using LXC. If you manage several images simultaneously, however, you will notice that LXC handles hardware resources much more economically than a full virtual machine. You can also use LXC as a sandbox for untrusted applications running independently of the host system.

Containers are often deemed insecure, and hypervisors still have an advantage in this respect. Many specialists are currently applying themselves to the task of securing containers. Daniel J. Walsh of Red Hat has discussed this topic in length.

Those working in safety-critical environments can run many LXC containers in a virtual machine, which unfortunately can somewhat increase the network structure's complexity. However, with kernel 3.12 and the use of kernel namespaces, containers with LXC 1.0 can be started under users other than root, thereby preventing changes in the host through the container.

It's difficult to ascertain whether the use of containers will move further into the end user realm. This would require the setup to be made a bit easier. Meanwhile, VirtualBox and KVM have their own setup hurdles. KVM users should have no problem with LXC. Another new player in the field is systemd-nspawn [15], which presumably might remain an enhanced replacement for chroot, but not without more of a manual effort in virtualizing operating systems.