English
Menu

Virtual Machine vs Container: Kernel, Isolation and Startup Time

Both let one computer run several applications isolated from each other, but they virtualize different layers. A virtual machine relies on a hypervisor that creates virtual hardware, such as CPUs, memory, disks and network devices, and each virtual machine runs a complete operating system, kernel included, on top of it. A container shares the host operating system's kernel and uses kernel features such as namespaces and cgroups to separate what processes can see and which resources they can use. Containers do not boot an operating system, so they are lighter and start faster, while virtual machines win on strength of isolation and the range of operating systems they can run. In the cloud the two are usually combined, with containers running inside virtual machines.

AspectVirtual machineContainer
Virtualization layerHardware: the hypervisor creates virtual CPUs, memory, disks and network devices and hands them outOperating system: on the host kernel, what processes can see (process IDs, network, file system and so on) and the resources they can use are separated
OS kernelEach virtual machine runs its own operating system (guest OS), including its own kernelAll containers share the host kernel; container images do not include a kernel
Operating systems that can runAlso a different kind of OS from the host (for example, Windows on a Linux host)Only what runs on the host kernel; Linux containers need a Linux kernel
Image sizeIncludes a whole OS, so typically measured in gigabytesOnly the application and the libraries it needs, so typically much smaller than a virtual machine
Startup timeStarts by booting an OS, so it often takes tens of seconds to a few minutesOnly starts processes, so it is fast, typically running within a few seconds
Strength of isolationStrong: separation at the hardware level, so problems in one guest kernel rarely reach other virtual machinesWeaker than a virtual machine: the kernel is shared, so an exploited kernel vulnerability can affect the host and other containers
Resource efficiencyEach guest OS uses its own memory and CPU, so fewer fit on one machineNo duplicated operating systems, so more fit in the same resources
Typical usesRunning different kinds of OS side by side, server consolidation, IaaS virtual machines, environments that need strong isolationMicroservices, testing and delivery in CI/CD, large-scale operation with Kubernetes, keeping development and production environments the same

Figures are typical orders of magnitude and vary by process generation and product.

When to use which

Virtual machine
When you need to run a different kind of OS from the host, want free choice of kernel version and settings, or need strong isolation, for example when sharing a physical server with other users.
Container
When you want to start and stop many copies of the same application quickly, run the same image from development to production, or pack many small services onto one machine.

FAQ

If I have containers, do I still need virtual machines?

It depends on the use. To run Linux applications, containers are often enough. To run a different kind of OS, change the kernel or get strong isolation, you need virtual machines. In the cloud, containers usually run on virtual machines provided by the cloud provider, so the two are combined rather than one replacing the other.

Why do Linux containers run on a Windows or macOS PC?

Linux containers need a Linux kernel. Tools that run Linux containers on Windows or macOS therefore start a lightweight Linux virtual machine behind the scenes and run the containers inside it. Containers still share the host kernel; in this case the host is the Linux system inside the virtual machine.

How can container isolation be strengthened?

Running the processes inside a container as a non-root user, dropping unneeded privileges and restricting the system calls they can make all reduce the impact of an attack. When even stronger isolation is needed, some approaches give each container its own lightweight virtual machine and run the container inside it.

What is the difference between type 1 and type 2 hypervisors?

A type 1 (bare-metal) hypervisor runs directly on the hardware and runs virtual machines on top of it. With no extra layer, it offers better performance and isolation and is used in servers and the cloud. A type 2 (hosted) hypervisor runs as an application on an ordinary operating system; it is easy to use and common for development and testing on PCs.

Check your understanding

Which correctly describes the types of hypervisors?

  1. ASome run directly on the hardware, and others run as applications on an ordinary OS
  2. BThey always run as applications on an ordinary OS and never directly on hardware
  3. CThere are no types; all run purely in software without using hardware features
Show answer and explanation

Answer: A. Some run directly on the hardware, and others run as applications on an ordinary OS

Hypervisors come in two types: Type 1 (bare-metal), which runs directly on the hardware and manages guest OSes, and Type 2 (hosted), which runs as an application on an ordinary OS such as Windows or Linux. Type 1 has no extra layer and offers better performance and isolation, so it is used in servers and clouds; Type 2 is convenient for development and testing on PCs. Both use hardware features such as CPU virtualization support.

