Hello Nab,
> Ok, I'm now getting more confused as to what your trying to accomplish
> with these patches.
> The original discussion was to restrict SendTargets discovery
> information for specific TargetName+TargetPortalGroupTag endpoints,
> based upon how the endpoint was configured using TPG attributes.
> Thus far it has included the following criteria:
> - If demo-mode (generate_node_acls=1) is enabled on the TargetName+TargetPortalGroup
> endpoint, always return TargetName regardless of other settings
> - If demo-mode (generate_node_acls=0) is disabled, only return TargetName if NodeACL
> exists that matches the InitiatorName for the discovery session.
> So from what I can tell the changes in your PATCH-v3 achieve these
> points.
I agree with the above. The PATCH-v3 accomplishes that and works
perfectly fine for me. I run it on top of everything else that you have
sent me and I'll report back by the end of the week when I have finished
my class.
(node-62) [~/work/linux-2.6] git shortlog remotes/nab/queue..HEAD
Nicholas Bellinger (6):
iscsi-target: Only perform wait_for_tasks when performing shutdown
iscsi-target: Perform release of acknowledged tags from RX context
iscsi-target; Allow an extra tag_num / 2 number of percpu_ida tags
target: Make target_do_xcopy failures return INVALID_PARAMETER_LIST
target: Allow non zero ListID in EXTENDED_COPY parameter list
target: Reject EXTENDED_COPY when emulate_3pc is disabled
Thomas Glanzmann (3):
iscsi-target: Add new TPG attribute demo_mode_discovery
target: Export symbol core_tpg_check_initiator_node_acl
iscsi-target: Implement demo_mode_discovery logic
Linux node-62 3.12.0-rc3+ #1 SMP Tue Oct 8 22:32:58 CEST 2013 x86_64 GNU/Linux
> Where I'm getting confused is where portals and subnets are now involved
> in the discussion. The above criteria will not restrict SendTargets
> discovery based on which portal the initiator is connecting to, but only
> restricts SendTargets discovery based upon how each of the endpoints are
> configured.
While I was working on the patch, I noticed, that I wanted more: I also
wanted to not expose demo mode luns from other portals. This is
currently a pending task since I have not accomplished that yet. As I
see it I have two options here:
- Drop the demo mode and set explicit access permissions (I
don't want that)
- Write a patch that only returns targets which are bound to the
portal
> Eg: The initiator will always see the same restricted set of SendTargets
> discovery information based on the above criteria, regardless of which
> network portal it's actually connecting to.
I can confirm that. Would you be willing to take a patch that changes
that or do you consider it fundamentally broken?
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.
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
