VirtualizationCanonical's Container-Visor a Sign of Virtualization's Evolution

Canonical’s Container-Visor a Sign of Virtualization’s Evolution

ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.




When Docker exploded onto the scene a few years back, there was no shortage of people saying that containers meant the end for virtual machines and server virtualization technology.

Well, things didn’t quite pan out that way. Both technologies are still alive and well and living side by side, and in fact each is making the other stronger. Virtually Speaking

VMware (and others) have pursued a “better together” strategy that involves running containers in virtual machines for a host of reasons, including providing better isolation for apps in containers and making it easier to manage containers using existing virtual machine orchestration infrastructure.

But while we have talked about putting containers in virtual machines in this column on a number of occasions, what we haven’t really looked at is the reverse: putting virtual machines in containers.

While it might seem like a pretty strange practice, it’s one that’s thriving, and one of the companies at the forefront of this is Canonical with its LXD container hypervisor, or what the company calls a “container-visor“.

A Closer Look at the Container-Visor Vision

Here’s how it works. LXD (which you’ll find in Ubuntu 16.04 LTS or later) creates a multi-host container management daemon that enables containers to exhibit properties more like those of a virtual machine (such as live migration).

But here’s the key thing: unlike a normal hypervisor that runs virtual machines, the LXD container-visor runs “system containers.” These are containers, but containers that don’t just run a single app or process — instead they run a complete Linux installation.

Since containers share the kernel of the host, that means the Linux installation running in a system container has to be compatible with the host’s OS. In practice that means it has to be the same or another version of Ubuntu, or a version of a related Linux distro like Red Hat Enterprise Linux, CentOS or Debian.

Reasons for Running System Containers instead of VMs

There are plenty of benefits of running system containers instead of full-blown VMs. Since system containers share their host’s kernel rather than running their own full operating system they are lightweight, they can be started in an instant and you can run large numbers of them on a single host.

And just like with virtual machines you can log in remotely, manage the guest OS the standard way, install applications, secure them and operate them with the same tools. You can also carry out snapshotting and start and stop containers remotely.

There’s also an impressive amount of control to be had: you can dedicate disk drives and network connections to particular system containers, and limit (or change on the fly) RAM and disk usage. You can even dedicate processor cores to specific containers, and modify that on the fly.

If you want to run Docker for “traditional” single-process or single-application containers you can do so alongside LXD with both instances working together, and if you really want to set your head spinning you can also run Docker inside LXD: Canonical promises zero performance impact doing so.

Of course, it’s not all roses with a container-visor. You obviously can’t run non-Linux system containers (as they can’t share the host’s Linux kernel), and any global restrictions in the Linux kernel such as the number of network connections it supports apply to all of the system containers running on the host, rather than each container being subject to those restrictions independently.

But when you look at LXD’s containers masquerading as virtual machines, and other initiatives such as VMware’s vSphere Integrated Containers, which are containers that are treated and orchestrated like virtual machines by its hypervisor, you can see that the distinction between containers and virtual machines is becoming increasingly blurred.

The future then is likely to be some sort of hybrid container and virtual machine — let’s call them container machines — which offer the best benefits of both.

Paul Rubens is a technology journalist and contributor to ServerWatch, EnterpriseNetworkingPlanet and EnterpriseMobileToday. He has also covered technology for international newspapers and magazines including The Economist and The Financial Times since 1991.

Follow ServerWatch on Twitter and on Facebook

Get the Free Newsletter!

Subscribe to Daily Tech Insider for top news, trends & analysis

Latest Posts

Related Stories