Date: Tue, 21 Oct 2014 15:45:16 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= <trasz@FreeBSD.org> To: Harald Schmalzbauer <h.schmalzbauer@omnilan.de> Cc: FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: ctld(8), multiple 'portal-group' on same socket (individual 'discovery-auth-group' restrictions) Message-ID: <20141021134516.GA89872@brick.home> In-Reply-To: <54464405.4090207@omnilan.de> References: <5444C94C.4050705@omnilan.de> <20141021104308.GA5990@brick.home> <54464405.4090207@omnilan.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1021T1331, Harald Schmalzbauer wrote: > 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]*! Thanks :-) > 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. So basically, each target has a different user/password pair, and during discovery the target only returns those targets that can actually be accessed using that user/password? > 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. In this case do the returned targets depend on authentication, or something else, eg. a static list defined in config? > 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. Hm, ok. > If someone could point me to the meaning of option iscsiname? That's an istgt option, right?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141021134516.GA89872>