LXC architecture: namespaces and cgroups · Proxmox VE

Why this matters in production

Containers rely on two kernel features: namespaces (visibility) and cgroups (resources). Understanding them lets you reason about what a container can and cannot do.

Namespaces

A namespace wraps a global system resource so a process sees an isolated instance. Linux has seven namespace types relevant to containers:

Namespace	What it isolates
PID	Process IDs (the container sees its own PID 1)
Network	Network devices, IPs, routes
Mount	Mount points
UTS	Hostname and domain name
IPC	Inter-process communication (System V IPC, POSIX message queues)
User	UIDs and GIDs (root in container = different UID on host)
Cgroup	cgroup hierarchy visibility

flowchart LR
  A[Container processes] --> B[PID namespace]
  A --> C[Network namespace]
  A --> D[Mount namespace]
  A --> E[User namespace]

Seeing a namespace, not just reading about one

A namespace is an object in the kernel with an inode number. Two processes are in the same namespace exactly when the inode behind their /proc/<pid>/ns/ entry matches. That makes the abstraction directly observable.

Read-only / Safethe host and a container are in different namespaces - here is the proof

# readlink /proc/self/ns/pid /proc/self/ns/net /proc/self/ns/user
pct exec 200 -- readlink /proc/self/ns/pid /proc/self/ns/net /proc/self/ns/user

pid:[4026531836]
net:[4026531840]
user:[4026531837]
pid:[4026532614]
net:[4026532617]
user:[4026532610]

Illustrative output

Different numbers mean different namespaces. This is worth doing once by hand, because it converts “the container is isolated” from a claim into an observation, and because it is the fastest way to answer “is this process really inside the container” during an incident.

Note what the same command shows for a privileged container: its user namespace inode matches the host’s, because a privileged container is not in a user namespace at all. That single line of output is the whole privileged/unprivileged distinction, expressed mechanically.

cgroups

cgroups (control groups) limit, account for, and isolate resource usage. PVE 9 uses cgroup v2 exclusively - the unified hierarchy, mounted at /sys/fs/cgroup, with no v1 controllers and no hybrid mode. Any guidance you find that refers to memory.limit_in_bytes, cpu.cfs_quota_us or blkio.weight is describing cgroup v1 and does not apply.

flowchart LR
  A[Container processes] --> B[cpu.max: quota and period]
  A --> C[cpu.weight: relative share]
  A --> D[memory.max: hard limit]
  A --> E[pids.max: process count]

The container config maps onto v2 interface files:

Config	cgroup v2 file	Effect
`cores: 4`	cpuset	Which host CPUs its tasks may run on
`cpulimit: 2`	`cpu.max`	Hard bandwidth ceiling
`cpuunits: 100`	`cpu.weight`	Relative share under contention only
`memory: 4096`	`memory.max`	Hard limit; OOM kill at the boundary
`swap: 512`	`memory.swap.max`	Additional swap allowance

Read-only / Saferead a running container's actual limits— Read-only. The cgroup parent directory name has differed between LXC versions, so discover the path rather than hard-coding it.

set -euo pipefail
CTID=200
CG=$(find /sys/fs/cgroup -maxdepth 2 -type d -name "$CTID" \
     -not -path '*monitor*' | head -1)

printf 'cgroup path: %s\n' "$CG"
cat "$CG/memory.max" "$CG/memory.current" "$CG/cpu.max" "$CG/cpu.weight"

Those files are the enforcement. Everything the web interface shows about a container’s limits is a rendering of them, and when the two disagree - which happens after a hand-edited config, or a pct set that did not take - the cgroup is what the kernel obeys. The full treatment is in container resource limits.

What namespaces give you

Visibility isolation: a process in a PID namespace cannot see or signal processes outside it (except via shared resources).
Resource visibility: a mount namespace gives the container its own filesystem hierarchy.
Identity isolation: a user namespace maps UIDs/GIDs so the container’s root is not the host’s root.

What namespaces do NOT give you

Kernel isolation: the container uses the host kernel. A kernel vulnerability in the host affects every container.
Hardware isolation: there is no VMX/SVM boundary.
Trust: a privileged container has many of the same capabilities as the host root.

Unprivileged containers

Proxmox’s unprivileged containers use user namespaces to map the container’s root (UID 0) to a high-numbered UID on the host. This is the default and should be kept.

flowchart LR
  subgraph CONTAINER[Container]
    UID0[UID 0]
  end
  subgraph HOST[Host]
    UID100000[UID 100000]
  end
  UID0 -->|maps to| UID100000

What is missing from that list, and why it decides everything

The seven namespaces cover process IDs, network, mounts, hostname, IPC, users and the cgroup hierarchy. Read the list again and notice what is not there.

There is no namespace for the kernel. There is no namespace for the system clock, for loaded modules, for **/proc/sys** tunables that are not namespaced, or for the page cache. Those are single, shared objects, and every container on the host uses the same one.

This is not an oversight; it is the design. A container is a set of views of a running kernel, achieved by giving processes different lookup tables for particular kinds of object. A VM is a different thing entirely: the hypervisor presents virtual hardware and the guest loads its own kernel onto it, so the guest’s kernel bugs, its clock, its modules and its page cache are all its own.

Two consequences follow that operators meet in practice.

Kernel version is a host property. A container’s userland can be Debian 12, Alma 9 or Alpine, and all of them run on the host’s kernel. Software that requires a specific kernel version, or a module the host does not load, cannot be made to work by changing the container’s distribution. It needs a VM.

