Incus Containers and VMs: Installation to Daily Management - 夜莺博客

Incus Containers and VMs: Installation to Daily Management

Incus is the fork of LXD that many production users migrated to, and it keeps the thing that made LXD popular: one CLI that manages both system containers (full Linux userspaces, near-native performance) and virtual machines (real kernels, real isolation) with the same commands. If you have been running VMs for services that would happily live in a container — or containers for workloads that need a kernel module — Incus lets you mix them without learning two tools. This is the working guide: install, init, launch, tune, snapshot.

Install and Give Yourself Control

# Debian/Ubuntu (Zabbly repository is the upstream-recommended source)
sudo apt install incus incus-client        # distro package, or use the Zabbly repo for the newest release
sudo adduser $USER incus-admin
newgrp incus-admin

Membership in incus-admin grants full control of the daemon — treat it like docker group membership and do not hand it out casually. Users in the plain incus group get a per-user project and cannot see other projects.

Initialise the Daemon

incus admin init
# or, to skip the questions and take the defaults:
incus admin init --minimal

The interactive init asks about clustering, storage pool backend (dir, ZFS, Btrfs, LVM), network bridge and whether to create a default profile. ZFS or Btrfs gives you cheap snapshots, which is the whole reason to run Incus rather than plain VMs.

Launch a Container and a VM

incus launch images:debian/13 my-ct
incus launch images:ubuntu/24.04 my-vm --vm

# Or create without starting, to configure first:
incus init iso-vm --empty --vm
incus init iso-vm --empty --vm -c limits.cpu=2 -c limits.memory=4GiB -d root,size=50GiB

Both instance types are called instances; the only difference at launch time is --vm.

Inspect and Resize

incus list
incus info my-ct
incus exec my-ct -- free -m          # containers: run a command directly
incus exec my-vm -- df -h            # VMs with the agent installed
incus config show my-ct
incus config device override my-vm root size=30GiB
incus restart my-vm

Resource limits are config keys, not a separate API: limits.cpu, limits.memory, limits.disk.priority. You can change limits.memory on a running container and see the change immediately inside it — one of the more useful differences from a hypervisor.

Profiles Beat Per-Instance Flags

incus profile create bigger-root
incus profile device set bigger-root root pool=default size=50GB
incus profile device set bigger-root root path=/ type=disk
incus profile assign my-vm default,bigger-root
incus config show my-vm | grep -A4 profiles

Keep one profile per platform role (web, database, lab) and assign them; editing ten instances by hand is how you end up with a fleet nobody understands.

Snapshots and Copy

incus snapshot create my-ct pre-upgrade
incus snapshot list my-ct
incus restore my-ct pre-upgrade
incus copy my-ct my-ct-clone
incus copy my-ct remote:prod-ct --instance-only

With a snapshot-capable backend, snapshots are near-instant and cost only the delta. Take one before every upgrade — this is the single highest-value habit in an Incus workflow.

Networking in One Paragraph

Incus creates a managed bridge (incusbr0) by default with its own DHCP and DNS, so instances get names that resolve. For real deployments you will either attach instances to a macvlan interface on the physical NIC (each instance appears directly on the LAN, DHCP from your real server) or bridge the instance's NIC to an existing VLAN-aware bridge. Set it declaratively once:

incus network list
incus network show incusbr0
incus config device add my-ct eth1 nic network=incusbr0

Troubleshooting a Failed Boot

incus info my-vm --show-log
incus start my-ct ; incus console --show-log my-ct
incus config show my-vm

For VMs, --show-log prints the QEMU/serial log; the most common causes of a VM that starts and immediately dies are missing /dev/kvm (virtualisation disabled in BIOS) or a root disk smaller than the image requires.

When to Choose Which

  • Container for services: near-native CPU and I/O, tiny memory overhead, starts in a second.
  • VM when you need a different kernel, kernel modules, or stronger isolation boundaries between tenants.
  • Neither if what you actually wanted was a scheduler and rolling deploys — that is Kubernetes' job, not Incus'.

Related Reading

Deeper dives on the same topics from our archive:

原文链接:https://linuxcontainers.org/incus/docs/main/tutorial/first_steps/