Incus jongliert Container und virtuelle Maschinen. Die neue Version kann einen Sub-Pfad eines Volumes als Disk verwenden und isolierte OVN-Netzwerke erzeugen. Der verfügbare Speicher für ein Projekt lässt sich zudem für jeden Storage Pool separat setzen.
In Incus 6.4 folgen die Befehle zur Steuerung von Cluster Groups dem Standard-Schema. Beispielsweise liefert „incus cluster group show mygroup“ Konfigurationsinformationen zur Cluster Group „mygroup“.
Des Weiteren lässt sich die VM CPU Baseline auf Cluster-Group-Basis einstellen. Als Beispiel nennt die offizielle Ankündigung den Befehl:
incus cluster group set foo instances.vm.cpu.x86_64.baseline=kvm64 instances.vm.cpu.x86_64.flags=auto
Er geht automatisch durch die Server in der Cluster Group „foo“ und bestückt die Einstellung „flags“ mit den typischen CPU Flags.
Unabhängig von den Cluster Groups kann man in Incus 6.4 jetzt ein Unterverzeichnis in einem Volume in einen anderen Container einhängen.
Bereits in den Vorversionen konnte man Projects den Zugriff auf Ressourcen einschränkten. Den Zugriff auf Datenträger konnte man dabei nur generell für alle Storage Pools reglementieren. Dieses Limit hebt Incus 6.4 auf: Ab sofort lässt sich der Zugriff auf jeden Storage Pool einzeln limitieren. Die Einschränkungen steuert die neue Einstellung „limits.disk.pool.POOLNAME“. Setzt man sie auf „0“, verschwindet der Storage Pool sogar aus der Liste der verfügbaren Pools.
Bei OVN-Netzwerken konfiguriert man über das „network“-Property das Uplink-Netzwerk. Dabei handelt es sich um das Netzwerk, über das alle Pakete zu und von der Außenwelt in das OVN-Netzwerk fließen. Mit dem neuen Wert „none“ erstellt Incus ein isoliertes OVN-Netzwerk, das keine Verbindung zur Außenwelt mehr hat.
Über die Einstellung „instances.lxcfs.per_instance“ kann man jedem Container eine eigene dedizierte LXCFS-Instanz spendieren. Abschließend lassen sich Umgebungsvariablen für OCI-Container in einer (Text-)Datei verstauen.
