zfs discuss - Sep 2012 - iscsi confusion

I am confused, because I would have expected a 1-to-1 mapping, if you create an
iscsi target on some system, you would have to specify which LUN it connects to.
But that is not the case...

I read the man pages for sbdadm, stmfadm, itadm, and iscsiadm.  I read some
online examples, where you first "sbdadm create-lu" which gives you a
GUID for a specific device in the system, and then "stmfadm add-view
$GUID", and then "itadm create-target."

It''s this last command that confuses me - Because it generates an iscsi
target "iqn.blahblah"...  And it will create as many as you specify,
regardless of how many LUN''s you have available.  So how can I know
which device I''m handing out to some initiator?  And if an initiator
connects to all those different iqn.blahblah addresses...  What device will they
actually be mucking around with?

I''m not quite sure what in my brain is thinking wrong, but I''m
guessing the explanation is something like this:

(can anyone tell me if this is the correct interpretation?)

I shouldn''t be thinking in such linear terms.  When I create an iscsi
target, don''t think of it as connecting to a device - instead, think of
it as sort of a channel.  Any initiator connecting to it can see any of the
devices that I have done add-views on.  But each iscsi target can only be used
by one initiator at a time.

Is that a good understanding?

Thanks...
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20120928/278a847b/attachment.html>

I am confused, because I would have expected a 1-to-1 mapping, if you create an
iscsi target on some system, you would have to specify which LUN it connects to.
But that is not the case...

I read the man pages for sbdadm, stmfadm, itadm, and iscsiadm.  I read some
online examples, where you first "sbdadm create-lu" which gives you a
GUID for a specific device in the system, and then "stmfadm add-view
$GUID", and then "itadm create-target."

It''s this last command that confuses me - Because it generates an iscsi
target "iqn.blahblah"...  And it will create as many as you specify,
regardless of how many LUN''s you have available.  So how can I know
which device I''m handing out to some initiator?  And if an initiator
connects to all those different iqn.blahblah addresses...  What device will they
actually be mucking around with?

I''m not quite sure what in my brain is thinking wrong, but I''m
guessing the explanation is something like this:

(can anyone tell me if this is the correct interpretation?)

I shouldn''t be thinking in such linear terms.  When I create an iscsi
target, don''t think of it as connecting to a device - instead, think of
it as sort of a channel.  Any initiator connecting to it can see any of the
devices that I have done add-views on.  But each iscsi target can only be used
by one initiator at a time.

Is that a good understanding?

Thanks...
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20120928/d54445d3/attachment-0001.html>

On Sat, Sep 29, 2012 at 3:09 AM, Edward Ned Harvey
(opensolarisisdeadlongliveopensolaris)
<opensolarisisdeadlongliveopensolaris at nedharvey.com>
wrote:
> I am confused, because I would have expected a 1-to-1 mapping, if you
create
> an iscsi target on some system, you would have to specify which LUN it
> connects to.  But that is not the case...
Nope. one target can have anything from zero (which is kinda useless)
or many LUNs.
> I shouldn''t be thinking in such linear terms.  When I create an
iscsi
> target, don''t think of it as connecting to a device - instead,
think of it
> as sort of a channel.  Any initiator connecting to it can see any of the
> devices that I have done add-views on.
Yup
>  But each iscsi target can only be
> used by one initiator at a time.
Nope. Many people use iscsi to provide shared storage (e.g. for
clustering), where two or more initiators connetcs to the same target.

-- 
Fajar