You can simply make a VM image of LXC installed and you have boot2lxc, the vast ecosystem of orchestration technology that works in VMs and systems works in LXC, you don't need specific tools to be designed just for LXC. There is an additional cost in complexity but if that is your use case the trade off may be worth it, but for other use cases the complexity may be overkill. That would be kernel namespaces and cgroups that LXC uses to give end user containers, like Docker uses post 0.9 directly with libcontainer and systemd-nspawn uses for its containers.ĭocker builds on containers to deliver additional functionality. A tad unfair to LXC given Docker was based on it till 0.9 and knew exactly what it was, and is as accurate as referring to docker or nspawn as low level capabilities. This has resulted in a lot of confusion about LXC in the Docker ecosystem with folks thinking its 'difficult to use' or 'just low level stuff'. LXC is not 'low level kernel capabilities' as Docker misleadingly refers to it on it's website. Its a use case built on Linux containers, not containers itself. Docker takes that base container and adds layers of aufs, constrains the container OS template to single app by modifying the container OS's init, gives you the dockerfile and focuses on deploy centric functionality with immutability idempotency etc, and this makes it much more complex to use than LXC. Users can then decide how they want to deploy. LXC virtualizes the OS environment and gives you lightweight containers that you can seamlessly transition your VM workloads to, or use as a lightweight portable alternative to VMs, so its use case is general and not a narrow focus on paas or deployment centric technology.

LXC is generic container technology like KVM OR Xen are generic virtualization technologies.

Knoppix boot only isolation