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?

1
  • 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, 2012 at 19:07

5 Answers 5

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.

2
  • Be sure to mark your own answer as accepted! This helps the backend to know this question is resolved even if you answered it yourself. Sep 21, 2012 at 16:05
  • 1
    I will .. you have to wait 24 hrs first.
    – jcalfee314
    Sep 21, 2012 at 19:33
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.

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
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.

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?

3
  • 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, 2012 at 20:39
  • I have edited the original post - thanks for pointing this out.
    – jcalfee314
    Sep 20, 2012 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. Sep 20, 2012 at 21:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .