Incus-Systemcontainer auf einem VPS einrichten

Was ein Incus-Systemcontainer ist

Incus-Systemcontainer auf einem VPS stellen Ihnen eine vollständige Maschine mit eigenem Init-System und eigenen Benutzerkonten bereit, nicht nur einen einzelnen Prozess mit angehängtem Dateisystem. Der Container startet, führt ein Init-System als PID 1 aus und beantwortet systemctl. Er verwendet den Kernel des Hosts gemeinsam mit diesem und ist daher keine virtuelle Maschine. Alles oberhalb des Kernels verhält sich wie auf einer eigenen Maschine.

Incus ist ein Community-Fork von LXD und wird im Rahmen des Linux-Containers-Projekts gepflegt. Das Clientprogramm ist incus. Mit --vm führt es über QEMU auch echte virtuelle Maschinen aus. Der Systemcontainer ist jedoch der Grund, warum die meisten Benutzer Incus installieren. Um ihn geht es im restlichen Verlauf dieses Leitfadens.

Warum Docker-Vergleiche in die Irre führen

Docker paketiert einen Prozess. Incus paketiert ein Betriebssystem. Die Incus-Dokumentation beschreibt die Abgrenzung direkt: „Anwendungscontainer (wie sie beispielsweise von Docker bereitgestellt werden) paketieren einen einzelnen Prozess oder eine einzelne Anwendung. Systemcontainer simulieren dagegen ein vollständiges Betriebssystem, ähnlich dem System, das Sie auf einem Host oder in einer virtuellen Maschine ausführen würden.“

Dieser Unterschied bestimmt, wie Sie die jeweilige Umgebung im Alltag verwenden.

• Ein Docker-Image enthält kein Init-System, daher schlägt systemctl darin fehl. Ein Incus-Container führt ein Init-System aus, sodass Dienste und Timer wie auf einem Server funktionieren.
• Ein Docker-Container ist dafür vorgesehen, gelöscht und aus einem Dockerfile neu erstellt zu werden. Ein Incus-Container ist dafür vorgesehen, erhalten, aktualisiert und als Snapshot gespeichert zu werden.
• Ein Docker-Image ist ein Build-Artefakt, das Sie in eine Registry übertragen. Eine Incus-Instanz ist ein auf einem Storage-Pool gespeicherter Zustand, den Sie mit incus export verschieben.
• Docker isoliert eine Arbeitslast. Incus isoliert eine Maschine. Daher kann ein Container mehrere Arbeitslasten und mehrere Benutzerkonten enthalten.

Sie können Docker in einem Incus-Systemcontainer ausführen. Incus würden Sie nicht in einem Docker-Anwendungscontainer ausführen. Wenn Sie tatsächlich einen Prozess pro Container mit einem Image-Build-Schritt benötigen, ist Podman und Docker auf einem VPS der erste Vergleich, den Sie lesen sollten. Wenn Sie statt eines gemeinsam genutzten Kernels einen eigenen Kernel pro Arbeitslast benötigen, gehen Firecracker-MicroVMs auf einem VPS in die andere Richtung.

Läuft Incus innerhalb eines VPS?

Das hängt vom Virtualisierungstyp und vom Kernel Ihres VPS ab. Prüfen Sie daher beides, bevor Sie etwas installieren. Verlassen Sie sich dabei nicht auf die Marketingseite des Anbieters. Führen Sie diese vier Befehle auf dem System aus.

systemd-detect-virt
uname -r
stat -fc %T /sys/fs/cgroup
cat /sys/fs/cgroup/cgroup.controllers

systemd-detect-virt, kvm oder qemu bedeutet, dass Ihr VPS eine virtuelle Maschine mit eigenem Kernel ist. Das ist der einfache Fall, weil sich Incus dann wie auf echter Hardware verhält. lxc, lxc-libvirt oder openvz bedeutet, dass Ihr VPS selbst ein Container ist, der den Kernel des Anbieters gemeinsam nutzt. Incus-Container darin sind verschachtelte Container. Verschachtelung funktioniert nur, wenn der Anbieter sie für Ihren Container aktiviert hat. Sie können sie nicht innerhalb des Containers aktivieren, weil die Einstellung auf dem Host liegt, den Sie nicht kontrollieren.

