Your cloud

Storage node

Learn what OpenStack storage means, what the current Saphira role prepares, what has now been published, and why the unproved deployment path must not yet be presented as a production-ready volume service.

The storage model: similar words, different jobs

Thing	What it is	What survives
Local compute storage	Disk space physically attached to the compute host, used by the hypervisor for guest data.	It belongs to that host. A host failure or instance deletion can make it unavailable or remove ephemeral data.
Ephemeral instance disk	The root or local disk created for an instance by the compute path.	Treat it as disposable unless the image/application and your backup process say otherwise. Rebuild and delete can destroy it.
Image	A reusable boot template held by Glance.	It is a source for new guests, not a backup of changes made inside a running guest.
Cinder volume	A persistent block device that an instance may attach and format as it chooses.	Designed to outlive an instance, subject to the storage backend and an actual backup/recovery design.
Snapshot / backup	A point-in-time copy or a separately retained copy of data.	Neither is automatic. A snapshot is not necessarily an independent, off-host backup.
Shared storage	Storage reachable by more than one compute host, often through a storage protocol or filesystem.	It can support designs that local disks cannot, but needs its own failure, access-control and recovery plan.

Cinder is OpenStack’s block-storage service. It records volumes and asks a backend driver to create and export them. In the current Saphira role, LVM is the backend allocator and iSCSI is the intended export protocol. LVM turns a dedicated disk or set of disks into a volume group; Cinder can allocate logical volumes from that group. iSCSI is the network target layer that makes those logical volumes appear as block devices to compute hosts. The required Saphira packages now exist; proving the whole deployed path is the remaining work.

Current implementation status: close, but not yet an operational volume service

Do not call this role production ready

Cinder 29 and the LVM host-side path are published. The target chain that used to be missing—tgt for tgtd/tgtadm, open-iscsi, open-isns and libiscsi—is now live in Hatched. That establishes package availability, not a successful Cinder service: no Saphira deployment has yet created, attached, read back and deleted a volume.

The current role prepares an LVM volume group, Cinder identity, endpoints and cinder.conf. The controller still needs the Cinder database and grants; controller setup does not create them. The published role starts cinder-volume only when tgtadm is installed. No page should invent the unproved database setup or claim that the service starting proves a volume can attach.

The next proof is deliberately narrow and safe: deploy on Minimer, use a loopback LVM volume group, create and attach a test volume, write and read data, then delete it. A separate ZFS proof uses a loop-file pool. The existing tank and /dev/vdb stay untouched. Until those records exist, use compute-local storage for real work and keep guest data backed up by a method you have tested.

Before touching a disk

The storage setup runs pvcreate and vgcreate. Those are storage-initialisation commands, not inspection commands. A wrong disk choice can overwrite a partition table or make existing data inaccessible. Never infer that a disk is spare from its name alone.

# Read-only inspection. Compare these results with the machine’s physical inventory.
lsblk -d -o NAME,SIZE,TYPE
lsblk -f
mount
fdisk -l /dev/CHOSEN_DISK

Identify the disk by its size, physical connection and absence from the operating-system, boot, data and backup layouts. Stop if the identity is uncertain. Back up anything of value before any destructive command. The script itself lists candidate disks, verifies that the answer is a block device, warns when it finds mounts or a partition table, and requires uppercase YES to proceed. A warning is not evidence that it is safe.

Do not share the future Cinder volume group with ordinary filesystems or another workload. Cinder assumes it owns the volume group. Do not use an OS disk, EFI disk, mounted disk, or a disk that you intend to “borrow temporarily.”

Install and run the preparation role

# Run as root. Package installation does not initialise a disk or start Cinder configuration.
apk add saphira-openstack-storage

# This is the destructive preparation step. Read the previous section first.
saphira-openstack-setup-storage

The package installs the Cinder and LVM closure plus the setup script. It does not configure storage merely because it has been installed. The script preserves an existing volume group and its configuration unless --force is given; do not use --force to bypass uncertainty about a disk.

