Incus

Systemcontainer verwenden den Linux-Kernel des Hosts und besitzen einen eigenen Benutzerraum. Dadurch entfällt ein eigener Gastkernel. Eine virtuelle Maschine nutzt dagegen virtualisierte Hardware und einen eigenen Kernel. Die Wahl beeinflusst Betriebssystemfreiheit, Ressourcenbedarf und die Sicherheitsgrenze.

Aktuelle Incus-Versionen können auch OCI-Anwendungsimages verwenden. Das macht Incus nicht automatisch zu einer Kubernetes-Plattform oder zu einem unveränderten Ersatz vorhandener Docker-Compose-Abläufe. Netzwerke, persistente Daten und der Startprozess müssen zum gewählten Betriebsmodell passen.

Profile fassen wiederverwendbare Konfiguration und Gerätezuordnungen zusammen. Projekte dienen zur Gliederung und können Ressourcen sowie Berechtigungen begrenzen. Dadurch lassen sich beispielsweise Entwicklung und Betrieb organisatorisch trennen, ohne für jede Instanz dieselben Einstellungen einzeln einzutragen.

Eine Änderung an einem gemeinsam genutzten Profil kann viele Instanzen betreffen. Profile daher wie Infrastrukturcode behandeln: Änderung prüfen, betroffene Instanzen bestimmen und einen Rückweg festlegen. Ein sprechender Name allein ist noch keine technische Begrenzung eines Projekts.

Die REST-API ermöglicht automatisierte Abläufe. Zugriff auf die Verwaltungs-API ist entsprechend mächtig. Persönliche Administration, Automationskonten und reine Beobachtung sollten unterschiedliche Rechte bekommen.

Incus unterstützt mehrere Storage-Treiber, darunter lokale Verzeichnisse, ZFS, LVM und Ceph-basierte Speicher. Ihre Eigenschaften unterscheiden sich bei Snapshots, Kopien, Migration und gemeinsamem Zugriff. Deshalb den Treiber anhand der benötigten Betriebsabläufe auswählen, nicht nur anhand einer erfolgreichen Erstinstallation.

Für Netzwerke stehen lokale und verteilte Varianten zur Verfügung, etwa verwaltete Bridges und OVN. IP-Adressierung, IPv6, DNS und Anbindung an bestehende VLANs müssen zum Standort passen. Ein virtuelles Netzwerk ersetzt keine Prüfung der Erreichbarkeit und Segmentierung im physischen Netz.

Für eine Anwendung mit mehreren Datenträgern zusätzlich festhalten, welche Volumes gemeinsam gesichert und wiederhergestellt werden müssen. Ein Snapshot der Systemdisk reicht nicht, wenn Datenbank oder Uploads auf separat eingebundenen Volumes liegen.

Im Cluster teilen sich die Mitglieder eine verteilte Konfigurationsdatenbank. Die Dokumentation empfiehlt mindestens drei Mitglieder für eine belastbare Quorumsituation. Diese Replikation betrifft den Verwaltungszustand und ist nicht gleichbedeutend mit einer Kopie jedes virtuellen Datenträgers auf jedem Host.

Soll eine Instanz nach einem Hostausfall anderswo starten, müssen ihre Daten erreichbar und die nötigen Geräte sowie Netze vorhanden sein. Bei Live-Migration kommen unter anderem CPU-Kompatibilität und Migrationsunterstützung des jeweiligen Instanztyps hinzu. Lokal durchgereichte Hardware kann diese Möglichkeiten einschränken.

Incus bietet Evakuierungs- und Wiederanlauffunktionen, die passend konfiguriert werden müssen. Vor einem automatischen Neustart auf einem anderen Host ist sicherzustellen, dass die alte Instanz nicht weiter aktiv ist. Sonst drohen konkurrierende Zugriffe auf denselben Datenbestand. Verfügbarkeitszusagen sollten deshalb aus getesteten Ausfällen entstehen.

Unprivilegierte Container sind die Ausgangsbasis. Privilegierter Betrieb, zusätzliche Gerätefreigaben und weitreichende Host-Verzeichnisse verändern die Isolation. Ein Fehler in einer Anwendung sollte nicht ohne Ursachenprüfung durch immer mehr Rechte umgangen werden.

Für verschachtelte Laufzeiten oder besondere Kernelanforderungen gezielt prüfen, welche Optionen tatsächlich nötig sind. Gegebenenfalls ist eine virtuelle Maschine die passendere Grenze. Den Verwaltungszugriff auf den Host und auf Incus separat von den Benutzerrechten innerhalb der Instanz behandeln.

Images, Cloud-init-Daten und Automationsskripte gehören ebenfalls zur Vertrauensprüfung. Vorgefertigte Images erleichtern den Start, ersetzen aber keine Updates und keine Kontrolle darüber, welche Benutzer und Schlüssel beim ersten Boot angelegt werden.

Incus 7.0 LTS wurde am 5. Mai 2026 veröffentlicht. Das Projekt nennt Unterstützung bis Juni 2031. Nach den ersten zwei Jahren mit Fehler- und Sicherheitskorrekturen folgt eine Phase mit Sicherheitswartung. Die Paketversorgung der gewählten Distribution beziehungsweise des Paketlieferanten muss dazu passen.

Für bestehende LXD-Installationen gibt es das Werkzeug lxd-to-incus. Der unterstützte Versionsbereich ist begrenzt und kann sich ändern. Vor einer Umstellung Ausgangsversion, verwendete Funktionen, Images und Speicher prüfen. Die Existenz eines Migrationswerkzeugs belegt keine Unterstützung beliebiger neuer LXD-Stände.

Instanzsicherungen und Server-Wiederherstellung getrennt planen. Ein Restore-Test sollte Konfiguration, zusätzliche Volumes und die erreichbaren Dienste umfassen. Snapshots auf demselben ausgefallenen Speicher sind kein unabhängiger Wiederherstellungsweg.

Geprüft am 20. September 2026. LTS-Angaben stammen aus der datierten Veröffentlichung von Incus 7.0, nicht aus teilweise älteren Übersichtsseiten. Details einzelner Treiber anhand der eingesetzten Paketversion prüfen.