Skip to content

iSCSI & Stratis

Applies to CentOS Stream 9 & 10 / AlmaLinux 9.x & 10.x / Rocky Linux 9.x & 10.x

This page covers two block storage solutions commonly used on enterprise Linux. iSCSI lets you share a disk on one server over the network to another server, which mounts it and uses it just like a local disk. Stratis is the local storage management tool provided by RHEL, layering pooling, thin provisioning, and snapshots on top of XFS and device-mapper, which is simpler to use than traditional LVM plus a filesystem.

  • The roles of the iSCSI target and initiator
  • How to build an iSCSI target with targetcli and persist the configuration
  • How to discover and log in to a remote block device from the initiator, and enable automatic login at boot
  • How to create storage pools, filesystems, and snapshots with Stratis
  • How to make a Stratis filesystem mount reliably at boot
  • Two systems running EL 9.x or EL 10.x (the iSCSI part needs one target host and one initiator host)
  • sudo privileges
  • A spare disk or partition on the target (such as /dev/sdb)
  • Network connectivity between the two hosts

iSCSI (Internet SCSI) transports SCSI commands over an ordinary TCP/IP network, presenting a remote disk to the client as a block device. It involves two roles:

  • target: the server, which provides block devices. Each target is identified by an IQN (iSCSI Qualified Name).
  • initiator: the client, which connects to a target and mounts the remote block device locally. After login, a new block device (such as /dev/sdb) appears.
iSCSI target (192.168.1.10) iSCSI initiator (192.168.1.20)
/dev/sdb ──> backstore ──> LUN ──network──> /dev/sdb (appears after login)
IQN + ACL partition / format / mount
Install the target tool
$ sudo dnf install targetcli

targetcli is an interactive shell. Once inside, you organize the configuration using filesystem-like paths. The example below uses a spare disk /dev/sdb as the backend storage.

  1. Enter the targetcli interactive shell:

    Start targetcli
    $ sudo targetcli
  2. Create a backstore. You can use a whole device (block) or an ordinary file (fileio):

    targetcli: create a block backstore
    /> backstores/block create disk1 /dev/sdb

    If you have no spare disk, use a file as the backend instead:

    targetcli: create a fileio backstore (optional)
    /> backstores/fileio create disk1 /var/lib/iscsi_disks/disk1.img 5G
  3. Create an iSCSI target, which automatically generates an IQN:

    targetcli: create a target
    /> iscsi/ create iqn.2026-06.com.example:target1
  4. Attach the backstore to the target as a LUN:

    targetcli: create a LUN
    /> iscsi/iqn.2026-06.com.example:target1/tpg1/luns create /backstores/block/disk1

    Match the LUN path to the backstore type you created in the previous step: use /backstores/block/disk1 for a block backstore, or /backstores/fileio/disk1 for a fileio backstore.

  5. Configure an ACL so that only the specified initiator IQN may connect. The initiator’s IQN comes from its /etc/iscsi/initiatorname.iscsi:

    targetcli: create an ACL
    /> iscsi/iqn.2026-06.com.example:target1/tpg1/acls create iqn.2026-06.com.example:client1
  6. Exit. On exit, the configuration is saved automatically to /etc/target/saveconfig.json:

    targetcli: exit and save
    /> exit

The target service loads the configuration from /etc/target/saveconfig.json at boot. Be sure to enable it, otherwise all your configuration is lost after a reboot:

Enable and start the target service
$ sudo systemctl enable --now target

iSCSI uses 3260/tcp, which must be allowed on the target:

Allow the iSCSI port
$ sudo firewall-cmd --permanent --add-port=3260/tcp
$ sudo firewall-cmd --reload

Stratis is the local storage management solution provided by RHEL and compatible distributions. Under the hood it uses XFS and device-mapper to handle the tedious configuration automatically, while exposing a simple command line that lets you manage pools, filesystems, and snapshots as objects, with thin provisioning built in.

It has two parts: the background service stratisd does the actual storage management, while the command-line tool stratis (from stratis-cli) takes your commands.

Install Stratis
$ sudo dnf install stratisd stratis-cli
Enable and start stratisd
$ sudo systemctl enable --now stratisd
  1. Create a storage pool named pool1 from a spare disk:

    Create a pool
    $ sudo stratis pool create pool1 /dev/sdb
  2. Create a filesystem named data1 in the pool:

    Create a filesystem
    $ sudo stratis filesystem create pool1 data1
  3. The filesystem’s device path is /dev/stratis/<pool>/<filesystem>. List them to confirm:

    List pools and filesystems
    $ stratis pool list
    $ stratis filesystem list

You can mount it temporarily first to test:

Temporary mount
$ sudo mkdir -p /mnt/data
$ sudo mount /dev/stratis/pool1/data1 /mnt/data

For auto-mount at boot, you must use the UUID and add the systemd dependency. First find the filesystem’s UUID:

Find the filesystem UUID
$ sudo lsblk --output=UUID /dev/stratis/pool1/data1

Then add this to /etc/fstab (note x-systemd.requires=stratisd.service):

/etc/fstab
UUID=<the UUID from the previous step> /mnt/data xfs defaults,x-systemd.requires=stratisd.service 0 0

Verify the fstab entry is correct (so you catch errors without rebooting):

Verify fstab
$ sudo umount /mnt/data
$ sudo systemctl daemon-reload
$ sudo mount -a
$ df -hT /mnt/data

Stratis snapshots are based on thin provisioning, so they are fast to create and take almost no space initially:

Create a snapshot
$ sudo stratis filesystem snapshot pool1 data1 data1-snap

A snapshot is itself an independent filesystem that you can mount separately to recover data:

Mount the snapshot to inspect data
$ sudo mkdir -p /mnt/snap
$ sudo mount /dev/stratis/pool1/data1-snap /mnt/snap

When the pool runs low on space, add another disk to it with no data migration required:

Add a disk to the pool
$ sudo stratis pool add-data pool1 /dev/sdc

targetcli configuration is lost after a reboot

Section titled “targetcli configuration is lost after a reboot”

The most common causes are not saving the configuration when exiting targetcli, or not enabling the target service. Confirm two things: that you ran saveconfig inside targetcli (or exited normally with exit), and that sudo systemctl enable --now target is in place.

Save the current configuration manually
$ sudo targetcli saveconfig

Troubleshoot in order:

  • Whether the IQN in the initiator’s /etc/iscsi/initiatorname.iscsi matches the IQN configured in the target’s ACL exactly (spelling and case must match).
  • Whether the target’s firewall allows 3260/tcp.
  • Whether the network is reachable (ping the target IP) and whether iscsiadm -m discovery returns the target list.

Almost always the fstab entry is missing x-systemd.requires=stratisd.service. Add this option so the mount waits until stratisd is ready. Also confirm you are using the UUID rather than the /dev/stratis/... path.

Can I use fdisk/LVM directly on disks in a Stratis pool

Section titled “Can I use fdisk/LVM directly on disks in a Stratis pool”

No. The physical devices in a pool are managed exclusively by Stratis, and all operations must go through the stratis command. Using other tools directly will corrupt the metadata.