Storage Problems in OS Reboots

Managing Loop Devices and Storage Pools Across Reboots

This document provides a clean and structured explanation of how loop devices behave across reboots, why storage pools become unavailable in the webUI, and how to make them available again.

1. How Loop Devices Delete Across Reboot

Overview Loop devices are virtual block devices that allow files (e.g., disk images) to be mounted as if they were physical block devices. These devices are ephemeral by nature, meaning they do not persist across system reboots unless explicitly configured to do so.

Behavior Across Reboot

  • When the system reboots:
    • The kernel clears all loop device mappings.
    • Any file or image associated with a loop device is unmounted.
    • The loop devices (/dev/loopX) are removed and must be recreated manually or through automation after the reboot.

Impact

  • If a storage pool relies on a loop device, the pool will become unavailable after a reboot because the loop device association is lost.

2. Storage Pool Becomes Unavailable in WebUI

Why Does This Happen?

  • A storage pool may use a loop device as its source (e.g., /dev/loop8).
  • After a reboot:
    • The loop device is no longer mapped to the underlying file or image.
    • The storage pool cannot locate its source device.
  • As a result, the storage pool appears as “unavailable” or “inactive” in the webUI.

3. How to Make the Storage Pool Available

Steps to Restore Functionality

To make the storage pool available after a reboot, follow these steps:

Step 1: Recreate the Loop Device
  • Use the losetup command to recreate the loop device association. For example: 
    sudo losetup /dev/loop8 /data/lxc/porter-in-demo1a-node01.img
sudo losetup /dev/loop9 /data3/lxc/pssb1avd003.img
  • Verify the loop devices are created: 
    losetup -a
Step 2: Edit the Storage Pool in the WebUI
  • Log in to the webUI and navigate to the storage pool settings.
  • Edit the storage pool configuration:
    • Locate the “Source” field.
    • Update it to point to the newly created loop device (e.g., /dev/loop8 or /dev/loop9).
  • Save the changes.
Step 3: Activate the Storage Pool
  • Once the source is updated, activate the storage pool from the webUI.
  • Verify that the pool is now available and functioning correctly.

4. Automating Loop Device Creation for Persistence

To avoid manually recreating loop devices after every reboot, you can automate the process:

Using /etc/rc.local

  1. Add the losetup commands to /etc/rc.local:

    sudo nano /etc/rc.local

    Add the following content:

    #!/bin/bash
# Recreate loop devices for storage pools

# Detach existing loop devices if they are already in use
/usr/sbin/losetup -d /dev/loop8 2>/dev/null || true
/usr/sbin/losetup -d /dev/loop9 2>/dev/null || true

# Attach loop devices to their respective files
/usr/sbin/losetup /dev/loop8 /data/lxc/porter-in-demo1a-node01.img
/usr/sbin/losetup /dev/loop9 /data3/lxc/pssb1avd003.img

exit 0

  2. Make /etc/rc.local executable:

    sudo chmod +x /etc/rc.local

  3. Enable the rc-local service:

    sudo systemctl enable rc-local
sudo systemctl start rc-local

  4. Reboot and verify:

    sudo reboot
losetup -a

Conclusion

  • Loop Device Behavior: Loop devices are deleted across reboots because they are ephemeral.
  • Storage Pool Impact: This causes storage pools relying on loop devices to become unavailable in the webUI.
  • Solution:
    • Recreate the loop devices using losetup.
    • Update the storage pool source in the webUI to reflect the new loop device.
    • Optionally, automate the loop device creation process using /etc/rc.local or a custom script.

By following these steps, you can ensure that your storage pools remain functional and accessible after every system reboot.