iscsiadm: discovery record not found

6,716 views
Skip to first unread message

Dr. Ed Morbius

unread,
Feb 18, 2011, 9:59:17 PM2/18/11
to Open iSCSI list
Trying to set up a number of initiators on CentOS 5.5 with a Dell
MD32xxi target.

I've successfully configured several other identical initiators with
these targets.

$ export DP=<dataport IP>
$ sudo iscsiadm -m discoverydb -t sendtargets -p $DP:3260
iscsiadm: Discovery record [$DP,3260] not found.


I've tried:

- Restarting iscsi and iscsid services.
- Clearing all database records.


There are no current records in the iscsiadm database best I can tell:

$ sudo iscsiadm -m node
iscsiadm: no records found!
:( sudo iscsiadm -m session
iscsiadm: No active sessions.
$ sudo iscsiadm -m discoverydb
:(

$ sudo iscsiadm -m iface
default tcp,<empty>,<empty>,<empty>,<empty>
iser iser,<empty>,<empty>,<empty>,<empty>
bnx2i.f0:4d:a2:03:5e:09 bnx2i,f0:4d:a2:03:5e:09,<empty>,<empty>,<empty>
bnx2i.f0:4d:a2:03:5e:0f bnx2i,f0:4d:a2:03:5e:0f,<empty>,<empty>,<empty>
bnx2i.f0:4d:a2:03:5e:0b bnx2i,f0:4d:a2:03:5e:0b,<empty>,<empty>,<empty>
bnx2i.f0:4d:a2:03:5e:0d bnx2i,f0:4d:a2:03:5e:0d,<empty>,<empty>,<empty>


I've got records in /var/lib/iscsi/ifaces, but no other /var/lib/iscsi/
subdirectories.


Any suggestions on resolving this?

--
Dr. Ed Morbius, Chief Scientist / |
Robot Wrangler / Staff Psychologist | When you seek unlimited power
Krell Power Systems Unlimited | Go to Krell!

Mike Christie

unread,
Feb 18, 2011, 11:45:09 PM2/18/11
to Dr. Ed Morbius, Open iSCSI list
On 02/18/2011 08:59 PM, Dr. Ed Morbius wrote:
> Trying to set up a number of initiators on CentOS 5.5 with a Dell
> MD32xxi target.
>
> I've successfully configured several other identical initiators with
> these targets.
>
> $ export DP=<dataport IP>
> $ sudo iscsiadm -m discoverydb -t sendtargets -p $DP:3260
> iscsiadm: Discovery record [$DP,3260] not found.
>

> I've got records in /var/lib/iscsi/ifaces, but no other /var/lib/iscsi/
> subdirectories.

Have you done discovery to that address,port or done a -o new to create
a db discovery record for it? If not then that is what you would expect.

You can do


sudo iscsiadm -m discoverydb -t sendtargets -p $DP:3260 -D

without the -D, then iscsiadm is just looking for the discovery record
for that discovery address,port.

To have iscsiadm try to do discovery pass it the -D argument or do the
old style

iscsiadm -m discovery -t st -p ip:port
(no db in the discovery mode name).

Dr. Ed Morbius

unread,
Feb 19, 2011, 12:40:54 AM2/19/11
to open-...@googlegroups.com
on 21:37 Fri 18 Feb, Mark Lehrer (ma...@knm.org) wrote:
> > iscsiadm: Discovery record [$DP,3260] not found.
>
> It looks like you have a shell syntax problem here. DP should be
> the IP address (aka portal).

I obfuscated that in the response.

For the shell command, $DP is defined to a non-routeable 10/8 net.

Dr. Ed Morbius

unread,
Feb 19, 2011, 1:31:22 AM2/19/11
to Open iSCSI list

The second command ("-m discovery") works. "-m discoverydb" doesn't

OK, that raises another question: what's the difference between
"discovery" mode and "discoverydb" mode? I'd been under the impression
that "discoverydb" was a synonym for "discovery" (or vice versa).
Apparently not.

The iscsiadm manpage is less than clear on this distinction:

-m, --mode op
specify the mode. op must be one of discoverydb, node, fw, host
iface or session.

If no other options are specified: for discoverydb and node, all
of their respective records are displayed; for session, all
active sessions and connections are displayed; for fw, all boot
firmware values are displayed; for host, all iSCSI hosts are
displayed; and for iface, all ifaces setup in /etc/iscsi/ifaces
are displayed.

... unless it's been updated since. Working from
iscsi-initiator-utils-6.2.0.871-0.20.el5_5

Mike Christie

unread,
Feb 19, 2011, 11:30:16 PM2/19/11
to Dr. Ed Morbius, Open iSCSI list

discoverydb mode will use the discovery values found in
/var/lib/sendtargets/ip,port if found. discovery mode will use the
iscsid.conf settings.

Mike Christie

unread,
Feb 19, 2011, 11:55:12 PM2/19/11
to Dr. Ed Morbius, Open iSCSI list
On 02/19/2011 12:31 AM, Dr. Ed Morbius wrote:
>
> The iscsiadm manpage is less than clear on this distinction:
>
> -m, --mode op
> specify the mode. op must be one of discoverydb, node, fw, host
> iface or session.
>
> If no other options are specified: for discoverydb and node, all
> of their respective records are displayed; for session, all
> active sessions and connections are displayed; for fw, all boot
> firmware values are displayed; for host, all iSCSI hosts are
> displayed; and for iface, all ifaces setup in /etc/iscsi/ifaces
> are displayed.
>
> ... unless it's been updated since. Working from

The readme info is better. Will try to update the man page.

Hoot, Joseph

unread,
Feb 20, 2011, 7:56:47 AM2/20/11
to open-...@googlegroups.com
Mike,

We had noticed another item that needed updating in the man page (or in the code itself). Here are the scenarios:

1) `iscsiadm -m node -u -T <iqn_here>` = unlogin from that iqn.
2) `iscsiadm -m node -U` = unlogin from ALL iqn's
3) `iscsiadm -m node -u <iqn_here>` = <<--- notice we forgot the -T. If you do that, the lowercase -u will actually do what the capital -U does.

