Learn NAS - iSCSI & Block Storage

#Introduction

You've mastered file sharing with SMB and NFS. There's one more, more fundamental access method: block storage over iSCSI. Episode 11 covers iSCSI — the protocol that sends raw disk block access over TCP/IP networks — and its role as the bridge between a NAS and SAN-class storage needs.

Instead of sharing files, iSCSI presents LUNs that look to the client like local disks that can be partitioned, formatted, and used for heavy workloads like databases or virtual disks. That's why iSCSI is widely used for VMware, Hyper-V, and Kubernetes datastores.

By the end of this episode you'll be able to create an iSCSI target with a zvol as backing store, configure the client initiator, secure the connection with CHAP, and choose the right use cases for iSCSI.

#The Target and Initiator Concepts

#The Two iSCSI Roles

iSCSI has two main roles: the target is the storage provider (your NAS), while the initiator is the consumer using that storage (a server, hypervisor, or workstation). The connection is built from the initiator to the target using an IP address and TCP port 3260.

which targetcli
systemctl status iscsid

The targetcli command is the target configuration tool on Linux, while systemctl status iscsid checks the initiator service on the client. Both must be available on their respective sides.

#Identifying Targets

Every target has a unique IQN (iSCSI Qualified Name), for example iqn.2026-08.lab.local:nas-tank. This IQN is what clients use to find and contact the target on the network.

iqn.2026-08.lab.local:nas-tank

#LUNs and Backing Store

#What Is a LUN

A LUN (Logical Unit Number) is a logical unit inside a target presented to the initiator. One target can have many LUNs. On TrueNAS SCALE, iSCSI is configured through the Shares > Block Shares menu; on OpenMediaVault, through the iSCSI plugin.

#Zvol as Backing Store

The best backing store for iSCSI is the zvol you created in episode 6. ZFS provides snapshots and checksums underneath the LUN, so block data gets protected too.

zfs create -V 500g -o sync=always tank/zvol-db1

The zfs create -V 500g -o sync=always tank/zvol-db1 command creates a 500-gigabyte zvol with mandatory synchronization. The sync=always option matters for database workloads so a write isn't considered successful before it's truly stored.

#Connecting a LUN to a Target

Once the zvol exists, the LUN is added to the target. Through targetcli, the sequence is: create a backstore from the zvol, add it as a LUN, then create an ACL for the initiator.

targetcli
cd /backstores/block
create block1 /dev/zvol/tank/zvol-db1
cd /iscsi
create iqn.2026-08.lab.local:nas-db

The targetcli command opens the interactive target configuration shell. After the block1 backstore is created from the zvol, the target and LUN can be connected.

#CHAP Authentication

#Securing with CHAP

Without authentication, anyone on the network could access the target. CHAP (Challenge-Handshake Authentication Protocol) verifies the initiator's identity with a shared username and secret. Enable it whenever your environment isn't fully isolated.

IncomingUsername: nas-init
IncomingUser: nas-init
Password: rahasia-kuat-2026

On TrueNAS SCALE, CHAP credentials are set on the Shares > Block Shares > iSCSI page. Use a long password and store it in a password manager, because it will be required on the initiator side.

#Configuring the Initiator with CHAP

On the client side, CHAP options are given when logging into the target:

iscsiadm -m discovery -t sendtargets -p 192.168.1.100
iscsiadm -m node -T iqn.2026-08.lab.local:nas-db \
  -p 192.168.1.100 --op update -n node.session.auth.authmethod -v CHAP

The first iscsiadm command discovers the target, and the second enables CHAP for the session. Credential details are filled in the node configuration file or via the appropriate auth flags.

#iSCSI Use Cases

#VMware and Hyper-V Datastores

VMware ESXi and Hyper-V use iSCSI as shared storage for datastores. After an iSCSI login on the hypervisor, the block disk is formatted as a VMFS or NTFS datastore and can immediately be used to store VMs.

iscsiadm -m session
lsblk

The iscsiadm -m session output shows connected targets, and lsblk shows the iSCSI disk as a new device like sdb. This disk is then formatted and used by the hypervisor.

#Kubernetes PersistentVolumes (iSCSI)

Kubernetes supports iSCSI PVs for workloads that need a block device. iSCSI PVs are accessed with ReadWriteOnce mode and suit stateful databases like PostgreSQL.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: iscsi-pv
spec:
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteOnce
  iscsi:
    targetPortal: 192.168.1.100:3260
    iqn: iqn.2026-08.lab.local:nas-db
    lun: 0
    fsType: ext4

The manifest above registers an iSCSI target as a PV. It's block-level, so it's better suited for databases than file-based NFS.

#Block-Level Backup

Because it's block-based, iSCSI enables backups at the LUN level — for example, snapshotting a zvol and sending the snapshot elsewhere. This opens a backup pattern different from file-level rsync, which we'll discuss further in episode 12.

#Closing

In this episode 11 you mastered iSCSI: understanding the target and initiator roles, creating LUNs with zvols as backing store, securing connections with CHAP, and using iSCSI for VMware datastores, Hyper-V, Kubernetes PVs, and block-level backup.

Key takeaways:

• iSCSI presents raw block storage over TCP/IP, not file sharing.
• A zvol is the ideal backing store because it inherits ZFS protection.
• CHAP must be enabled to prevent unauthorized target access.
• iSCSI suits hypervisor datastores and stateful databases.
• A single LUN must not be shared by two writers without a cluster filesystem.

In the next episode, episode 12, we'll cover snapshots, replication, and backup — from manual and scheduled ZFS snapshots, retention policies, rollback, to replication with zfs send and receive, rsync, and TrueNAS Replication Tasks for offsite backup. Your storage is ready; now it's time to make sure data is never lost.