Data, paths and networking

OCI manager Apps~8 min

What lives in the rootfs, what survives its replacement, how data is shared between containers and how each container gets its address.

Persistence is decided before the LXC exists

The volumes published by the image and by its Compose file are read before the container is created. Every path that has to survive an update becomes a mount point independent of the rootfs, so the rootfs only holds what belongs to the image and can be replaced.

What the installer asks

The template supplies the paths the application needs. Each one is placed on a container disk or on a host directory, and more paths can be added before the summary.

  1. 1

    Required paths

    /config, /data, libraries, downloads and every volume the application declares are listed.

  2. 2

    Location

    Each path is placed on a disk of the container or on an existing host directory.

  3. 3

    Storage and size

    A container disk is created on a Proxmox VE storage with the size given. The default installation asks once for the storage of the container and its data when the node has more than one; the advanced installation asks the storage of each path right before its size and proposes the one of the rootfs. It appears as vm-VMID-disk-N and is attached as mpN.

  4. 4

    Host directory

    A host directory is given by its path. A directory that does not exist is created, owned by the user the container maps.

  5. 5

    Additional paths

    More pairs of host path or volume and container path can be added before installing.

  6. 6

    Summary

    The complete mapping is shown before the CT is created and is stored in its instance contract.

The two persistent locations

PropertyContainer diskHost directory
In the configurationmpN: STORAGE:vm-VMID-disk-N,mp=/config,backup=1,size=16GmpN: /mnt/oci-shared/media,mp=/data/media
Container backup (vzdump)Included, with backup=1Not included
SizeFixed; grown with a resize of the mount pointThe free space of the host filesystem or dataset
Other containersMounted only by its own containerThe same directory can be mounted in several containers
Snapshots and restoreManaged by Proxmox VE together with the CTManaged on the host storage
Removing the applicationDeleted with the containerKept, with its content
Moving the CT to another nodeMoves with the CTThe same path has to exist on the other node

The rootfs is reserved for the binaries and the content of the image. An update or a recreation replaces it without touching either kind of mount point.

A host directory is mounted with everything the host has mounted inside it. A directory such as /mnt/pve shows its network shares, disks and datasets in the container, and what the host mounts or unmounts there later appears or disappears without restarting the container. A directory added as read-only is read-only together with what is mounted inside it when the container starts. A filesystem the host mounts afterwards arrives with the permissions the host mounts it with, and becomes read-only as well when the container is restarted.

Example: a container with both locations

Jellyfin installed as CT 151 on local-lvm (excerpt)
rootfs: local-lvm:vm-151-disk-0,size=8G
# Container disk, part of the CT backup
mp0: local-lvm:vm-151-disk-1,mp=/config,backup=1,size=16G

# Host directory, outside the CT backup
mp1: /mnt/oci-shared/media,mp=/data/media

An update or a recreation replaces only the rootfs: mp0 keeps users, libraries and settings, and mp1 keeps showing the same media. Restoring the CT backup brings back /config; the media directory is restored, if needed, from the backup of the host storage.

Contract
/config
Location
container disk or host directory
LXC
always /config for the application

The application sees the path the image publishes; only where it is stored changes.

One host directory, several containers

Loading diagram…

Each container keeps its configuration on its own disk. The library or the downloads are one host directory mounted at the same internal path in every container, so a path that one application writes is the same path another one reads.

Cloud storage through the Rclone application

The Rclone application of the catalog offers, besides its installation, Enable a mount on an existing Rclone OCI container. It mounts a remote already created and authorised in the Rclone web UI and publishes it on the host, where other containers can use it as a host directory.

  1. 1

    Container and remote

    The VMID of the Rclone container, the exact name of the remote and, optionally, a path inside it.

  2. 2

    Mount name and cache

    The name of the mount and the VFS cache mode: off, minimal, writes or full (default).

  3. 3

    Published views

    A common root, /mnt/oci-shared by default, holds a read/write view in /mnt/oci-shared/remotes/NAME and a read-only view in /mnt/oci-shared/remotes-ro/NAME.

  4. 4

    Activation

    After a confirmation, the CT is stopped, its start command and a Proxmox VE hookscript are set, and it is started again. The operation waits until both views are mounted on the host.

If the mount does not come up

The previous configuration of the container is restored and it is started again, so a failed activation leaves Rclone as it was.

Addresses and networks

A single application needs an address. A multi-container application also needs a stable network between its members.

Single application

Bridge and DHCP or a fixed CIDR address are chosen. The LXC has an address of its own and the summary shows the complete URLs of the services.

Multi-container application

A free subnet is found, a persistent private bridge is created and each member (application, database, cache) gets a fixed address on it.

LAN
reachable address main service only
Main LXC
web / API LAN + private network
Private network
PostgreSQL · Valkey · ML fixed addresses

Dependencies talk over the private network and have no address on the LAN.

The stack contract stores bridge, subnet, addresses and the relations between services. Updating the application reuses the same topology for every member. ProxMenux Monitor opens the main container at its LAN address, not at its address on the private network.

Ownership

  • New directories are created with the UID and GID the unprivileged LXC maps.
  • Existing directories are not re-owned recursively.
  • Sockets, system files and sensitive paths are not offered as generic host directories.

What a container backup contains

ElementIn the CT vzdumpWhere it is kept
OCI rootfsYesThe CT backup; it can also be rebuilt from the image and the contract
Container disk with backup=1YesThe CT backup
Host directoryNoThe backup of the host storage
Instance contractYes, the copy carried inside the CT/.proxmenux/oci-record.json inside the CT; additional host and cluster copies are kept separately
Multi-container applicationEach member in its own backupThe backups of every member, plus the stack contract and its bridge on the host