stat -fc %T /sys/fs/cgroup sollte cgroup2fs ausgeben. Jede andere Ausgabe bedeutet, dass das System ein cgroup-Layout (control group) der Version 1 oder ein hybrides Layout verwendet. Aktuelle Incus-Versionen zielen nicht auf diese Layouts ab.

cat /sys/fs/cgroup/cgroup.controllers listet die an Sie delegierten Controller der Control Groups auf. Incus dokumentiert blkio, cpuset, devices, freezer, memory und pids als erforderlich. Bei einem verschachtelten VPS ist diese Liste oft kürzer als bei einem KVM-VPS, weil der Anbieter festlegt, welche Controller weitergereicht werden. Fehlt ein Controller in dieser Datei, kann Incus ihn nicht verwenden. Das davon abhängige Instanzlimit steht Ihnen dann nicht zur Verfügung.

Die Kernel-Version ist heute wichtiger als früher. Im August 2026 nennt die Incus-Dokumentation für die beiden vom Upstream gepflegten Zweige zwei unterschiedliche Mindestversionen. Für den Zweig 6.0 LTS (long term support) gilt: "The minimum supported kernel version is 5.4." Für den aktuellen Stable-Zweig gilt: "The minimum supported kernel version is 6.12." Ubuntu 24.04 stellt die Serie 6.0 LTS in seinem eigenen Repository bereit und kombiniert sie mit einem 6.8-Kernel. Diese Kombination wird unterstützt. Wenn Sie dagegen den aktuellen Stable-Build aus dem Upstream-Repository auf demselben 6.8-Kernel installieren, unterschreiten Sie die dokumentierte Mindestversion. Lesen Sie daher uname -r, bevor Sie ein Repository auswählen.

Wenn Sie vollständige virtuelle Maschinen statt Container ausführen möchten, ist die Einschränkung eine andere und schwieriger zu erfüllen. Unter verschachtelte Virtualisierung auf einem VPS erfahren Sie, ob Ihr VPS /dev/kvm überhaupt bereitstellen kann. Informationen zum Fall, in dem Sie die Hardware besitzen, finden Sie unter Proxmox auf einem gemieteten VPS.

Incus unter Ubuntu oder Debian installieren

Debian 13 sowie Ubuntu 24.04 und neuere Versionen stellen Incus in ihren eigenen Repositorys bereit.

sudo apt update
sudo apt install -y incus

Unter Debian installiert incus-base die Container-Unterstützung ohne die Komponenten für virtuelle Maschinen. Fügen Sie unter Ubuntu qemu-system hinzu, wenn Sie auch --vm-Instanzen verwenden möchten.

Für eine neuere Version als die, die Ihre Distribution bereitstellt, finden Sie die Upstream-Pakete unter pkgs.zabbly.com. Diese Befehle stammen aus der README-Datei des projek eigenen Repositorys.

sudo apt update && sudo apt install -y curl
sudo mkdir -p /etc/apt/keyrings/
sudo curl -fsSL https://pkgs.zabbly.com/key.asc -o /etc/apt/keyrings/zabbly.asc
sudo sh -c 'cat <<EOF > /etc/apt/sources.list.d/zabbly-incus-stable.sources
Enabled: yes
Types: deb
URIs: https://pkgs.zabbly.com/incus/stable
Suites: $(. /etc/os-release && echo ${VERSION_CODENAME})
Components: main
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/zabbly.asc
EOF'
sudo apt-get update
sudo apt-get install -y incus

Geben Sie Ihrem Benutzer anschließend Zugriff auf den Daemon-Socket.

sudo usermod -aG incus-admin "$USER"
newgrp incus-admin
incus info

