Proxmox VE / Basic: platform and guest foundations / Lesson 2

VM and container isolation models

Choose a virtualization boundary from operating-system, compatibility and trust requirements rather than equating low overhead with universal suitability.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Compare independent guest kernels with shared host-kernel containers.
Explain privileged and unprivileged container identity mapping.
Assess isolation and device requirements explicitly.

Compare kernel boundaries

A QEMU/KVM VM exposes virtual hardware to an operating system with its own kernel. An LXC container runs Linux userspace against the host kernel, using namespaces, resource controls and other isolation mechanisms. This difference determines compatibility: a container cannot simply bring an arbitrary guest kernel because its application prefers one. A VM is often appropriate when a separate kernel, another supported operating system or a stronger workload boundary is needed. Neither model removes the need for patching, access control and application security. Select the boundary from requirements before comparing convenience or density.

Model container identity

An unprivileged container maps guest user IDs into a different host ID range. Container root therefore does not ordinarily equal host root. This is a useful reduction in privilege, not proof that every kernel vulnerability or device exposure is harmless. The first example models one simple offset mapping for teaching. Real mappings can contain multiple ranges and have filesystem ownership implications. Changing privilege mode or ID mappings after data exists can break access. Do not treat a numeric ownership symptom as permission to make the container privileged; identify the intended mapping and data owner first.

python Illustrative user-ID mapping arithmetic

offset = 100000
for guest_uid in (0, 1000):
    print(guest_uid + offset)

Expected output

100000
101000

100000 and 101000 follow this deliberately simple model. It reads no account database and does not configure an actual mapping.

Consider devices and features

Device passthrough, nesting and extra container features can expand the trust boundary. A workload that needs low-level kernel control may fit a VM better than a heavily relaxed container. Likewise, passing a physical device to a VM can limit migration and couple recovery to one host. The second example is a requirements record, not a configuration. It separates an application’s actual need from a preferred implementation. Ask whether a userspace alternative satisfies the requirement before exposing additional host capabilities, and document why the chosen isolation level is acceptable.

text Compare requirements before selecting a guest type

workload A: Linux userspace, no custom kernel, controlled trust
workload B: independent kernel requirement, separate guest lifecycle
review dimensions: kernel compatibility, device access, data ownership, recovery

The record does not declare one type universally secure or prescribe a host change.

Separate filesystem and application state

A container root filesystem, bind mount and externally managed dataset can have different backup and ownership behavior. A VM disk also does not automatically include every external data source used by its application. Inventory where each piece of state lives before comparing backup simplicity. Permissions observed inside a container may reflect mapped IDs rather than the host’s names. Copying a directory into another isolation model without preserving the intended ownership can produce failures that look like missing files. Diagnose path existence, mapping and application identity separately.

Make a defensible selection

A defensible selection record names the supported operating system, kernel needs, trust assumptions, resource demand, device requirements and recovery constraints. It also names what has not been tested. Lower container overhead is useful only if the application fits the shared-kernel contract and operational policy. A VM’s separate kernel adds flexibility but consumes resources and still shares underlying hardware. This course creates neither guest type and performs no isolation test. The safe mapping arithmetic establishes only its stated numeric result; actual security and compatibility need release-specific review and authorized evidence.

Common errors and fixes

A container is expected to boot its own custom kernel

Why it happens: Shared-kernel isolation was confused with a VM.
How to fix it: Select a compatible VM boundary or remove the unsupported kernel requirement.
Prevent it next time: Record kernel compatibility before guest selection.

Container root is assumed to be host root

Why it happens: User-ID mapping and privilege mode were ignored.
How to fix it: Review the explicit mapping and filesystem owner contract.
Prevent it next time: Preserve numeric ownership context in diagnostics.

Privilege is increased to fix a bind-mount symptom

Why it happens: Mapping and application identity were not diagnosed.
How to fix it: Trace path, mapped IDs and required access before redesigning isolation.
Prevent it next time: Review feature changes as trust-boundary changes.

Check your understanding

1. A Linux workload requires a different kernel module. Is an ordinary LXC container sufficient?

Show worked solution

Not merely because it has Linux userspace. Containers share the host kernel and cannot independently supply arbitrary kernel behavior. Assess a supported VM or an approved host capability design. Record compatibility, trust and recovery implications rather than relaxing container restrictions until the application happens to start.

2. Under the example offset, where does guest UID 42 map, and what does that not prove?