The six storage questions

Prompt	Purpose	How to answer
controller IP address	Reach Keystone, RabbitMQ, memcached and the controller database.	Use the stable address from controller setup.
controller admin password	Obtains a one-time Keystone administrator token to register Cinder.	Use the controller administrator secret; it is not the Cinder service credential.
service users password	Configures the Cinder service user.	Use the controller’s service password.
database password	Builds Cinder’s controller-database connection URI.	Use the controller database password; the required Cinder database/grants remain an explicit outstanding controller task.
volume group name	Names the LVM pool from which the driver would allocate volumes.	The default is `cinder-volumes`. Keep it dedicated to Cinder.
disk to devote to volumes	Selects the block device for `pvcreate` and `vgcreate`.	Enter only the positively identified empty disk path, for example `/dev/sdb`. Do not guess.

What the script does, and the exact remaining gate

It makes or retains the selected LVM volume group. A successful new preparation reports that the named volume group is ready on the chosen disk.
It authenticates to Keystone on the controller, creates or retains the cinder service user, grants it admin and service roles in the service project, and creates the volumev3 service/endpoints when absent.
It writes /etc/cinder/cinder.conf for the controller’s RabbitMQ, database, Keystone and memcached services, with the LVM driver, chosen volume group, iSCSI protocol and tgtadm helper.
It prints the requirement for a cinder database and controller grants. This is not created by the controller role and there is no verified Saphira command on this page to invent it.
It checks for tgtadm. If it is absent, it prints STOPPING HERE, HONESTLY: the target daemon is not installed, so the host cannot export volumes. That remains the correct diagnostic for an unprepared host. Thetgt package is now available in Hatched, but installing a dependency does not replace the required Cinder database and end-to-end attach proof.

The target package is now published. The remaining work is deployment and proof: create the Cinder database/grants, run Cinder against a disposable loopback LVM group, then create a volume, attach it to a test instance, format it, write and read data, and delete it. Rerun the Saphira role rather than rewriting its generated state by hand. Only that complete lifecycle makes the role operational.

Check, recover and protect data

# Read-only status report from the Saphira role.
saphira-openstack-setup-storage --check

# Inspect the dedicated LVM pool without changing it.
vgs cinder-volumes
lvs cinder-volumes

The role check reports whether the volume group exists, whether tgtadm is present and whether cinder-volume is active. On a host where tgt has not been installed it should still report the target as missing. Once the service is active, verify the actual create/attach/read-back/delete path; active is necessary, not sufficient.

If disk preparation was interrupted, first establish exactly whether the intended volume group exists with vgs. Do not run pvcreate again on a disk that might already belong to LVM. Recover from a tested backup or seek storage expertise when the device identity or LVM metadata is unclear.

Adding a disk, extending a volume group, snapshots and backups are storage operations with failure modes beyond this incomplete role. Plan redundant copies, restoration tests, monitoring and capacity alerts before placing valuable data there. No Saphira Cinder backup, snapshot or expansion workflow has been verified by the current package implementation.

NFS and ZFS are architectures, not hidden Cinder features

Upstream OpenStack can use other backends, including NFS-based and ZFS-based designs, depending on drivers, network layout and operational requirements. They can address different needs such as shared filesystems, snapshots or replication, but they are not configured by the current Saphira storage script. ZFS userspace and matching module packages for the published 7.1.5, 7.2.2 and 7.2.3 kernel lines are available; that proves the ZFS packages, not a Cinder ZFS backend.

Do not substitute an upstream architecture document for a supported Saphira procedure. A backend needs a tested driver, authentication, network path, recovery design and attach workflow before it becomes a service promise. Keep this role’s LVM/iSCSI status separate from those possible designs. The planned ZFS proof is a disposable loop-file pool, not an experiment on the existing tank.

Return to the cloud architecture for the role of volumes, or use the pitfalls book when storage integration blocks a deployment.