We happened to notice that the hard way (oops... didn't mean to take down 15 vms!). So I'm not sure if that is a bug or if the man page is just incorrect (my guess would be bug in that it should do error-checking to see if there is any -T or not. And if NOT, then throw exit some number with messages stating "-u requires iqn".

not sure if that was fixed or not and saw you were going to update the man page, so I figured I'd toss this your way.


Thanks,
Joe

===========================
Joseph R. Hoot
Lead System Programmer/Analyst
(w) 716-878-4832 (Office - Receptionist/able to leave message)
(w) 716-878-4863 (Direct - no voicemail)
(c) 716-759-HOOT
joe....@itec.suny.edu
GPG KEY: 7145F633
===========================

> --
> You received this message because you are subscribed to the Google Groups "open-iscsi" group.
> To post to this group, send email to open-...@googlegroups.com.
> To unsubscribe from this group, send email to open-iscsi+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
>

Mike Christie

unread,
Feb 21, 2011, 5:29:43 PM2/21/11
to open-...@googlegroups.com, Hoot, Joseph
On 02/20/2011 06:56 AM, Hoot, Joseph wrote:
> Mike,
>
> We had noticed another item that needed updating in the man page (or in the code itself). Here are the scenarios:
>
> 1) `iscsiadm -m node -u -T<iqn_here>` = unlogin from that iqn.
> 2) `iscsiadm -m node -U` = unlogin from ALL iqn's

That should be:

iscsiadm -m node -U [all | manual | automatic ]

Just a -U does not work for me.

> 3) `iscsiadm -m node -u<iqn_here>` =<<--- notice we forgot the -T. If you do that, the lowercase -u will actually do what the capital -U does.
>

That is described in the README. It is not described in the man page.

For -U you pass in a startup method to match. For -u you can pass in a
portal, target, iface, some combo of them or none of them.

Hoot, Joseph

unread,
Feb 22, 2011, 9:15:12 AM2/22/11
to open-...@googlegroups.com

OK... yep... I see that now Mike. So it looks like the man page just wasn't as clear to us. But the README definitely makes it more obvious.


from README:
============

- iSCSI Logout to all portals on every node/starget through each interface
set in the db:

./iscsiadm -m node -u

Warning: this does not check startup values like the logout/login all
option. Do not use this if you are running iscsi on your root disk.


from man page:
============

-u, --logout
logout for a specified record.