Wenn incus info die Serverkonfiguration ausgibt, funktioniert der Socket. Ein Berechtigungsfehler bedeutet, dass die Gruppenänderung Ihre Shell noch nicht erreicht hat. newgrp incus-admin wendet sie für die aktuelle Shell an. Eine neue Anmeldung übernimmt die Änderung dauerhaft. Behandeln Sie die Mitgliedschaft in incus-admin auf dem Host wie root, weil der Zugriff auf diesen Socket die vollständige Kontrolle über einen als root laufenden Daemon ermöglicht. Einige Distributionen erstellen außerdem eine einfache Gruppe incus für eingeschränkten Benutzerzugriff.

Initialisieren Sie nun den Daemon.

sudo incus admin init

Beantworten Sie die Fragen, anstatt auf incus admin init --minimal zurückzugreifen. Der minimale Pfad wählt den Speichertreiber dir. Im nächsten Abschnitt wird erklärt, warum Sie diese Entscheidung später weiter begleitet.

Starten Sie etwas und prüfen Sie, ob es funktioniert.

incus launch images:debian/13 web
incus list
incus exec web -- bash

incus list sollte web als RUNNING mit einer IPv4-Adresse im Subnetz incusbr0 anzeigen. Wenn keine Adresse vorhanden ist, wurde DHCP (Dynamic Host Configuration Protocol) nicht abgeschlossen. Das wird im Abschnitt zur Netzwerkkonfiguration behandelt. Ein Container, der nicht startet, gibt den Grund in incus info web --show-log aus. Fehler auf Daemon-Ebene landen in sudo journalctl -u incus -n 50. Wenn systemd-detect-virt auf einem VPS lxc oder openvz zurückgegeben hat, ist dieser Start der aussagekräftige Test dafür, ob Ihnen Verschachtelung zur Verfügung steht.

Warum das Standard-Storage-Backend wichtig ist

Das Storage-Backend bestimmt, ob ein Snapshot sofort erstellt wird oder ob eine vollständige Kopie des Container-Datenträgers angelegt wird. Diese Entscheidung bei der Installation lässt sich später nicht kostengünstig ändern.

Incus unterstützt dir, btrfs, lvm, zfs, Ceph und mehrere Remote-Treiber. Bei einem VPS mit nur einer Festplatte fällt die tatsächliche Wahl zwischen dir und btrfs.

Der Treiber dir speichert jeden Container als normale Dateien und Verzeichnisse unter /var/lib/incus. Incus bezeichnet ihn als „deutlich langsamer als alle anderen Treiber“, weil jedes Image entpackt und vollständig kopiert werden muss, anstatt auf gemeinsam genutzte Blöcke zu verweisen. Ein Snapshot eines Containers mit 4 GiB schreibt 4 GiB und benötigt genauso lange wie cp -a. Festplattenkontingente funktionieren nur mit ext4 oder XFS und aktivierten Project Quotas auf Dateisystemebene. Das ist bei den meisten VPS-Images standardmäßig nicht aktiviert. Daher hat ein Festplattenlimit auf einem dir-Pool häufig keine Wirkung.

btrfs und zfs arbeiten nach dem Copy-on-Write-Verfahren. Ein Snapshot enthält daher nur die Blöcke, die danach geändert werden. Incus nennt diese beiden Backends als empfohlene Optionen. Snapshots werden dadurch nahezu sofort erstellt. Festplattenkontingente verwenden die integrierte Quota-Unterstützung des Dateisystems.

Die meisten VPS-Tarife stellen eine einzelne Festplatte ohne freie Partition bereit. Legen Sie den Pool daher in einer Loop-Datei an. Incus übernimmt das automatisch, wenn Sie kein source= angeben.

sudo apt install -y btrfs-progs
incus storage create fast btrfs size=30GiB
incus profile device set default root pool=fast
incus launch images:debian/13 web2 -s fast

Ohne size= verwendet ein Loop-basierter Pool 20% des freien Festplattenspeichers, mindestens 5 GiB und höchstens 30 GiB. Legen Sie diesen Wert bewusst fest. Die Loop-Datei liegt auf dem Root-Dateisystem. Daher teilen sich der Pool und der Host den freien Speicherplatz. Wenn der Pool voll läuft, wird auch die Festplatte des Hosts voll.

