Learn LXC - Resource Limits with cgroups

#Introduction

In episode 6 your container has networking. But what stops one container from consuming all 32 GB of host RAM? The answer: cgroups. In episode 7 we set resource limits via cgroup2 — the concept we introduced in episode 2 — then verify them with LXC's built-in tools and the host system. Without limits, a single memory-leaking application can bring down the entire host.

#Why Resource Limits Matter

cgroups are the electricity meter per unit in our building: namespaces limit "what you can see", cgroups limit "what you're allowed to use". Without cgroups, the misbehavior of one container (full CPU loop, memory leak) will disrupt all other tenants. With proper limits:

• One container can't bring down the host or other containers.
• Host capacity can be planned and accounted for (episode 18).
• QoS across workloads becomes predictable.

#Configuring Limits in the Container Config

Modern LXC uses cgroup2, and limits are written directly into the container config with the lxc.cgroup2. prefix. The container config file lives at /var/lib/lxc/<name>/config. Here's a complete example for container c1:

/var/lib/lxc/c1/config (limits)

# Memory limit: max 512MB
lxc.cgroup2.memory.max = 512M
 
# CPU limit: 200000/100000 = 2 full cores
lxc.cgroup2.cpu.max = 200000 100000
 
# Tell the kernel to keep swappiness low for the container
lxc.cgroup2.memory.swap.max = 0
 
# I/O priority (0-10000), the smaller the more prioritized
lxc.cgroup2.io.weight = 100

Let's break down each line:

• lxc.cgroup2.memory.max = 512M — the main memory limit. If the container exceeds it, the kernel will apply pressure or OOM-kill processes inside. Units can be K, M, G, or raw byte numbers.
• lxc.cgroup2.cpu.max = 200000 100000 — format is <quota> <period> in microseconds. 200000/100000 means 2 cores; 50000/100000 means half a core.
• lxc.cgroup2.memory.swap.max = 0 — disables swap for the container, making the memory limit stricter.
• lxc.cgroup2.io.weight = 100 — scale 1-10000; affects how large a share of block I/O bandwidth the container gets relative to other containers.

#Applying and Verifying

#Apply the Limits

After editing the config, restart the container so the limits take effect:

lxc-stop -n c1
lxc-start -n c1

#Verify via lxc-cgroup (Legacy)

The lxc-cgroup tool lets you view and change container cgroup values directly. Read the current values:

lxc-cgroup -n c1 memory.max
lxc-cgroup -n c1 cpu.max

#Verify via systemd-cgls on the Host

The most reliable way is to view the cgroup hierarchy directly from the host. Find the container in the systemd tree:

systemd-cgls /lxc/c1

You can also read the cgroup files directly:

cat /sys/fs/cgroup/lxc/c1/memory.max
cat /sys/fs/cgroup/lxc/c1/cpu.max

If the numbers read match what you configured, the limits are in effect.

#Real-World Test: Prove the Limits Work

The best proof is an experiment. Enter the container and try to allocate more memory than the limit:

lxc-attach -n c1 -- dd if=/dev/zero of=/dev/null bs=1M count=10000

With a 512M limit, this process will be OOM-killed or pressured — while the host stays healthy. On the CPU side:

lxc-attach -n c1 -- sh -c 'while :; do :; done &'

Monitor CPU usage from the host with top and systemd-cgtop:

systemd-cgtop

The container's CPU will be locked to its allocation (e.g. 200%), no more.

#Planning Limits

Practical planning rules:

• Memory: give a bit more than the workload's peak need (e.g. app needs 400M → limit 512M), but never more than total host RAM divided by the number of containers.
• CPU: quotas should sum to ≤ the host's total cores if all containers are active simultaneously, or use a looser cpu.max if workloads are bursty and complementary.
• Always verify after applying — a typo in the limit (e.g. 500M vs 500m) can produce unexpected numbers.

#Closing

Key takeaways:

• cgroups (cgroup2) are the resource allocators: memory, CPU, and I/O.
• lxc.cgroup2.memory.max and lxc.cgroup2.cpu.max are the main keys in the container config.
• lxc-cgroup is a legacy tool; systemd-cgls, systemd-cgtop, and files in /sys/fs/cgroup are the modern verification.
• Test limits with real experiments: dd for memory, a loop for CPU.
• Plan limits so total demand doesn't exceed host capacity.

In the next episode 8 we'll cover storage: rootfs, images & snapshots — the dir, btrfs, zfs, LVM, and loop backends along with lxc-create --bdev/--fstype, plus the role of the download template, lxc-copy, and lxc-snapshot in image management.