This option is only valid for node and session mode.

-U, --logoutall==[all,manual,automatic]
logout all sessions with the node or conn startup values passed in or all run-
ning sesssion, except ones marked onboot, if all is passed in.

This option is only valid for node mode (it is valid but not functional for ses-
sion mode).

===========================
Joseph R. Hoot
Lead System Programmer/Analyst
(w) 716-878-4832 (Office - Receptionist/able to leave message)
(w) 716-878-4863 (Direct - no voicemail)
(c) 716-759-HOOT
joe....@itec.suny.edu
GPG KEY: 7145F633
===========================

Mike Christie

unread,
Feb 22, 2011, 6:05:51 PM2/22/11
to open-...@googlegroups.com
On 02/22/2011 08:15 AM, Hoot, Joseph wrote:
>
> OK... yep... I see that now Mike. So it looks like the man page just wasn't as clear to us. But the README definitely makes it more obvious.
>

Yeah, will fix that too. Working on some other iscsiadm man pages for
Dr. Morbius's discoverydb/discovery comment.

Mark Lehrer

unread,
Feb 18, 2011, 11:37:36 PM2/18/11
to open-...@googlegroups.com, Dr. Ed Morbius
> iscsiadm: Discovery record [$DP,3260] not found.

It looks like you have a shell syntax problem here. DP should be the IP
address (aka portal).

Mark

Hannes Reinecke

unread,
Feb 23, 2011, 9:44:17 AM2/23/11
to open-...@googlegroups.com, Mike Christie, Dr. Ed Morbius
I have just stumbled upon this issue, too.

And found it pretty awkward to use; after all, to all intents and
purposes the hostname and the IP-address can be used interchangeably.
I (and our QA :-( ) don't see a reason why should draw a blank here.

So after long hours of debugging I came up with this patch, which
resolves the hostname into the IP address and uses this for lookup.

Mike, comments?

Cheers,

Hannes
--
Dr. Hannes Reinecke zSeries & Storage
ha...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N�rnberg
GF: Markus Rex, HRB 16746 (AG N�rnberg)

open-iscsi-resolve-hostname-for-discovery

Mike Christie

unread,
Feb 24, 2011, 12:05:10 AM2/24/11
to Hannes Reinecke, open-...@googlegroups.com
On 02/23/2011 08:44 AM, Hannes Reinecke wrote:
> On 02/19/2011 05:45 AM, Mike Christie wrote:
>> On 02/18/2011 08:59 PM, Dr. Ed Morbius wrote:
>>> Trying to set up a number of initiators on CentOS 5.5 with a Dell
>>> MD32xxi target.
>>>
>>> I've successfully configured several other identical initiators with
>>> these targets.
>>>
>>> $ export DP=<dataport IP>
>>> $ sudo iscsiadm -m discoverydb -t sendtargets -p $DP:3260
>>> iscsiadm: Discovery record [$DP,3260] not found.
>>>
>>
>>> I've got records in /var/lib/iscsi/ifaces, but no other /var/lib/iscsi/
>>> subdirectories.
>>
>> Have you done discovery to that address,port or done a -o new to create
>> a db discovery record for it? If not then that is what you would expect.
>>
>> You can do
>>
>>
>> sudo iscsiadm -m discoverydb -t sendtargets -p $DP:3260 -D
>>
>> without the -D, then iscsiadm is just looking for the discovery record
>> for that discovery address,port.
>>
>> To have iscsiadm try to do discovery pass it the -D argument or do the
>> old style
>>
>> iscsiadm -m discovery -t st -p ip:port
>> (no db in the discovery mode name).
>>
> I have just stumbled upon this issue, too.

I am not sure you guys are talking about the same issue. Here is the
long story for why we have discoverydb and discover mode. It is
bascially because I messed up. So if you like long stories read on. If
not skip to the patch comments :)


In the discoverydb issue it is that with discoverydb mode you can use -o
new to create a discovery record manually. This was to make it easier to
script/manage. So if you had multiple discovery addresses that needed
different discovery settings you had to edit iscsid.conf discovery
settings, run iscsiadm discovery command for -p A, then edit iscsid.conf
disocvery settings again and then rerun iscsiadm discovery command for -p B.

With discoverydb mode your script can do

