Hi, Got a possibly odd question. I'm pretty sure the iSCSI target doesn't support this but wondered if it was something that could be considered for future. We've been trying to use the target to emulate a customer environment that we do not have direct access to. They have a SAN which has a fairly complex configuration. There are two array controllers, each with its own IQN, each controller then has two TPGs each of which has three portal addresses. So far this is all OK and we can emulate that with a software target. Where it becomes difficult is when we look at the responses from discovery. Each group of three portal addresses will only return itself and the other two siblings, it will not return the details of the portals on the other tpg or those for the other array controller. Our control plane software should work in this scenario but our customer found a bug meaning it did not in all circumstances function correctly. As part of producing a fix it would be preferable if we could also create a regression test for this scenario to ensure that after it is fixed it doesn't get broken again and without requiring capital expense to purchase a representative SAN. Whilst the software target can be configured with multiple IQNs and multiple tpgs and with multiple portals for each tpg when performing discovery to any one of those portals will respond with the details of all of the other portals and thus will not trigger the bug that we have seen. This is a little bit similar to https://target-devel.vger.kernel.narkive.com/SyrmxKHS/lio-per-initiator-target-discovery-question, but in our case we would be satisfying the ACL when contacting each of the portal addresses so it's only the cross tpg discovery exposure that we would want to disable. Is this something that would be considered or is it just too specific to a small use case? Thanks, Mark.