Which correctly distinguishes containers from virtual machines?

  1. AEach container has its own OS kernel, while virtual machines share a kernel
  2. BContainers run on a hypervisor, while virtual machines run using only OS features
  3. CContainers share the kernel; each VM runs its own OS
Show answer and explanation

Answer: C. Containers share the kernel; each VM runs its own OS

Containers share a single OS kernel while partitioning file-system views, processes, networking and resource limits by group. Since no whole OS is booted, they are lightweight and start quickly. Virtual machines run on a hypervisor, each with its own OS including a kernel, which is heavier but gives stronger isolation and allows different OS types. Kernel sharing belongs to containers; watch for options that reverse the two.

Among the Linux kernel features that make containers possible, which of the following correctly pairs namespaces and cgroups (control groups) with their roles?

  1. ANamespaces: separate what a process can see (process IDs, network, mounts, etc.); cgroups: limit and account for the use of resources such as CPU and memory
  2. BNamespaces: limit and account for the use of resources such as CPU and memory; cgroups: separate what a process can see (process IDs, network, mounts, etc.)
  3. CNamespaces: boot a separate kernel for each container to isolate them; cgroups: create a virtual CPU for each container and emulate the hardware
Show answer and explanation

Answer: A. Namespaces: separate what a process can see (process IDs, network, mounts, etc.); cgroups: limit and account for the use of resources such as CPU and memory

A container is an ordinary process running on the host kernel, isolated by two mechanisms. Namespaces split process IDs, the network, mounts (the view of the file system), the host name and so on into groups, so that the processes in a container see only their own share. Cgroups limit the CPU time and amount of memory a group of processes can use and account for their usage. Both are kernel features, so a container neither boots another kernel nor emulates hardware.

  1. On a Linux host, Docker is used to start a container from an image based on a different distribution from the host, and uname -r (which shows the kernel release) and cat /etc/os-release (which shows information about the distribution) are run inside it. Which of the following correctly describes the results?
  2. Which of the following correctly describes the relationship between a container image and a container?
  3. Which of the following is an appropriate way to update the software on production servers in line with the idea of immutable infrastructure?

Practice Cloud and Container Basics questions

Key terms explained

Container
A unit of execution that bundles an application with the libraries and settings it needs and runs it isolated from other processes while sharing the host OS kernel. On Linux it is built from namespaces, which separate the view of process IDs, the network, mounts and so on, and cgroups, which limit the use of CPU and memory. It is lighter and faster to start than a virtual machine that boots a whole OS, but because it shares the kernel it cannot run a kernel of a different kind of OS from the host. Containers are created from container images and are created and managed with tools such as Docker and Kubernetes.
Container image
A read-only template from which containers are created. It stacks the files of an application, such as executables, libraries and settings, in layers and adds configuration such as the command to start, and it does not contain an OS kernel. Images are built from a Dockerfile or similar and stored and distributed through registries. An image is specified by repository name and tag (for example web:1.4), or uniquely by a digest computed from its contents (sha256:…). Identical layers are shared between images.
Hypervisor
Software that runs multiple virtual machines on one computer, allocating CPU, memory and devices to each guest OS and isolating them from one another. Also called a virtual machine monitor.
Docker
A widely used software suite for building container images, exchanging images with registries, and starting and managing containers. It builds images from the instructions written in a Dockerfile and starts containers with docker run. It can publish ports with -p, keep data in volumes and bind mounts, and configure networking. The image and container formats are standardized as OCI (Open Container Initiative) specifications, so the same images can be used with tools other than Docker.
Kubernetes
An orchestration platform that places containers on a cluster of many machines (nodes), keeps their number, updates them and provides endpoints for them. Users declare a desired state with resources such as Deployments and Services, and controllers observe the actual state and bring it closer to the declaration (reconciliation). The smallest unit is the Pod; lost Pods are recreated automatically, and rolling updates and load-based autoscaling are supported. It is also abbreviated K8s.
Immutable infrastructure
An operational approach in which servers (virtual machines or containers) are never changed once created; when an update is needed, new ones are created from an image containing the change and swapped in, and the old ones are discarded. Because every server is created from the same image, configurations do not drift apart through accumulated manual differences, and going back to the previous image easily restores the old state. Anything to be kept, such as logs and data, is placed in storage or databases outside the servers.

Related comparisons