ctld(8), multiple 'portal-group' on same socket (individual 'discovery-auth-group' restrictions)

[Harald Schmalzbauer]

 Bezüglich Edward Tomasz Napierała's Nachricht vom 21.10.2014 12:43
(localtime):
> On 1020T1035, Harald Schmalzbauer wrote:
>>  Hello,
>>
>> I'm trying to move from istgt(1) to ctld(8), but it seems my setup isn't
>> possible with ctld.
>> Besides missing support for virtual-DVDs ('UnitType DVD' in istgt) and
>> real ODD-devices ('UnitType pass' in istgt),
> Yup, we don't implement virtual DVDs and passthrough.  Especially the
> latter would be a nice feature to have.
>
>> I guess it's impossible to
>> define multiple "portal-group"s, listening on the same socket, but with
>> different "discovery-auth-group".
>> The idea is, to present initiators only targets at discovery, which they
>> are allowed to connect to.
>> Am I missing something which could provide such selective discovery with
>> ctld(8)?
> I thought about it, but I don't like the way istgt does it.  By allowing
> multiple portal groups to bind to a single address (portal), we would
> introduce ambiguity as for which portal-group and associated
> discovery-auth-group is being used.  On the other hand, a simplistic
> approach of only showing targets with auth-group being the same
> as discovery-auth-group for the portal probably wouldn't be very useful
> in real-world cases.

Thanks a lot for your attention and the highly appreciated work on ctl[d]*!

In my "real world" case, I dispense backup disks to win7 clients via iSCSI.
I liked the possibility to limit target-discovery-results, because
curious people, garnated such extra resources, weren't able to see who
else was granted this extra resource (by definition, there's no private
data on the clients which use that backup-strategy, so no need for
qualified identity checks or encryption needed). Even with any security
mechanisms active, two consumers (some dozen in my case) of the same
portal know about the other. That's one example where this feature was
useful for me.
Another one actually is (since not implemented in ctld, yet?) with
virtual DVDs. If you provide 50 DVDs at one portal, it's confusing if
any initiator needs to select from the complete list.

I'd like to point to two options I'm missing:
option RPM
option FormFactor
And another one I don't know/understand:
option scsiname

Missing resp. wrong reported option RPM leads to identification as SSD
with ESXi initiators. I don't remember what defines a SSD vs. HDD, I
think it was a threshold of something about 400? Or was it 0? I think I
read the former… Don't have docs handy.
The FormFactor was more cosmetic, but in bigger environments I guess it
can be useful if you have multiple targets available, choosing the
better fitting backend-pool e.g.

If someone could point me to the meaning of option iscsiname?

Thanks a lot,

-Harry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20141021/117a0589/attachment.sig>