A kernel vulnerability is a whole-host vulnerability. A local privilege escalation reachable from an unprivileged process is reachable from inside every container simultaneously. Patching one container patches nothing. This is why the host patching cadence in patching is the security control that actually protects containers, and why container-level updates, useful as they are, address a different threat.

What happens if a process inside a container looks at /proc/meminfo?

It sees the container’s limits, not the host’s - and the mechanism is a piece of software that is not part of the kernel at all.

By default /proc/meminfo is a kernel interface describing the machine, and a container has no machine. Without intervention a container limited to 4 GiB on a 512 GiB host would read 512 GiB, and every application that sizes a cache, a heap or a worker pool from available memory would size itself for a machine a hundred times larger than it has - and then be OOM-killed by a cgroup limit it never knew about.

PVE ships lxcfs, a FUSE filesystem that synthesises per-container versions of /proc/meminfo, /proc/cpuinfo, /proc/stat, /proc/uptime, /proc/diskstats, /proc/swaps and /sys/devices/system/cpu/online from the container’s cgroup values, and bind-mounts them over the real ones.

Three practical points:

It covers a specific list. Anything reading a file not on it - or reading cgroup values directly - sees host reality. A monitoring agent inside a container reporting the host’s CPU count while nproc reports the container’s is this, not a bug in either.
Its failure is silent. If lxcfs is not running, containers do not break; they start believing they own the machine. Include systemctl is-active lxcfs in node health checks.
It is why containers feel like small machines at all. Every “free reports the right number” moment you have taken for granted is this daemon.

systemctl is-active lxcfs
pct exec 200 -- sh -c 'nproc; free -m | head -2'

Production considerations

The container that was 'compromised' and was not

A recurring false alarm, worth recognising because the reasoning behind it is almost right.

The symptom. A security tool inside a container reports processes it cannot account for, or ps output from the host shows the container’s processes running as an unfamiliar high-numbered UID such as 100000, 101000 or 165534. Someone concludes an attacker has created accounts.

What is actually happening. Those are the container’s own processes, seen from the host through the user namespace mapping. Container UID 0 is host UID 100000; container UID 1000 is host 101000. Nothing has been created; you are looking at the same processes through the other end of the map.

Why the first diagnosis is wrong. The UIDs genuinely do not exist in the host’s /etc/passwd, so ps renders them numerically and every tool that looks for “processes running as unknown users” flags them. The heuristic is sound in general and wrong here.

How to settle it in one command - compare the host’s view with the container’s own view of the same PID:

CTID=200
ps -eo pid,user,uid,comm --no-headers | awk '$3 >= 100000'
pct exec "$CTID" -- ps -eo pid,user,uid,comm --no-headers | head

If the host’s 101000 lines correspond to the container’s 1000 lines, the arithmetic is the answer. Investigating an actual compromise is a different exercise, and it starts from the threat model rather than from a UID that looked odd.

Common mistakes

Treating privileged containers as VMs.
Disabling cgroup limits “for performance.”
Running containers with kernel modules the host does not have.
Following cgroup v1 guidance on PVE 9, which is cgroup v2 only.
Reading a container’s memory usage from inside it during an incident, rather than from the host cgroup that is doing the enforcing.

Verification

Three commands that answer “is this container isolated the way I think it is”, and each can fail:

Read-only / Safeconfirm the isolation a container actually has— Read-only. Compare against a container you know is configured correctly - the differences are the answer.

set -euo pipefail
CTID=200

# 1. Is it in a user namespace at all? A privileged container is not.
pct exec "$CTID" -- cat /proc/self/uid_map

# 2. Which namespaces differ from the host's?
for NS in pid net mnt uts ipc user cgroup; do
H=$(readlink "/proc/self/ns/$NS")
C=$(pct exec "$CTID" -- readlink "/proc/self/ns/$NS")
[ "$H" = "$C" ] && printf '%-7s SHARED WITH HOST\n' "$NS" \
                || printf '%-7s isolated\n' "$NS"
done

# 3. Are the limits you configured the limits being enforced?
CG=$(find /sys/fs/cgroup -maxdepth 2 -type d -name "$CTID" \
     -not -path '*monitor*' | head -1)
pct config "$CTID" | grep -E '^(cores|cpulimit|memory|swap):'
cat "$CG/memory.max" "$CG/cpu.max"

Check 1 is the decisive one. 0 100000 65536 is an unprivileged container. 0 0 4294967295 is a privileged container: the whole ID space, identity mapped, which is the mechanical statement of “container root is host root”.

Key takeaways

Namespaces give visibility isolation; cgroups give resource isolation.
Neither provides kernel isolation; containers share the host kernel.
PVE 9 is cgroup v2 only - v1 file names and guidance do not apply.
Default to unprivileged, and verify it by reading uid_map rather than trusting the config field.

Knowledge check

Why this matters

Namespaces and cgroups look like background theory, and they are the two facts that decide almost every practical question you will have about containers.

Why can this container not load a module? Because there is no module namespace. Why did the application size its heap for 512 GiB? Because lxcfs was not running and there is no memory namespace, only a cgroup limit and a synthesised view of it. Why is a privileged container host-equivalent? Because it is not in a user namespace, and uid_map says so in one line. Why does patching the host protect the containers and patching the containers not protect the host? Because there is one kernel.

Every one of those is the same observation applied differently: a container is a set of views of a shared kernel, bounded by accounting. Operators who hold that model answer new container questions correctly without looking anything up. Operators who hold the model “a container is a small VM” get a plausible answer to every one of those questions and the plausible answer is wrong each time.