LXC containers alongside virtual machines

Building one

Distribution, release and architecture come out of the templates already in the cache; more are fetched under Images & ISOs. The CPU and memory limits are set while you are there rather than afterwards, and so is the network — with a fixed address instead of DHCP if you want one — the root password and an SSH key.

Because a container has no firmware and no bootloader, none of it is asked. What takes the time is unpacking the root filesystem, and that runs as a background task with a log.

A real terminal, not a form

The console of a container is a shell. Phillux starts lxc-attach on a pseudo-terminal and pushes the bytes both ways; in the browser xterm.js draws them. Line editing, colours, curses programs — it behaves like the terminal it is.

The same way in is used for questions that have to be answered without a network: a lab check, the verification of a backup, an assistant looking whether the service it just installed is actually running.

Limits that hold

CPU shares and a memory limit hang off the container itself. They are cgroup settings, so they take effect on a running container without restarting it.

Live charts and resource limits are built for containers too, not only for VMs. Where a feature makes sense on both, it exists on both — that was a deliberate rule and not an accident of the order things were written in.

Snapshots are more expensive here — say so

A container snapshot is a full copy. lxc-snapshot on a directory-backed container clones the whole root filesystem: half a gigabyte of container is half a gigabyte per snapshot, every single time. That is not a detail to bury in a manual — it is the number that decides whether a nightly snapshot is a good idea.

The cost is shown before it is taken, and the same clean-up rule that limits VM snapshots limits these, with the same exception for lab stages.

Stopping without stopping

A container can be frozen instead of shut down. Freezing is a write to a cgroup file: it takes no measurable time, needs no cooperation from anything inside, and is completely reversible.

That is also how the emergency brake halts a container it thinks is encrypting itself — see the emergency brake.

The firewall, bound differently

A container is not a libvirt domain, so there is nothing to write a filter reference into. Instead the filter is bound straight to the host-side veth device. Such a binding lives only as long as the device — it disappears when the container stops and is set again when it starts.

The rules themselves are the same rules a VM gets, and they hang off the guest's device, never off the host's.

Where a container is the wrong answer A container shares the host's kernel. A guest that needs another kernel, another operating system, its own kernel modules or a firmware setting of its own belongs in a virtual machine — and everything about running one is on the same page for both.