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).
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
