VMs and Containers: Rivalry or Convergence?
For years the debate was “will virtual machines be replaced by containers?” Today the answer seems to be a different one, because in the meantime the question itself has changed: does the replacement even make sense, if the two technologies no longer compete, but collaborate?
Over the last decade we have moved from an almost ideological confrontation, where “containers will replace virtual machines” rode the wave of innovation enthusiasm, to a much more pragmatic approach: today Kubernetes instances often run inside virtual environments, and cloud providers build entire platforms by combining multiple technological layers.
At first glance the two technologies may look similar, and may seem to produce the same practical result. A deeper understanding of their differences, however, is what brings out the specific strengths of each.
Two Kinds of Hypervisors
When talking about virtual environments (and not only about virtual machines), a distinction must be made between the types of hypervisor on which VMs are executed.
Type 1 hypervisors run VMs directly on a tool that manages resources on bare metal, allowing virtual instances direct access to memory, processors, and network interfaces. Xen and KVM are two excellent examples of type 1 hypervisors. KVM is also the foundation of Proxmox VE, a virtualization platform suited to complex and structured enterprise contexts. Proxmox VE supports load distribution, cluster management, and high availability.
The other category is the type 2 hypervisor, which works on top of an additional layer, as a program inside an operating system. Distinguished examples here are VirtualBox and Virt-Manager.
Figure 1 compares type 1 and type 2 hypervisors.
In resource usage and ease of resource management, type 1 hypervisors win hands down. They are widespread in professional environments, while their weightier type 2 colleagues are rarely entrusted with complex or demanding workloads.
Containers: Born Light
Containers were born with one characteristic in mind: lightness. Unlike a virtual machine, they do not need to simulate an entire hardware system, nor boot a complete operating system for every single instance. The processes inside a container share the kernel of the host system, while remaining separate from one another.
This separation is made possible by features of the Linux kernel. Namespaces isolate elements such as processes, network, filesystem, and users, so that each container perceives an apparently autonomous environment. Control groups, commonly called cgroups, allow the system to control and limit the use of resources such as memory, CPU, and input/output operations.
The result is an environment far lighter than a traditional virtual machine. A container can start quickly, occupy less space, and require less memory, because it does not need to include a dedicated kernel. This makes it possible to run numerous containers on the same host and to deploy them very rapidly.
It is important, however, not to mistake a container for a small virtual machine. A container is, first of all, a set of isolated processes, accompanied by the libraries and dependencies needed to run an application. Its level of isolation therefore depends on the kernel shared with the host system, while a VM has its own kernel and an independent operating system.
The role of images is also central. A container image contains the application, its dependencies, and the configurations needed to create a reproducible environment. The same image can run in development, during testing, and later in production, reducing the differences between environments. Docker contributed decisively to the spread of this model, but the concept of a container is not limited to a single product. Today the ecosystem includes tools such as Podman, containerd, and CRI-O, along with shared standards promoted by the Open Container Initiative. Kubernetes, finally, does not create containers directly: it coordinates their execution, distribution, and availability across one or more nodes.
The lean structure of containers does not mean they automatically replace virtual machines. The shared kernel reduces resource consumption, but it also implies a different, often insufficient, level of isolation. This is exactly where the supposed rivalry begins to turn into complementarity: VMs can offer a sharper separation of the infrastructure, while containers make application deployment simpler and faster.
Figure 2 summarizes the components of VMS and containers.
Where Convergence Happens
A concrete example of convergence is a virtualization cluster running several Linux virtual machines. Some of them might host the nodes of a Kubernetes cluster, while others might be dedicated to databases, legacy systems, or services requiring stronger isolation. Inside the VMs assigned to Kubernetes, a container runtime executes the application containers, organized in pods and distributed across the nodes. The hypervisor manages the physical resources, the isolation, and the high availability of the virtual machines, while Kubernetes manages the life cycle, distribution, and scalability of the containerized applications.
In this architecture, virtual machines and containers do not compete for the same role: they operate on different levels. VMs define the boundaries of the infrastructure, while containers define the units in which applications are distributed and executed. Figure 3 shows the composite architecture.
This is exactly where the rivalry between virtual machines and containers loses its meaning. In modern infrastructures, containers do not replace VMs: in most cases, they live inside them. Virtual machines provide the isolation of the infrastructure, while containers take care of the distribution and execution of applications. Two different, complementary levels of the same architecture.
To explore these topics in a structured way, the LPIC-3 Virtualization and Containerization certification is a useful path to consolidate knowledge of KVM, Xen, libvirt, Linux containers, Docker, Podman, Kubernetes, and the main technologies for managing and orchestrating virtualized environments.
<< Read the previous article of this series
