Understanding mgr-storage-server and mgr-storage-proxy

mgr-storage-server and mgr-storage-proxy are helper scripts provided with Uyuni.

They are designed to configure storage for Uyuni Server and Proxy.

The scripts take disk devices as arguments. mgr-storage-proxy requires a single argument for the storage disk device. mgr-storage-server requires a storage disk device and can optionally accept a second argument for a dedicated database disk device. While both normal and database storage can reside on the same disk, it is advisable to place the database on a dedicated, high-performance disk to ensure better performance and easier management.

1. What these tools do

Both mgr-storage-server and mgr-storage-proxy perform standard storage setup operations:

  • Validate the provided storage devices.

  • Ensure that devices are empty and suitable for use.

  • Create XFS filesystems on the specified devices.

  • Mount the devices temporarily for data migration.

  • Move the relevant storage directories to the new devices.

  • Create entries in /etc/fstab so that the storage mounts automatically on boot.

  • Remount the devices at their final locations.

Table 1. Additional tool-specific behavior

mgr-storage-server

  • Optionally supports a separate device for database storage.

  • Stops SUSE Manager services during migration, restarts them afterward.

  • Moves Podman volumes directory /var/lib/containers/storage/volumes to the prepared storage, and optionally /var/lib/containers/storage/volumes/var-pgsql to the prepared database storage.

mgr-storage-proxy

  • Focuses only on proxy storage (no database storage support).

  • Stops and restarts the proxy service during migration.

  • Moves podman volumes directory /var/lib/containers/storage/volumes to the prepared storage.

Both tools automate standard Linux storage operations. There is no hidden or custom logic beyond what a Linux administrator would do manually.

2. What these tools do not do

  • They do not create or manage LVM volumes.

  • They do not configure RAID or complex storage topologies.

  • They do not prevent you from managing storage using normal Linux tools after setup.

  • They do not provide dynamic resizing or expansion capabilities — these must be handled using standard Linux storage tools.

3. Post-installation storage management

Once storage has been configured, you can safely manage it using standard Linux commands.

3.1. Examples

Listing 1. Example 1: Extending storage if using LVM
lvextend -L +10G /dev/your_vg/your_lv
xfs_growfs /var/lib/containers/storage/volumes
Example 2: Migrating to a larger disk

  1. Add and format the new disk.

  2. Mount it temporarily.

  3. Use rsync to copy data.

  4. Update /etc/fstab.

  5. Remount at the correct location.

4. When to use, or not use

Always take a backup before making changes to your storage setup.

  • Use these tools only during initial storage setup or when migrating to new storage where the tool is expected to handle data migration and update /etc/fstab.

  • Do not rerun these scripts for resizing or expanding storage. Use standard Linux tools (e.g., lvextend, xfs_growfs) for such operations.

5. Summary

mgr-storage-server and mgr-storage-proxy help automate the initial persistent storage setup for Uyuni components using standard Linux storage practices. They do not limit or interfere with standard storage management afterward.

After setup, continue managing your storage using familiar Linux tools.

A full database volume can cause significant issues with system operation. As disk usage notifications have not yet been adapted for containerized environments, users are encouraged to monitor the disk space used by Podman volumes themselves, either through tools such as Grafana, Prometheus, or any other preferred method. Pay particular attention to the var-pgsql volume, located under /var/lib/containers/storage/volumes/.