CentOS iscsi initiator has session but there is no block device

TwinStrata required my clinet's iqn number. This is located here:

less /etc/iscsi/initiatorname.iscsi

Once the server change was in place, I restarted the client iscsi service and I could see /dev/sda.

I had this same issue and it turned out to be a target problem.

In my case (target was a NetApp) I had forgotten to map the initiator group to the LUN.

I ran into a very similar situation and I appreciate the tips found here. In my case, I had changed the IQN in the /etc/iscsi/initiatorname.iscsi file and had restarted iscsi several times, nut still could not connect.

The answer for me was to restart iscsid (notice the "d"), specifically, I had to restart both iscsi and iscsid:

# service iscsi stop
# service iscsid stop
# service iscsid start
# service iscsi start

I had this same issue. I would conclude that it's all about the target configuration.

All the log messages looked good, except nothing got mounted in /dev/. I had a Windows Server 2012 R2 as the target and was trying to provide an existing virtual disk (VHDX) to Ubuntu. That VHDX has previously been provided to and used by VMWare ESXi with its own VMFS format, and looks like Ubuntu coudn't handle this for some reason after the connection was established. Once I created a new virtual disk and a new target for it with the exact same settings, creating a new session with iscsiadm finally gave me a block device. Testing other scenarios afterwards, I figured that the same thing happens with targets that are created from copies of VHDX files that are imported as iSCSI virtual disks. But those are obviously broken, because extending them (they were thin provisioned) gives an error in the Server Manager. So if a target is somehow broken, open-iscsi won't give you a block device for it.

The only solution seems to be to redo the whole configuration (and yes, don't forget to set up the initiator ID in the target's config as stated in the accepted answer) when running into this issue.

Just as a note as to what counts as broken targets: I finally found that my target was broken, because VHDX files on ReFS volumes cannot be used if their FileIntegrity bit is set to Enabled=True. Sadly, only Hyper-V gives an error when trying to copy a VHD/VHDX file to an ReFS volume, but not the Server Manager in the section for iSCSI target disk setup. The folder created by the iSCSI target wizard for new disks (called iscsivirtualdisks) hat its FileIntegrity bit set to Enable, and hence all files created in this folder (VHDX files that you copy there) will also get that bit set to Enabled=True. I would classify this as a bug in the Server Manager.