Cinder LVM volumes are unavailable after system restart

Restarting the system causes volumes associated with cinder's LVM backend to become unusable. Two symptoms are observed:

1. The systemd service that initializes the loopback devices used by the LVM backend may fail

This can happen if the cinder-lvm-losetup systemd service starts before the local /var filesystem is mounted.

[stack@undercloud ~]$ sudo systemctl status cinder-lvm-losetup
● cinder-lvm-losetup.service - Cinder LVM losetup
   Loaded: loaded (/etc/systemd/system/cinder-lvm-losetup.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2020-11-18 07:44:55 UTC; 1min 31s ago
 Main PID: 1264 (code=exited, status=1/FAILURE)

Nov 18 07:44:55 osp16.elconaslab.de systemd[1]: Starting Cinder LVM losetup...
Nov 18 07:44:55 osp16.elconaslab.de losetup[1264]: losetup: /var/lib/cinder/cinder-volumes: failed to set up loop device: No such file or directory
Nov 18 07:44:55 osp16.elconaslab.de systemd[1]: cinder-lvm-losetup.service: Main process exited, code=exited, status=1/FAILURE
Nov 18 07:44:55 osp16.elconaslab.de systemd[1]: cinder-lvm-losetup.service: Failed with result 'exit-code'.
Nov 18 07:44:55 osp16.elconaslab.de systemd[1]: Failed to start Cinder LVM losetup.

2. The /etc/target directory (used by both the cinder-volume and iscsid tripleo services) isn't persistent

The LIO SCSI target stores and retrieves target data in that directory, and that data is lost because the contents generated from the services running in containers isn't mapped to a persistent directory on the host. This prevents VMs that boot from a volume from restarting after the entire system restarts.