7

I have installed the scsi-target-utils package on CentOS and I used it to perform a discovery. The discovery did give me an active session. I restarted the iscsi service but I do not see any new devices (fdisk -l). I see in /var/log/messages that my connection is operational now.

I'm not sure how to debug this further. Can someone direct me into fixing this?

discovery:

iscsiadm -m discovery -t sendtargets -p 192.168.0.155

returns:

192.168.0.155:3260,-1 iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3

Just to verify it actually worked:

iscsiadm -m session

returns

tcp: [1] 192.168.0.155:3260,1 iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3

restarting as the directions say to do:

service iscsi restart

output written to /var/log/message

Stopping iscsi: Sep 20 12:14:22 localhost kernel: connection1:0: detected conn error (1020)
                                                           [  OK  ]
Starting iscsi: Sep 20 12:14:22 localhost kernel: scsi1 : iSCSI Initiator over TCP/IP
Sep 20 12:14:22 localhost iscsid: Connection1:0 to [target: iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3, portal: 192.168.0.155,3260] through [iface: default] is shutdown.
Sep 20 12:14:22 localhost iscsid: Could not set session2 priority. READ/WRITE throughout and latency could be affected.
                                                           [  OK  ]
[root@db iscsi]# Sep 20 12:14:23 localhost iscsid: Connection2:0 to [target: iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3, portal: 192.168.0.155,3260] through [iface: default] is operational now

Ran a login command:

iscsiadm -m node -T iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3 -p 192.168.0.155 -l

No errors, no logging occurred.

Next I compared the output from "fdisk -l|egrep dev" both with the iscsi session and without. There is no difference. I suppose I could just look in /etc/mtab. Any ideas on how I can get an iscsi device?

jcalfee314
  • 269
  • 1
  • 6
  • 14
  • 1
    I have seen this recently, too. Can you post the output of tgtadm --lld iscsi --op show --mode target and the part of `/etc/tgt/targets.conf` where you define your and targets LUN's? – wzzrd Sep 20 '12 at 19:07

5 Answers5

2

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.

jcalfee314
  • 269
  • 1
  • 6
  • 14
1

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.

Pyzo
  • 135
  • 1
  • 1
  • 7
1

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
msmcknight
  • 11
  • 1
1

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.

Anton Kaiser
  • 111
  • 3
0

You need to login to the target after discovery.

iscsiadm -m node -T iqn.2009-02.com.twinstrata:cloudarray:sn-1d07c1b62d4ec8f3 -p 192.168.0.155:3260 -l

See: Configure a system as an iSCSI initiator that persistently mounts an iSCSI target
How to use iSCSI Targets on Linux
How can I connect to iSCSI target from Linux console?

Aaron Copley
  • 12,525
  • 5
  • 47
  • 68
  • Sorry, tried that. The login command returns with no input and an exist value of 0. There is no device. No messages in the log. – jcalfee314 Sep 20 '12 at 20:39
  • I have edited the original post - thanks for pointing this out. – jcalfee314 Sep 20 '12 at 20:46
  • Was the login after restarting the iscsi service? If not, it sounds like it's not configured correctly on the target but I am not sure where to start with that. – Aaron Copley Sep 20 '12 at 21:14