Hello Nab,
> Ok, good. Just making sure the objective for the first patch series
> is mutually understood. ;)
yes, let me know if you want to have anything else cleaned up. I
consider it ready for upstream.
> Mmm, so far I've avoided NodeACLs based on IP address entirely, so
> adding this specifically for in-band sendtargets discovery is something
> that I'd rather avoid.
> Coding this up for your internal use is fine, but it's most likely
> something that I'll not be merging.
I assumed so.
> > Do you have an alternative? I have the following scenario:
> > I have 10 VLANs. They're seperated by a firewall so that one VLAN can
> > not access the other VLAN. Each VLAN has 12 ESX Servers in it. I have one storage.
> > This storage is used by all 10 VLANs. On the storage I have two IPs in
> > every VLAN. I want to be able to provide 'LUNs which can only be
> > accessed by the ESX server' and I want LUNs which can be accessed by
> > everyone in the VLAN not taking the iqn into account. Before PATCH-v3
> > all LUNs were discovered which LED to many unsucessfull logins and long
> > reboot times, because the ESX initiators tried to log in into every
> > single target. With PATCH-v3 this is now much better, but the ESX still
> > try to login to all demo mode LUNs, two they can reach all other fail
> > because they do not reach them over layer 3 because of the firewall.
> OK, this exactly what explicit NodeACLs are intended for, and given how
> the PATCH-v3 demo_mode_discovery logic now works, correctly hides
> TargetNames from Initiators who don't have an explicit NodeACL set.
The thing is the following: This is a lab environment. So people might
play with the initiator iqn. If they do so they would loose access to
the storage. I don't want that because I want to make it as seamless
for the user as possible, so that really is not an option for me. About
the three private LUNs with NodeACLs: They're only needed for two labs,
so I don't care that much about this. But making the shared storage
unavailable because someone screwed up the iqn of the initiator, would
be a no go. However I see your point. You consider that broken and I
think we had that discussion a while back ago. So maybe I'll make
something ready and use it and post it here. If you like it or someone
else, he can pick it up, otherwise, git makes it easy to do vendor
tracking while maintaing a private patch or two. I do the same for
screen, mutt, you name it. :-)
I really like the current tip. If you want me to stress test anything
else let me know. It is shame that I currently don't have FC or 10 GBit.
I would like to try the FCOE and FC code as well.
Cheers,
Thomas
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
