Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?


iscsiadm -m discovery -t sendtargets -p


Just to verify it actually worked:

iscsiadm -m session


tcp: [1],1

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:, portal:,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:, portal:,3260] through [iface: default] is operational now

Ran a login command:

iscsiadm -m node -T -p -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?

share|improve this question
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
up vote 2 down vote accepted

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.

share|improve this answer
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. – Aaron Copley Sep 21 '12 at 16:05
I will .. you have to wait 24 hrs first. – jcalfee314 Sep 21 '12 at 19:33

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
share|improve this answer

You need to login to the target after discovery.

iscsiadm -m node -T -p -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?

share|improve this answer
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

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.