ZFS ist unter Debian und Ubuntu ein DKMS-Modul und kein integriertes Kernel-Modul. Daher wird es bei jedem Kernel-Upgrade neu gebaut und kann dabei fehlschlagen. Auf einem Server, den Sie nicht täglich überwachen, verursacht btrfs von den beiden Optionen weniger Wartungsaufwand.

Die drei Netzwerkmodi und was jeder davon verfügbar macht

incus admin init erstellt eine verwaltete Bridge namens incusbr0 und verbindet jede neue Instanz damit. Das ist eine von drei Möglichkeiten, einen Container anzubinden. Die beiden anderen gibt es, weil die erste Möglichkeit Ihre Container hinter NAT (Network Address Translation) verbirgt.

Verwaltete Bridge. incusbr0 erhält ein privates Subnetz. Der Host verwendet darin die erste Adresse und fungiert als Gateway. Incus stellt darin DHCP und DNS (Domain Name System) bereit. Ausgehender Datenverkehr verlässt den Host über seine öffentliche Adresse, wobei Source NAT angewendet wird. Von außen erreicht den Container zunächst nichts. Sie müssen den Zugriff ausdrücklich freigeben. Leiten Sie dazu einen Port mit einem Proxy-Gerät weiter.

incus config device add web http proxy listen=tcp:0.0.0.0:8080 connect=tcp:127.0.0.1:80 nat=true

nat=true leitet den Datenverkehr mit Netfilter-Regeln weiter, statt ihn über eine separate Userspace-Verbindung zu proxyn. Dadurch bleibt die echte Adresse des Clients in den Logs des Containers erhalten. Incus unterstützt diesen Modus nur, wenn der Host das Gateway der Instanz ist. Genau das ist beim Fall incusbr0 gegeben.

macvlan. Der Container erhält im physischen Netzwerk des Hosts eine eigene MAC-Adresse (Media Access Control). Auf den meisten VPS-Plattformen schlägt das fehl, weil der Port des virtuellen Switches an die MAC-Adresse Ihrer VM gebunden ist und Frames von anderen MAC-Adressen verwirft. Es gibt außerdem eine zweite Einschränkung, die auch funktionierende Konfigurationen betrifft. Incus dokumentiert: „macvlan-Geräte können untereinander und mit dem externen Netzwerk kommunizieren, aber nicht mit ihrem übergeordneten Gerät. Daher können Sie macvlan nicht verwenden, wenn Ihre Instanzen mit dem Host selbst kommunizieren müssen.“

Geroutet. Dieser Modus funktioniert auf einem VPS mit zusätzlichen Adressen normalerweise. Incus beschreibt das Gerät als eines, das „ein virtuelles Geräte-Paar erstellt, um den Host mit der Instanz zu verbinden, und statische Routen sowie Proxy-ARP/NDP-Einträge einrichtet, damit die Instanz dem Netzwerk einer festgelegten übergeordneten Schnittstelle beitreten kann“. ARP steht für Address Resolution Protocol. Der Container behält eine öffentliche Adresse. Der Host beantwortet ARP-Anfragen für diese Adresse. Der Provider sieht daher weiterhin nur die MAC-Adresse des Hosts.

incus config device add web eth0 nic nictype=routed parent=enp1s0 ipv4.address=203.0.113.20

Übernehmen Sie den Namen der übergeordneten Schnittstelle aus ip route show default. Aktuelle Images verwenden Namen wie enp1s0 oder ens3, nur selten eth0. Wenn Sie das Gerät eth0 nennen, überschreiben Sie das Gerät, das vom Profil default bereitgestellt wird. Der Container landet dadurch an der gerouteten Schnittstelle statt an der Bridge. Prüfen Sie das Ergebnis innerhalb des Containers mit ip a und ip route.

Warum ein Container einen Dienst auf dem Host erreicht hat

Ein Container auf incusbr0 verfügt über einen eigenen Netzwerk-Namespace. Zwischen dem Container und dem Host besteht jedoch keine Firewall-Grenze. Der Host befindet sich unter der Gateway-Adresse in diesem Bridge-Netzwerk. Aus dem Container ist er daher ein direkt erreichbarer Nachbar. Jeder Host-Dienst, der an 0.0.0.0 gebunden ist, nimmt dort Verbindungen an.

