The LUN is mapped on the array, the target shows it as presented, and lsblk on the server still shows nothing. The new iSCSI disk is there — the kernel has simply not looked for it. Linux does not poll the SCSI bus, so a LUN added to an already established iSCSI session stays invisible until something triggers a scan. Below is the whole path, from "the array says it is mapped" to a mounted XFS filesystem on LVM that still mounts after a reboot. Tested on RHEL 8 and RHEL 9; the same commands work unchanged on AlmaLinux 9 and Rocky Linux 9.
Why a new iSCSI disk does not appear on its own
An iSCSI session is a transport, not a device list. Once iscsid has logged in to the target the session stays up, and a LUN added afterwards is announced by the target — but the initiator only creates a block device when it is told to scan for one. Rebooting works because the session is rebuilt from scratch and every LUN is enumerated on the way up. It is just a very expensive way to run a scan.
This assumes the iSCSI session to the target is already logged in — iscsiadm -m session should list it. If it does not, that is a separate iscsiadm -m discovery -t st -p <portal> and --login step first, and no amount of rescanning will conjure a device out of a session that does not exist.
Two other things are worth knowing before you start:
- A rescan is read-only. It creates device nodes; it never writes to the disk.
- On a multipathed target you will get one
/dev/sdXper path. That is normal, and it is the reason the identification step below matters.
Step 1. Rescan the SCSI hosts for the new iSCSI disk
The portable way is to write the wildcard scan triple - - - (channel, target, LUN) into the scan file of every SCSI host:
[root@RHEL tmp]# nano iscsi_rescan.sh
for BUS in /sys/class/scsi_host/host*/scan
do
echo "- - -" > ${BUS}
done
[root@RHEL tmp]# chmod +x iscsi_rescan.sh
[root@RHEL tmp]# ./iscsi_rescan.sh
Two shorter alternatives do the same job:
# rescan only the iSCSI sessions, not every SCSI host
iscsiadm -m session --rescan
# or, from sg3_utils, with a summary of what changed
rescan-scsi-bus.sh -a
If nothing new turns up, the problem is above the initiator: the LUN is not mapped to this IQN, or the session is down. Check with iscsiadm -m session -P 1 before blaming the rescan.
Step 2. Identify the disk before you touch it
This is the step people skip, and it is the one that destroys data. pvcreate on the wrong device is not recoverable in any pleasant way.
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,WWN
ls -l /dev/disk/by-path/ | grep iscsi
multipath -ll
Match the size and the WWN against what the array shows. If multipath -ll lists the new LUN, use the /dev/mapper/mpath* device from here on and not the raw /dev/sdX, or you will build the volume group on a single path and lose the filesystem the first time that path flaps.
Step 3. Create the physical volume, volume group and logical volume
With the right device confirmed, the LVM part is the standard three commands. The example below is a single-path host, so /dev/sdb is what Step 2 confirmed — on a multipathed target, substitute your /dev/mapper/mpathX name in every command from here to the end:
[root@RHEL tmp]# pvcreate /dev/sdb
Physical volume "/dev/sdb" successfully created.
[root@RHEL tmp]# vgcreate backup_vg /dev/sdb
Volume group "backup_vg" successfully created
[root@RHEL tmp]# vgdisplay backup_vg | grep "Free"
Free PE / Size 314572 / <1.20 TiB
[root@RHEL tmp]# lvcreate -L1.19TiB -n backup_lv backup_vg
Rounding up size to full physical extent 1.19 TiB
Logical volume "backup_lv" created.
Note the gap between <1.20 TiB free and the 1.19 TiB actually requested. LVM allocates in whole extents, so asking for the round number usually fails with Volume group "backup_vg" has insufficient free space. Avoid the arithmetic entirely:
lvcreate -l 100%FREE -n backup_lv backup_vg
Note also that no partition table is involved. Putting LVM straight on the whole device is the normal choice for an iSCSI disk that exists only to carry one volume group — it removes an alignment problem and makes a later resize simpler.
Step 4. Format the new volume with XFS
[root@RHEL tmp]# mkfs.xfs /dev/backup_vg/backup_lv
meta-data=/dev/backup_vg/backup_lv isize=512 agcount=4, agsize=79859712 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=0, sparse=0
data = bsize=4096 blocks=319438848, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal log bsize=4096 blocks=155976, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
XFS is the RHEL default and it grows online later, which is what you want on a volume that lives on an array. It does not shrink, though — Red Hat's own documentation states that it is not possible to decrease the size of an XFS file system — so err on the generous side now rather than planning to trim it later.
Step 5. Mount it — and the /etc/fstab entry that breaks the boot
Here is the original, and it is the line that will eventually cost you a trip to the console:
[root@RHEL tmp]# mkdir /backup
[root@RHEL tmp]# nano /etc/fstab
/dev/backup_vg/backup_lv /backup xfs defaults 0 0
[root@RHEL tmp]# mount -a
mount -a succeeds, because by the time you run it the network is up and the iSCSI session is established. That proves nothing about the next boot. With defaults alone, systemd's fstab generator treats the mount as a local filesystem and orders it before the network, the mount fails, and a failed non-optional mount drops the machine into emergency mode. Add _netdev:
/dev/backup_vg/backup_lv /backup xfs defaults,_netdev 0 0
_netdev tells systemd this filesystem needs the network, so the generated mount unit gains After=remote-fs-pre.target network-online.target — well past the point where the network, and in practice the already-running iSCSI session, are up. Note that this is ordering against the network, not a hard dependency on the iSCSI login itself: iscsi.service only declares Before=remote-fs.target, so the two are guaranteed to finish before the same target rather than to be sequenced against each other. If the volume is not essential, add nofail as well so a missing target delays the boot instead of stopping it.
There is no need to use a UUID here, unlike a bare /dev/sdX entry: /dev/mapper and /dev/<vg>/<lv> names come from the LVM metadata on the disk itself, so they follow the volume group wherever the kernel happens to enumerate it.
Verify
findmnt --verify --verbose # parses fstab and reports bad entries
systemctl daemon-reload # regenerate the mount units from fstab
df -hT /backup
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT
findmnt --verify catches typos and unknown options without touching anything. The only real proof, though, is a reboot in a window where you can reach the console — do that once, deliberately, rather than discovering it during an unplanned restart.
Rollback
If you built the volume on the wrong device, unwind it in the opposite order and stop as soon as you reach something you did not create:
umount /backup
lvremove /dev/backup_vg/backup_lv
vgremove backup_vg
pvremove /dev/sdb
Then remove the fstab line. Deleting the LUN on the array without doing this first leaves the volume group referencing a device that no longer exists, and every subsequent LVM command prints a warning about it.
Once the volume is in use and the array hands you more space, growing it is a different procedure — see how to extend an LVM partition on RHEL, CentOS and Ubuntu, which picks up exactly where this post ends.
