The Case for LXD, Canonical’s System Container Framework

Most container conversations today center on Docker. But as Docker has taken enough, Canonical has been quietly working on LXD, a different type of container framework that supports some interesting use cases. Here’s what it is and how it works.

LXD is based on LXC, the Linux container framework that was also the foundation for Docker in Docker’s earlier days. (Docker has since replaced it with libcontainer, its own container framework.)

However, LXD is designed with a different set of use cases in mind. It is primarily intended to host complete operating systems inside containers. That makes it different from Docker, whose primary use case is hosting individual applications.

LXD’s Killer Features

Why host an entire operating system inside a container? Wouldn’t you use a virtual machine to do that instead?

Well, you could use a virtual machine. But the main advantage of LXD is that it doesn’t require you to install a complete guest operating system inside your container. Instead, the container shares resources from the host server’s operating system environment.

Sponsorships Available

Sponsorships Available

Sponsorships Available

Because LXD doesn’t require a complete operating system to be installed inside each guest container, it allows you to run more guest operating systems on a single host server than you could deploy using traditional virtualization. Canonical says it can support about 10 times as many virtual guest environments on a single host as VMware.

It also offers the benefit of fast startup times. It can launch a guest operating system in seconds, rather than minutes.

Last but not least, Canonical says LXD-hosted systems run 25 percent faster than traditional virtual machines.

Limitations and Use Cases

All of the above sets LXD apart from Docker containers, as well as traditional virtual machines.

To date, however, there has been little evidence of large-scale adoption. Chatter about LXD reached its height about a year ago, around the time of its first production release, and it seems to have dropped off since then.

In other words, LXD is currently getting less attention than you might expect for an open-source technology which solves a specific challenge that Docker is not designed to address—and does it in a more efficient way than traditional virtualization.

Why the lack of love? Part of the reason is because it’s closely tied to Ubuntu Linux, Canonical’s open-source operating system. LXD doesn’t work well on Linux distributions other than Ubuntu. It’s possible to install it on other Linux distributions, such as CentOS, but there are some big caveats. And you certainly can’t run LXD on Windows. This limits its availability and constrains its use cases.

Another challenge is that system containers in general don’t offer obvious value in many situations. If you want to host a lot of applications on a single host server without using traditional virtualization, you can do that using Docker application containers.

And if you want the ability to run Linux applications on a Windows server, or vice versa, only traditional virtualization can give you that. The guest containers hosted by LXD have to run the same type of operating system as the host.

What this means is that use cases for LXD are relatively limited. But they exist. If you’re using Ubuntu Linux, it might be preferable to Docker for hosting workloads that benefit from containerizing an entire operating system environment, rather than just an application. For example, it could be handy for creating virtual server environments on an Ubuntu host without having to set up traditional virtual machines.

Conclusion

LXD has received much less attention than Docker, mostly because its use cases are more limited. But for certain situations—and as long as you don’t mind running your servers on Ubuntu—it can help you do things that Docker was not designed to do.