Prüfen Sie das selbst. Zeigen Sie auf dem Host, welche Dienste auf Ports lauschen.

sudo ss -tlnp

Richten Sie die Anfrage anschließend aus einem Container an das Gateway, das ip route meldet.

ip route show default
nc -zv 10.0.0.1 6379

Wenn eine Datenbank, ein Metrik-Endpunkt oder ein Administrationsbereich auf dem Host an 0.0.0.0 gebunden ist, ist diese Prüfung erfolgreich. Die Netzwerk-Firewall Ihres Providers hat das Paket nie gesehen, weil es das System nicht verlassen hat. Genau das überrascht bei den meisten Fragen nach dem Muster „Wie konnte es diesen Dienst erreichen?“: Der Container ist durch NAT vom Internet isoliert, aber zum Host besteht keine entsprechende Isolation.

Binden Sie Host-Dienste nach Möglichkeit an 127.0.0.1. Filtern Sie anschließend die Bridge auf dem Host. Auf einem System mit ufw blockiert die standardmäßige Deny-Richtlinie bereits den Datenverkehr vom Container zum Host. Dadurch funktionieren DNS und DHCP von Incus nicht mehr. Die Incus-Dokumentation nennt als Lösung sudo ufw allow in on incusbr0. Dieser einzelne Befehl öffnet jeden Host-Port erneut für jeden Container. Erlauben Sie stattdessen nur, was die Container tatsächlich benötigen.

sudo ufw allow in on incusbr0 to any port 53 proto udp
sudo ufw allow in on incusbr0 to any port 53 proto tcp
sudo ufw allow in on incusbr0 to any port 67 proto udp
sudo ufw route allow in on incusbr0
sudo ufw route allow out on incusbr0

Die beiden ufw route-Regeln ermöglichen es dem Datenverkehr der Instanzen, den Host zum Internet zu durchlaufen. Ohne diese Regeln verwirft die geroutete ufw-Richtlinie weitergeleitete Pakete. Die Container erhalten dann zwar eine Adresse, erreichen aber nichts.

Snapshots und Profile

Ein Snapshot ist eine zeitpunktbezogene Kopie der Instanz innerhalb ihres Storage-Pools.

incus snapshot create web pre-upgrade
incus info web
incus snapshot restore web pre-upgrade
incus snapshot delete web pre-upgrade

incus info web listet die Snapshots auf, die die Instanz enthält. Planen Sie Snapshots pro Instanz.

incus config set web snapshots.schedule=@daily
incus config set web snapshots.expiry=4w

Ein Snapshot liegt im selben Pool, auf derselben Festplatte und auf demselben Server. Er schützt Sie vor einem fehlerhaften Upgrade. Er schützt Sie nicht vor einem ausgefallenen Datenträger oder einer gelöschten Instanz. Das Backup ist incus export, und die Datei muss den Server verlassen.

incus export web /root/web-backup.tar.gz
incus import /root/web-backup.tar.gz

Ein Profil ist eine benannte Gruppe von Konfigurationsschlüsseln und Geräten, die auf Instanzen angewendet wird. Jede Instanz erhält das Profil default, sofern Sie nichts anderes angeben. Dieses Profil stellt die Root-Disk und die Netzwerkschnittstelle der Instanz bereit. Wenn Sie default bearbeiten, ändern Sie jede Instanz, die dieses Profil verwendet. Das ist nützlich, ermöglicht aber auch, das Netzwerk gleichzeitig von zwanzig Containern zu trennen.

incus profile create small
incus profile set small limits.memory=512MiB
incus profile set small limits.cpu=1
incus launch images:debian/13 api -p default -p small

Profile werden in der angegebenen Reihenfolge angewendet. Daher hat ein Schlüssel aus dem zuletzt aufgeführten Profil Vorrang. Mit incus config show api --expanded sehen Sie, welche Konfiguration eine Instanz tatsächlich erhalten hat.

Docker innerhalb eines Incus-Containers ausführen

