How processes, containers, and virtual machines isolate work

Trace the same file request in three environments, then test which boundary contains a simulated crash.

Trace an uncached file read

Native process

Own address space; the host’s process and filesystem views.

Physical hostApp’s host PID: 2417

Process address spaceMemory isolation

Application processRequests file bytes through a system call.Current event

What the app seesHost view · example

PID	Process
1	host init
635	other service
2417	this app

Files: /notes.txt in the host mount view
Limits: No extra cgroup cap in this example

Other host PIDs are visible here. Seeing a process or path does not grant access to it.

Shared hosting OSSame kernel as containers

Host kernelChecks access and manages the filesystem.Current event
Host driverSubmits the needed device request.Current event

Physical resources

Physical hardwareThe storage device performs the work.Current event

Container

Own address space plus private process and filesystem views. Still the host’s kernel.

Physical hostApp’s host PID: 2417

Container boundaryPrivate OS views

Process address space

Container processStill a process, with namespaces and configured resource controls.Current event

What the app seesPrivate view · example

PID	Process
1	this app

Files: /notes.txt in a container root, plus explicitly mounted paths
Limits: Example cgroup cap: 1 CPU worth · 512 MiB RAM

Namespaces change the view: host PID 2417 appears as PID 1 here. Cgroup caps are optional, not a new kernel.

Shared hosting OSNo guest kernel

Shared hosting kernelSystem calls enter this kernel; there is no guest kernel.Current event
Host driverServices permitted device requests.Current event

Physical resources

Physical hardwareConfigured resource controls can limit use of real resources.Current event

Virtual machine

A guest OS runs its own kernel on virtual hardware managed by a hypervisor.

Physical hostHosted VM example

Virtual machine boundaryOwn guest kernel

Guest applicationMakes a system call to its guest kernel.Current event
Guest kernelChecks access and interprets the guest filesystem.Current event
Virtual deviceA virtual disk request enters virtualization machinery.Current event

What the guest seesGuest OS · example

Guest PID	Process
1	guest init
42	this app

Kernel: Own guest kernel manages these processes
Files: /notes.txt in the guest filesystem on a virtual disk

vCPUs: 2
Assigned RAM: 2 GiB
Virtual disk: 20 GiB

Guest PID 42 belongs to the guest kernel—not a renamed host PID as in a container PID namespace. These example allocations describe virtual hardware, not dedicated physical cores or a separate physical machine.

Hosting infrastructureOutside the guest

Hypervisor / hosting supportVirtualization and device models arrange host-side I/O.Current event
Host driverHandles the physical device request in this example.Current event

Physical resources

Physical hardwareReal CPU time, RAM, and devices support the guest.Current event

Conceptual file request

Follow the request, not every instruction.

These paths show who services a file request. They are not a pipeline through which every application instruction passes.

Native processes and containers deliberately share the same lower layers: the difference is the configured views and controls, not another kernel. The VM trace is one conventional hosted, virtual-device path—not a universal hypervisor topology. Passthrough and other architectures differ. Cache hits can avoid device I/O; return and completion paths are omitted.

Ordinary arithmetic runs as application instructions on the CPU; it needs no system call. Virtual memory is an address-space abstraction, not a virtual machine.

Failure boundaries & model limits

App crash: this process stops. In the container example, the app is PID 1 in a private PID namespace: its exit also terminates any remaining processes in that namespace. The hosting kernel and other isolated workloads can continue, though shared services or application dependencies can still be affected.

Example views, not universal defaults: native/container views illustrate Linux-style PID and mount namespaces; the VM has a separate guest OS process list. PIDs and virtual hardware allocations are example configurations, not measurements or extra read events. A vCPU is scheduled on physical CPUs; virtual disk capacity need not be preallocated on the host. The container has a configured cgroup CPU/memory cap here. Native processes can also use namespaces and cgroups, and containers can be configured to share host namespaces. Visibility does not bypass access checks; resource caps do not appear automatically.

Hosting-kernel crash: native processes and ordinary containers sharing that kernel lose normal operation. Container isolation does not supply a separate kernel.

Guest-kernel crash: this guest and its applications stop. The host and other guests can continue under the intended isolation boundary. This is not a hypervisor crash: failure of the hypervisor or hosting infrastructure can affect multiple guests.

VM-backed container isolation also exists; desktop tools often host Linux containers inside a VM. “Shared hosting kernel” can therefore be a VM’s guest kernel. Isolation is a design boundary, not an absolute security guarantee.

The controls only display a local teaching simulation. No real processes or VMs are launched, no files or devices are changed, and nothing actually crashes. Restart clears the displayed failure and restarts the trace.