Advanced iSCSI Procedures

This article covers non-trivial iSCSI procedures that require careful execution to avoid data loss or service disruption.

When an iSCSI target needs to be expanded, the process varies depending on the underlying storage technology. This guide covers both LVM2 and ZFS-based targets.

For LVM2-backed exports:

1. Unmount and disconnect the target on all initiators
2. Expand the logical volume on the target server
3. Restart the iSCSI target service (recommended for consistency)
4. Reconnect initiators and resize the filesystem

The following procedure assumes:

• Target: FreeBSD with ZFS volumes (zvols)
• Initiator: Debian/Devuan-based Linux systems

# Set the new size on the ZFS volume
# Example: storage/iscsi/target is the zvol path
# newsize format: 500G, 2T, etc.
zfs set volsize=500G storage/iscsi/target
 
# Notify ctld of the configuration change
# 'reload' may work instead of 'restart' if supported
service ctld restart

After expanding the target, initiators must rescan to detect the new size.

Option A: Rescan all sessions (not recommended for production)

# Rescans ALL iSCSI sessions - use with caution in production
iscsiadm -m session --rescan

Option B: Rescan specific target only (recommended)

# Method 1: Find the Session ID (SID) for your specific target
# Replace 'thing1' with a unique substring from your target name
SID=$(iscsiadm -m session -P 0 | grep thing1 | cut -d'[' -f2 | cut -d']' -f1)
 
# Rescan only that specific session
iscsiadm --mode session --sid=$SID --rescan
 
# Alternatively, manually find SID and run directly:
# iscsiadm -m session          # Lists all sessions with SIDs
# iscsiadm --mode session --sid=15 --rescan
 
# Verify the new size has been detected
fdisk -l /dev/disk/by-path/ip-<target-ip>:3260-iscsi-<iqn>-lun-<num>
# Or use lsblk for a cleaner view
lsblk /dev/disk/by-path/ip-<target-ip>*

After the initiator recognizes the new size, expand the filesystem:

For ext4:

resize2fs /dev/sdX

For XFS:

xfs_growfs /mount/point

For LVM:

pvresize /dev/sdX
lvextend -l +100%FREE /dev/vg_name/lv_name
resize2fs /dev/vg_name/lv_name  # for ext4

For virtual machines: Consider booting from GParted Live CD to safely resize partitions without mounting them.

Removing an iSCSI target requires cleanup on both the target server and all initiators. The initiator maintains a local database of discovered targets that must be explicitly cleaned.

# Step 1: Logout from the iSCSI session
# Replace with your actual target IQN and portal address
iscsiadm -m node \
  --target='iqn.2005-03.org.example:storage.target1' \
  --portal "192.168.1.100:3260" \
  --logout
 
# Step 2: Remove the target from the local database
iscsiadm -m node \
  --target='iqn.2005-03.org.example:storage.target1' \
  --portal "192.168.1.100:3260" \
  -o delete
 
# Verify removal
iscsiadm -m node

When decommissioning an entire iSCSI infrastructure or target server:

# Stop the iSCSI initiator service
# sysV (Devuan, other good Linux systems)
service start iscsiadm
service stop open-iscis # or iscsid on some systems
 
# systemd (RedHat, other Linux systems which have drunk the Kool-aid)
systemctl stop iscsiadm
systemctl stop open-iscsi    # or iscsid on some systems
 
# Remove iSCSI configuration databases
# Debian/Ubuntu location:
rm -rf /etc/iscsi/send_targets/*
rm -rf /etc/iscsi/nodes/*
 
# RHEL/CentOS/Rocky location:
rm -rf /var/lib/iscsi/send_targets/*
rm -rf /var/lib/iscsi/nodes/*
 
# Restart the service
service start open-iscis # sysV
systemctl start open-iscsi # systemd

# Logout from all active sessions
iscsiadm -m node --logoutall=all
 
# Remove all node records
iscsiadm -m node -o delete
 
# Verify all targets are removed
iscsiadm -m node

• iscsiadm man page
• FreeBSD iSCSI Handbook
• Open-iSCSI Google Group Discussion

• Always test resize operations in a non-production environment first
• Maintain backups before performing any resize operations
• Document your target IQNs and portal addresses
• Use by-path device naming for consistency across reboots
• Monitor initiator logs (/var/log/syslog or journalctl) during operations

Last updated: February 2, 2026