Docker innerhalb eines Incus-Systemcontainers benötigt aktiviertes Nesting, weil Docker eigene Namespaces und Mounts erstellt, die ein Container standardmäßig nicht erstellen darf.

incus config set web security.nesting=true
incus restart web

Incus dokumentiert security.nesting als „Ob Nesting innerhalb der Instanz erlaubt werden soll“. Für Container ist der Standardwert false. Zwei weitere Punkte stammen direkt aus der Incus-FAQ. Ein Container kann keine Kernelmodule laden. Ein von Docker benötigtes Modul muss daher auf dem Host geladen und mit incus config set web linux.kernel_modules overlay,br_netfilter angegeben werden. Wenn Sie innerhalb des Containers eine Datei /.dockerenv erstellen, überspringt Docker einige Prüfungen, die in einer verschachtelten Umgebung fehlschlagen.

Auf Ubuntu-24.04-Hosts können die Einschränkungen von AppArmor für nicht privilegierte User-Namespaces den von runc ausgeführten pivot_root blockieren. Docker innerhalb des Containers gibt Folgendes aus:

failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error jailing process inside rootfs: pivot_root .: permission denied

Die dmesg-Ausgabe auf dem Host enthält dann eine Zeile mit apparmor="DENIED" operation="pivotroot" class="mount". Die naheliegende Einstellung ist kernel.apparmor_restrict_unprivileged_userns. Das Deaktivieren dieser Einstellung ist jedoch keine zuverlässige Lösung. Der Upstream-Incus-Fehlerbericht zu genau dieser Ablehnung dokumentiert, dass die Einstellung auf 0 das Problem nicht behoben hat. Lesen Sie zuerst dmesg, um die Ablehnung zu prüfen. So stellen Sie fest, ob AppArmor tatsächlich die Ursache ist, bevor Sie einen Sicherheitsstandard ändern.

Wenn Sie Container lieber direkt auf dem VPS ausführen und eine Ebene überspringen möchten, beschreibt Docker auf einem VPS ausführen diese Konfiguration separat.

Fehlerbilder und die angezeigten Meldungen

Nach der Installation von Docker auf dem Host verlieren Instanzen ihre gesamte Netzwerkverbindung. Die Incus-Dokumentation nennt die Ursache: „Docker setzt die globale FORWARD-Richtlinie auf drop. Dadurch kann Incus keinen Datenverkehr weiterleiten, und die Instanzen verlieren ihre Netzwerkverbindung.“ Die Instanzen behalten ihre Adressen, erreichen aber kein Ziel. Setzen Sie ip-forward-no-drop in /etc/docker/daemon.json auf true. Machen Sie die Weiterleitung anschließend dauerhaft und lassen Sie die Bridge durch die eigene Docker-Kette passieren.

echo "net.ipv4.conf.all.forwarding=1" | sudo tee /etc/sysctl.d/99-forwarding.conf
sudo systemctl restart systemd-sysctl
sudo iptables -I DOCKER-USER -i incusbr0 -j ACCEPT
sudo iptables -I DOCKER-USER -o incusbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Diese iptables-Regeln bleiben nach einem Reboot nicht automatisch erhalten. Speichern Sie sie dauerhaft.

Container starten mit einem cgroup-Fehler nicht mehr. Die Incus-FAQ beschreibt diesen Fall. Eine Meldung über Failed to mount "/sys/fs/cgroup" bedeutet normalerweise, dass ein VPN-Client auf dem Host den net_cls-Controller von cgroup v1 über cgroup v2 eingehängt hat, das Incus verwendet. sudo umount /sys/fs/cgroup/net_cls behebt das Problem.

Eine Instanz erhält keine IPv4-Adresse. incus list zeigt, dass sie ausgeführt wird, die Adressspalte aber leer ist. DHCP-Antworten vom Host werden verworfen. Meist ist eine Host-Firewall die Ursache, die die Bridge nicht kennt. Unter ufw stellt sudo ufw allow in on incusbr0 to any port 67 proto udp die Verbindung wieder her. Mit sudo tcpdump -ni incusbr0 port 67 können Sie prüfen, ob die Anfragen eintreffen.

