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!
> 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 obfuscated that in the response.
For the shell command, $DP is defined to a non-routeable 10/8 net.
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
discoverydb mode will use the discovery values found in
/var/lib/sendtargets/ip,port if found. discovery mode will use the
iscsid.conf settings.
The readme info is better. Will try to update the man page.
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.
>
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.
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
===========================
Yeah, will fix that too. Working on some other iscsiadm man pages for
Dr. Morbius's discoverydb/discovery comment.
It looks like you have a shell syntax problem here. DP should be the IP
address (aka portal).
Mark
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)
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).
<...>
Thanks (belatedly) for the story.
[...]
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)?