Much of the industry seems to agree that containers aren't going to replace virtual machines any time soon. But people are certainly thinking about it.

At OpenStack Silicon Valley (OSSV) this past week, Canonical CEO Mark Shuttleworth showed one example of that thinking: a diagram of a theoretical all-container OpenStack implementation.

Other efforts are looking at streamlining VMs to better suit containers. Citrix, for instance, gave an OSSV talk about its App Adapter, a software work-in-progress that would run containers directly on the hypervisor.

And the discussion will continue as VMworld unfolds this week. It was at VMworld a year ago that VMware, the don of virtual machines, declared that containers aren't the enemy. Rather, VMware says customers are deploying containers inside virtual machines, and that's been the usage pattern that the company has championed.

A Linux container is a single package for an application and its dependencies, such as libraries. Containers are an old idea, but Docker made them easy to implement and turned them into a hot property. The draw is application portability: A container makes it easy to move an application, intact, to different environments — say, from a test network into a production one.

But in production environments, some organizations prefer to run containers inside virtual machines. A big reason is security, which came up during one of the OSSV panels.

Multiple containers can ride on one host, meaning they're sharing one Linux kernel. That creates a tempting attack surface, considering how often applications send calls to the kernel.

VMs, separated by hardware, present a "tiny attack surface" that's more realistic to secure, said Adrian Otto, the Rackspace distinguished architect who heads Magnum, the OpenStack project focusing on container orchestration.

"Magnum's answer is: Embrace that this is a weak security barrier and don't use it as a security barrier," he said during the OSSV panel.

The problem is that VMs aren't as small or efficient as containers. Groups of containers can squeeze onto one host, which yields better resource utilization than VMs get. That goes not just for CPU cycles but for memory, which is often the largest IT expense aside from people, said Derek Collison, CEO of Apcera (now majority-owned by Ericsson).

That efficiency gap leads some to believe the VM-container equation can be improved.

Canonical, for one, sees a path toward eliminating VMs. CEO Shuttleworth's OSSV talk was about Canonical's OpenStack work in general and included some live demos of cloud tools such as Landscape (management) and MAAS (bare-metal provisioning), but he concluded it with a diagram of a possible all-container OpenStack.

That setup would be based on a recent Canonical invention called LXD, pronounced "lexdee." It's described as a hypervisor for containers. Normally, applications inside containers will send calls to the kernel. LXD replaces that function, so that applications talk to it, not directly to the host OS.

This creates more separation between containers. The containers aren't all talking to the kernel, so the wide attack surface — where a security breach on any container leads to kernel access — goes away.

Citrix presented an idea along the same lines: App Adapter, software to run containers directly on the hypervisor.

The idea is to shrink the needs of containers. Each container runs with an operating system, and that operating system often includes some elements meant to talk to the hardware.

[caption id="attachment_33907" align="aligncenter" width="800"] Citrix's App Adapter runs containers directly on the hypervisor. Source: Citrix, via Slideshare.[/caption]

"This is where a lot of the operating system overhead comes from," said Steve Wilson, vice president of Citrix's converged infrastructure group. (I missed his talk but got a summary from him the next day.) "If you're not ever going to have physical hardware underneath, or even simulated physical hardware, you're not going to need any of that."

App Adapter pushes those pieces of the OS into the hypervisor, to be shared among containers. What's left on the container is an OS reduced to "basic life support."

Among the advantages would be speed, because containers wouldn't have to boot up. The boot sequence, in which an OS does things like scout around for available memory, would be inherited from the hypervisor.

App Adapter seems like it could be another way to remove the VM from the container equation. But it's worth noting that Wilson's talk was titled, "It Isn't Containers vs. VMs. It Is About Applications."

And his talk mentioned a couple of other efforts that are built around keeping VMs but streamlining them. That's the purpose behind Clear Containers, which were first designed for the CoreOS container system known as rkt. Among Intel’s goals in starting the project was to optimize the use of memory.

Another project called Hyper_ (the underscore is part of the name) aims to create a hypervisor-agnostic engine for Docker containers. Again, the idea is to improve performance, reduce overhead, and avoid the shared-kernel security issue.

Here's the key to all these efforts, something Wilson and Rackspace's Otto both mentioned: Containers weren't created to be infrastructure the way that VMs were. It's more accurate to think about containers as a way to package and move an application, Wilson told me. VMs can provide the missing infrastructure piece.

"This is really going to accelerate the container value proposition around app packaging," Wilson said, referring to all the projects mentioned in his talk. "You get the benefit of a decade's worth of work that's gone into these hypervisors."

Does that mean containers eventually win at the expense of VMs? Maybe it doesn't matter, as Apcera's Collison pointed out during the OSSV panel: "I promise you, in five years we won't be talking about containers. We'll be talking about the next thing, even more lightweight and with even better security."