LXD, the Hypervisor for LXC Containers, Part One
Canonical is the company behind Ubuntu and is neck-deep in providing Linux Containers, i.e., LXC and its component technologies, now including LXD (the LXC container hypervisor), CGmanager (for cgroups) and LXCFS (a file system). ContainerJournal spoke with Dustin Kirkland, Strategist, Container Offerings, Canonical about LXD.
After 40-Years, THE Hypervisor for LXC
More than 40-years ago, research engineers Gerald J. Popek & Robert P. Goldberg published the “Formal requirements for virtualizable third generation architectures” in the Communications of the ACM (1974). “This article defined the type-1 and type-2 hypervisors as we know them today, with VMware ESX in the type-1 category and Virtual Box and KVM in the type-2 category,” says Kirkland; “with LXD, we have essentially met the hard requirements, as set forth in this paper, for what is a hypervisor. It’s just that we’ve done it with containers,” says Kirkland.
While present in the background and waiting for an event to activate it, the LXD daemon, which is also a child process of the Ubuntu Linux kernel doles out and administers underlying machine resources such as storage, memory, and CPU resources, and networking to the container. “It is that daemon, that hypervisor, that watches all the containers on a given host,” says Kirkland.
Containers must meet a three-pronged definition, says Kirkland, and LXD works with LXC within that definition. In the first prong, cgroups assist with supplying the resource control aspect of the container definition. Second, LXD runs directly on the host CPU. Third, LXD secures guest environments, safe guarding guests, hostile or otherwise, against the host and each other as potential sources of threats or intrusions. “That’s what we do within LXD. We make use of every security measure possible. We use discretionary access controls. The container is owned by a non-root user and is executed by a non-root user,” says Kirkland.
LXD and Security
LXD of course uses Mandatory Access Controls (MAC) such as AppArmor together with MAC rules, all of which isolates access control as a separate process at the process level. Whereas MACs control process-level permissions, Discretionary Access Controls police the user-level permissions. LXD also uses Seccomp to help limit container use to permissible activities using user namespaces. See the Ubuntu Security Features Wiki for more detail.
“This enforces the requirement that the root user inside the container is not the same user zero outside the container. We do that using a method in the upstream links kernel called user namespaces. Essentially, user zero, inside of the container, is mapped to some nobody user outside of the container, usually, I think we started about 10 thousand and one, so it’s sort of a high order, non-root user,” explains Kirkland.
Technical / Business Drivers Behind the Creation of LXD
The Ubuntu Linux operating system is Canonical’s business. Canonical customer demand drove Canonical to create and offer LXD (together with other sub-technologies CGmanager and LXCFS) in support of LXC. This ensures that Canonical customers have access to two types of container solutions.
In the realm of application containers, Canonical customers want Docker or something like it to run a single process inside a container. “We are supporting real customers, in the field, in production, using application containers, typically in a platform-as-a-service type environment, a path type environment,” says Kirkland; “when application containers are a strict requirement, we’re delighted to refer and support Docker.”
Canonical customers also crave OS containers, i.e. machine containers. “They want containers to look, act, feel, and manage like VMs, and that’s distinctly different from a container that’s running one process, and only one process,” says Kirkland. Like VMs, these containers boot up in the same manner as UNIX systems. Today that means using the “systemd” init (initialization) script a multi-process, multi-threaded init script for simultaneous boot of Linux system processes replacing the serial boot approaches of earlier init scripts. These OS containers work with common server tools such as the SSH (Secure Shell) CLI. “When the user Secure Shell’s into that system container, it looks and feels like a VM or a physical machine to them,” says Kirkland.
Canonical customers need that to support workloads that their systems parse at the machine level. “With the physical aspect, the virtual migration and now virtual-to-container migration, having some consistency across the units, being able to treat them like OSs allows them to really reuse many of their processes, which are operating-systems heavy,” says Kirkland.