Eine Instanz startet auf einem verschachtelten VPS nicht. Lesen Sie zuerst incus info <name> --show-log und anschließend sudo journalctl -u incus -n 50. Wenn systemd-detect-virt den Wert lxc oder openvz meldet, liegt die fehlende Funktion auf der Seite des Providers. Keine Einstellung innerhalb Ihres VPS kann das ändern.

Snapshots sind langsam, und der Datenträger läuft ständig voll. Sie verwenden einen dir-Pool. incus storage list gibt den Treiber für jeden Pool aus. Der Wechsel zu einem Copy-on-Write-Pool erfordert, dass Sie den neuen Pool erstellen und die Instanzen mit incus copy web web-new -s fast dorthin kopieren. Löschen Sie die ursprünglichen Instanzen erst, nachdem Sie geprüft haben, dass die Kopien starten.

FAQ

Ist ein Incus-Container dasselbe wie ein Docker-Container?

Nein. Docker bündelt einen einzelnen Prozess oder eine einzelne Anwendung. Ein Incus-Systemcontainer bildet ein vollständiges Betriebssystem nach, mit eigener init, eigenen Benutzern, eigenen Diensten und eigenem Paketmanager. Einen Incus-Container halten und aktualisieren Sie wie einen Server. Einen Docker-Container verwerfen Sie und erstellen ihn aus einem Image neu. Sie können Docker in einem Incus-Container ausführen, indem Sie security.nesting=true für den Container setzen. Umgekehrt funktioniert das nicht.

Kann ich Incus auf einem VPS ausführen?

Auf einem KVM-VPS ja. systemd-detect-virt gibt kvm oder qemu aus. Sie haben einen eigenen Kernel, und Incus verhält sich wie auf echter Hardware. Gibt der Befehl lxc, lxc-libvirt oder openvz aus, ist Ihr VPS selbst ein Container. Incus-Container darin sind daher verschachtelt und funktionieren nur, wenn der Anbieter Nesting für Ihren Container aktiviert hat. Prüfen Sie außerdem uname -r. Seit August 2026 dokumentiert der aktuelle stabile Incus-Zweig einen Mindestkernel von 6.12, während für den 6.0-LTS-Zweig 5.4 dokumentiert ist.

Welches Storage-Backend sollte ich für Incus auf einem VPS wählen?

btrfs mit einer Loop-Datei, sofern Sie kein ungenutztes Blockgerät dafür haben. Der dir-Treiber ist laut Dokumentation deutlich langsamer als die anderen Treiber, weil er Dateien kopiert, statt Copy-on-Write zu verwenden. Daher schreibt jeder Snapshot den gesamten Container erneut. incus admin init --minimal wählt dir aus. Deshalb lohnt es sich, die interaktiven Fragen zwei Minuten lang zu beantworten. Erstellen Sie den Pool mit incus storage create fast btrfs size=30GiB.

Warum kann mein Incus-Container einen Dienst erreichen, der auf dem Host läuft?

Die standardmäßige incusbr0-Bridge platziert den Host an der Gateway-Adresse im selben Subnetz wie der Container. Zwischen beiden findet keine Filterung statt. Jeder Host-Dienst, der an 0.0.0.0 gebunden ist, antwortet dort. Die Firewall Ihres Anbieters sieht diese Pakete nicht, weil sie die Maschine nicht verlassen. Binden Sie Host-Dienste an 127.0.0.1. Erlauben Sie auf einem Host mit ufw über incusbr0 nur DNS und DHCP, statt pauschal sudo ufw allow in on incusbr0 freizugeben.

Wie sichere ich einen Incus-Container?

incus export web /root/web-backup.tar.gz schreibt die Instanz und ihre Snapshots in eine Datei. incus import stellt sie auf demselben oder einem anderen Server wieder her. Snapshots, die mit incus snapshot create erstellt wurden, sind keine Backups. Sie liegen im selben Storage-Pool auf derselben Festplatte. Daher überstehen sie ein fehlerhaftes Upgrade, aber keinen Ausfall des Servers. Planen Sie sie mit incus config set web snapshots.schedule=@daily, und kopieren Sie die Exporte vom Server weg.