Incus Resource Limits Guide
This document explains how to prevent Incus containers from consuming all host resources by applying CPU, memory and process limits using profiles.
Containers share the host kernel. Without limits, any container process (for example ffmpeg in PeerTube) can use all available CPU cores and memory.
Using Incus profiles allows applying resource policies to many containers at once.
Inspect Current Container Limits
Check a container configuration:
Incus Networking on Routed /32 Hosts (Hetzner-style)
This document describes the correct and supported networking models for running Incus on hosts with a routed public IPv4 /32, such as Hetzner ARM and similar cloud servers. It also documents common pitfalls, misleading error messages, and the rationale behind the recommended setup.
1. Host Characteristics
Typical properties of these systems:
Incus: Disable AppArmor
This page documents how to disable AppArmor confinement for existing and new Incus containers in the raid1 project. This eliminates AppArmor DENIED spam in kernel logs and journald.
Overview
Incus generates per-container AppArmor profiles. Many containers produce constant AppArmor DENIED messages (e.g. systemd-logind mount attempts). To stop this, containers can be switched to the unconfined AppArmor profile using:
PeerTube Migration btrfs Incus
Diese Dokumentation beschreibt das final empfohlene Setup für die PeerTube-Instanz auf at1 in Verbindung mit:
- einem btrfs‑RAID1 unter
/mnt/raid1, - klar getrennten btrfs‑Subvolumes,
- einem Incus‑Container (
peertubeoderpeertube4), - sauberem Host→Container‑Mounting via Incus‑Disk‑Device,
- korrekt eingerichtetem User‑Namespace‑Mapping.
Das Ziel ist ein robustes, snapshot‑fähiges, sauber getrenntes System, das Migrationen und Backups extrem erleichtert.
Incus Container Image
Diese Doku beschreibt, wie ein bestehender Incus-Container CTNAME in ein wiederverwendbares Image umgewandelt und auf einen anderen Server übertragen wird. Aus diesem Image kann auf dem Zielsystem wieder ein Container erstellt werden.
Es werden zwei Varianten gezeigt:
incus debug
incus start listmonk Error:
Failed start validation for device "net0": MAC address "00:16:3e:7f:0d:73" already defined on another NIC
incus config device unset listmonk net0 hwaddrincus shell web-test
Error while executing alias expansion: incus exec web-test -- su -l
Error: Instance not found
incus_remote_copy.sh
#!/bin/bash
# Script Version: 02
# Description: Automate migration of a single LXC container to Incus and push it to remote project
# Set variables
# ========
LXCHOSTNAME="$1"
REMOTE_NAME="at1"
TARGET_PROJECT="raid1"
DEBUG=1
# Safety checks
# ========
if [ -z "$LXCHOSTNAME" ]; then
echo "[ERROR] Usage: $0 <LXCHOSTNAME>"
exit 1
fi
# Functions
# ========
stop_lxc_container() {
echo "[DEBUG] Stopping LXC container $LXCHOSTNAME"
if lxc-info -n "$LXCHOSTNAME" &>/dev/null; then
lxc-stop -n "$LXCHOSTNAME" 2>/dev/null || true
else
Incus: Remote-Server mit Trust-Token
Diese Dokumentation beschreibt, wie ein lokaler Incus‑Client mit einem entfernten Incus‑Server per Trust‑Token verknüpft wird.
Beispielszenario:
incus_remote_rsync.sh
#!/bin/bash
# Script Version: 04
# Description: Incus migration helper (DEV state)
# ======= USAGE =======
# Usage: ./incus_remote_rsync.sh <container-name> <target-host> [project] [--snapshot] [--no-compress]
# Examples:
# ./incus_remote_rsync.sh zammad 80.109.18.113 raid1 --snapshot
# ./incus_remote_rsync.sh zammad 80.109.18.113
# ./incus_remote_rsync.sh peertube 80.109.18.113 raid1 --no-compress
# ======= ARGS & DEFAULTS =======
if [ -z "$1" ] || [ -z "$2" ]; then
echo "Usage: $0 <container-name> <target-host> [projectLXC2Incus
A comprehensive guide for system administrators, self‑hosters, and advanced Linux users who want to migrate from classic LXC to Incus. The process ensures reliable container management, persistent networking, and smooth integration with storage and firewall systems.