iscsiadm -m discoverydb -p ip:port -o new
iscsiadm -m discoverydb -p ip:port -o update -n discovery.somesetting -v
value
iscsiadm -m discoverdb -p ip:port -D


A long time ago, I think when Alex and Dimitry and I transitioned
maintainership, I messed up the original "discovery" mode. We used to do
something like the above with -o new in the old discovery mode and
--login in discovery mode had you use the discovery record and login to
the discovery address. But at some point I changed it so -o new operated
on the node records that got created and --login logged into the portals
that got discovered.

A couple months ago I realized I messed up when someone was requesting
the behavior. I could not change the current discovery behavior because
users were using it so I added the discoverydb mode which acts on the
discovery db. (I think no one noticed I messed up before because there
not as many users or at least we did not have vocal users because no one
said anything. And I never knew I messed up until I was looking at that
code a couple months ago).

So now we have commands like:

// just create discovery record
iscsiadm -m discoverydb -p ip:port -o new
you can then use -o update to edit the settings like in node mode.


// do discovery and only add records for portals that are not yet
present in the db
iscsiadm -m discovery -p ip:port -o new
or
iscsiadm -m discoverydb -p ip:port --discover -o new
// note that for discoverydb mode you pass in the --discover argument,
and that the discoverydb command will use the discovery record settings
where discovery mode would use the iscsid.conf settings.


>
> And found it pretty awkward to use; after all, to all intents and
> purposes the hostname and the IP-address can be used interchangeably.
> I (and our QA :-( ) don't see a reason why should draw a blank here.
>

I just added support for this to node mode with commit
4d045cdeaf701f8abe6bee4f1e433f7bc9c50493.

I did not add support for discovery mode, because I figured you would
just use whatever you used the first time. With node mode though the
target decided and you had no control. I am ok with adding support though.


> So after long hours of debugging I came up with this patch, which
> resolves the hostname into the IP address and uses this for lookup.
>

I am ok with the idea. I am not sure if the patch works ok though. I was
not sure what version to apply it to, so the comment below are based on
me trying to port it.

For the patch it seems if you passed in a hostname into

iscsiadm -m discovery -p myhost -t st

but later did

iscsiadm -m discovery -p myhost

it would not work since we are only resolving in the discovery path. So
we need to resolve and convert in other paths. For example if you ran

iscsiadm -m discovery
or
iscsiadm -m discovery -P 1

you get the ip address printed out when if they passed in the hostname
they probably want to see the hostname.

Also it seems since we resolve the hostname to a IP and use that for
discovery record value if the hostname changes IPs then the db is messed up.

For 4d045cdeaf701f8abe6bee4f1e433f7bc9c50493 I tried to do the
resolution on the fly. So the user/target gives us whatever they want
then I tried to resolve and match. I will try to convert your patch to
support the above. Give me a couple days. I am very backed up (I am just
about done porting the broadcom patch to fix if
session_login_task->iscsi_conn_connect->ep_connect fails with a
transient error).

Dr. Ed Morbius

unread,
Mar 4, 2011, 4:12:50 PM3/4/11
to open-...@googlegroups.com

<...>

Thanks (belatedly) for the story.

Ulrich Windl

unread,
Mar 14, 2011, 5:55:37 AM3/14/11
to open-...@googlegroups.com
>>> Mike Christie <mich...@cs.wisc.edu> schrieb am 24.02.2011 um 06:05 in
Nachricht <4D65E706...@cs.wisc.edu>:

[...]

I still have some questions (see inline comments).

If not there already? Is this mode dependent on the actual exstence of the portal, or does it allow to "pre-create" a record for a portal to be used later?

> iscsiadm -m discoverydb -p ip:port -o new
> you can then use -o update to edit the settings like in node mode.
>
>
> // do discovery and only add records for portals that are not yet
> present in the db
> iscsiadm -m discovery -p ip:port -o new
> or
> iscsiadm -m discoverydb -p ip:port --discover -o new
> // note that for discoverydb mode you pass in the --discover argument,
> and that the discoverydb command will use the discovery record settings
> where discovery mode would use the iscsid.conf settings.
>

What is unclear: In which of the commands above I can specify variable settings different from iscsid.conf (so that those are recorded permanently with the corresponding DB records)?

Reply all
Reply to author
Forward
0 new messages