VMs and containers

The kernel boundary changes the exercise

A conventional VM boots its own guest kernel. A Linux container isolates processes using facilities such as namespaces and resource controls while sharing its host Linux kernel. An image can contain a distribution's userspace without containing a separately booted kernel.

These are practical defaults, not claims that every VM or container is configured identically.

Open diagram at full size.

Read downward from each application to the kernel handling its system calls. In the VM example those paths reach separate guest kernels. In the container example they converge on one Linux kernel. The Mac example adds a Linux VM because macOS itself does not supply Linux system calls.

An image is packaged filesystem content and metadata used to create an environment. A container is a running or stopped instance created from an image. Linux namespaces give processes different views of resources such as process IDs and networking. Resource controls, commonly cgroups, account for and limit their use. Those controls do not mean each container has a separately booted kernel.

For example, a container can report Ubuntu in /etc/os-release while uname -r reports its host's Linux kernel. The files describing userspace and the running kernel answer different questions. A writable container layer is also not automatically a durable backup; persistent data needs a deliberately retained volume, mount, or external store.

Linux containers on a Mac

macOS does not provide a Linux kernel directly to Linux containers. OrbStack supplies a Linux VM and Docker integration. Its lightweight Linux machines also share that Linux kernel. They are useful for many distribution and service exercises, but they are not independent full VMs with separate boot chains.

Keep that distinction in your notes when comparing uname -r with /etc/os-release: the first describes the running kernel, the second describes the installed userspace distribution. Different distributions can report the same shared kernel.

Match the lab to the boundary

Use OrbStack for file permissions, processes, systemd services on Ubuntu, package management, and Ansible practice. Use a full VM with its own bootable guest kernel for bootloader repair, independent kernel replacement, or a realistic disk-layout/LVM experiment. A Docker application container is useful for packaging and runtime lifecycle work later in DevOps foundations.

Try three placement decisions

For each task, pick an environment and explain the kernel/lifecycle reason:

1. Change a configuration file and inspect a systemd service: the Ubuntu OrbStack machine is suitable because it supplies the distribution userspace and service manager needed here.
2. Repair a guest bootloader after a failed kernel boot: use a full independently bootable VM with console recovery; neither an ordinary application container nor an OrbStack shared-kernel machine demonstrates this.
3. Package one web process reproducibly: an application container is a useful later DevOps exercise, with persistence and networking made explicit.

The answers depend on what must be observed, not on the presence of a shell prompt. Do not launch three environments to complete the exercise; draw them and justify the choice. Next, create only the single Linux learning machine.

Check and revise

Does installing a kernel package in an ordinary application container replace its running kernel? No. Does having a shell inside a container make it equivalent to a VM? No: inspect isolation and lifecycle boundaries.

Revision: choose by the behavior under test, not by whichever environment starts fastest. This comparison creates no resources and makes no claim that the later kubeadm topology has already been validated on OrbStack.

Sources

Primary references: Container fundamentals↗; OrbStack architecture↗.