[stgt] [PATCH 1/2] tgt-admin: check if direct-device exists before allocating it

[FUJITA Tomonori]

On Fri, 12 Sep 2008 19:22:30 +1000
"ronnie sahlberg" <ronniesahlberg at gmail.com> wrote:

> >> later I would also like to be able to configure for individual LUNs
> >> things like :
> >>    Only these initiators can see/access this particular LUN.
> >
> > Is it at all possible? To allow initiators access to specified LUNs only? In
> > tgtd, iSCSI RFCs etc.?
> 
> Yes. All enterprise targets support features like this.
> You implement access control down on the LUN level, not on the target level.

Actually, there are enterprise iSCSI target systems don't support lun
masking.

FC uses lun masking. Generally if you buy an iSCSI target system from
a company also sell FC systems, probably it supports lun masking.


> With this and when you have multiple targets on a single host you may
> also want some changes we may need later.
> 
> Example :
> Sometimes you want to create one dedicated target for each initiator.
> On each target you create a few LUNs and you set up the ACLs for that
> LUN that only that particular initiator can access it.
> Some people want to set their systems up like this.
> 
> You would then end up with 100 targets, behind which there are a few LUNs.
> For one particular Initiator, lets call it host Foo, which runs Linux.
> 
> When we connect to the target to do discovery, Foo would see 100
> different targets, but there would only be one single target behind
> which there would be a LUN.
> 99 of the targets would report that there were no luns at all when the
> initiator does a REPORT LUNS.

Well, I think that if configure stgt to deny an initiator to access to
some targets, stgt also doesn't tell the initiator about these targets
in discovery. So the initiator don't see 99 targets.


In general, I think that iSCSI people don't use lun masking and they
use multiple targets.
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html