LXC Containers¶
LXC (Linux Containers) provides lightweight system containers — a full Linux userspace with its own init system, networking, and process tree, but sharing the host kernel. Think of it as something between Docker and a full VM.
Where to find it: Infrastructure > Server View — LXC containers appear as nodes in the resource tree alongside your VMs and Docker apps.
When to Use LXC vs Docker vs VMs¶
| Docker | LXC | VM | |
|---|---|---|---|
| What runs | A single process / app | A full OS userspace | A complete OS with its own kernel |
| Overhead | Near zero | Very low | Moderate (RAM + CPU reserved) |
| Init system | No (PID 1 is your app) | Yes (systemd, OpenRC, etc.) | Yes |
| Isolation | Process-level | OS-level (shared kernel) | Full hardware-level |
| Boot time | Seconds | Seconds | 10-30 seconds |
| Best for | Single-purpose apps (Plex, Sonarr, Pi-hole) | Services needing systemd, multi-process stacks, dev environments | Different OS kernels, Windows, untrusted workloads |
Rule of thumb: Use Docker for the bulk of your apps — it's what most of the App Store catalog uses. Use LXC for services that need a real init system or where you'd otherwise spin up a full VM. Use VMs when you need a different kernel or full isolation.
Creating an LXC Container¶
- Go to Infrastructure > Server View
- Click Create CT
- Configure:
- Name — name for the container
- Node — which node to create it on
- Distribution, Release, Arch, Variant — chosen from a live list of what's actually available; nothing is picked for you by default
- Set up networking
- Create
The container downloads the image (if not cached) and starts within seconds. Networking is wired up automatically (the container comes up on the host bridge with DHCP). CPU and memory limits are not set at creation — they're part of the container's underlying configuration, not the create wizard.
Lifecycle Management¶
From the container's detail view in the Infrastructure page:
| Action | Description |
|---|---|
| Start | Boot the container |
| Stop | Graceful shutdown |
| Delete | Remove the container and its root filesystem |
Console Access¶
Click on a running LXC container in the Infrastructure tree to open its detail view. The Console tab gives you a terminal session inside the container, directly in your browser. This is a real PTY — tab completion, scrollback, everything works.
Snapshots¶
Point-in-time snapshots are managed from the container's Snapshots tab.
Snapshots need a snapshottable backing store
lxc-snapshot only works on containers backed by overlayfs, btrfs, zfs, or lvm. Containers created through the Create CT wizard are dir-backed, and dir-backed containers cannot be snapshotted — the dashboard rejects the request up front with a message telling you to either recreate the container on a snapshottable backing store or use Backup instead.
For the common case — a dir-backed container — use Backup (below), not Snapshots. Backup is the supported path for dir-backed containers.
Backup¶
Every LXC container has a Backup tab in its detail view. A backup is a full tar.gz archive of the container's rootfs, and unlike snapshots it works on any container regardless of backing store.
| Action | Description |
|---|---|
| Create | Archive the container's rootfs to a .tar.gz backup |
| List | View backups with timestamps and sizes |
| Restore | Restore the container from a previous backup |
Backups can be stored locally or sent to Eight.ly Backup Server (EBS) — the Backup tab shows a Local/EBS badge on each entry.
Resource Limits¶
The container's Resources tab shows its CPU, memory, and swap limits, and root disk size. Editing these from the dashboard isn't available today — they're part of the container's underlying configuration.
LXC containers share the host kernel's scheduler, so unused CPU and memory remain available to other containers and the host.
Rehome (High Availability)¶
LXC containers can be protected by Rehome, Eight.ly's HA arc, with two conditions VMs don't have: the container's rootfs must be on shared storage (a node-local rootfs can't be relocated), and a node failure must be confirmed — fenced — before Eight.ly will move the container. A relocated container comes back up cold on the new node; there's no live-migration equivalent for LXC the way there is for VMs. Rehome lives behind Settings > Experimental > Clustering & High Availability, off by default.
Related Guides¶
- Virtual Machines — for workloads that need full isolation or a different kernel
- Web Dashboard — overview of the Infrastructure page and sidebar navigation
- Architecture — how Eight.ly's infrastructure layer works under the hood