On Sun, Apr 17, 2011 at 10:59 AM, FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote: > On Sun, 17 Apr 2011 10:24:01 +1000 > ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote: > >> This would allow to add and remove portals from tgtd at runtime >> without the need for shutting down and restarting tgtd any time >> the portal configuration changes. > > Sounds good. > > >> To operate on portals, I added a new mode to tgtadm/tgt : >> >> Example use: >> >> $ sudo ./usr/tgtadm --lld iscsi --op show --mode portal >> Portal: 0.0.0.0:3260 >> Portal: [0::0]:3260 > > Can we handle portal group? tgt doesn't support it but the interface > needs to handle it, I think. Ok. I can add setting a portal group tag for each portal, and have it default to ptgt 1 by default. That would need some additional changes in the discovery and login processing, but that should not be too painful. The biggest question would be of the syntax and how to specify it. The most natural way to specify the tpgt would be using ',<tpgt>' Like : tgtd --iscsi portal=10.1.1.27:3260,1 But ',' is already taken for specifying --iscsi portal=10.1.1.27:3260,portal=10.1.1.28:3261 or if other iscsi parameters will be added later. I like being able to specify multiple comma-separated portals using ike that, and also comma-separated other arguments that may be added in the future. But I would also like to retain using ',<tpgt>' since that seems to be the de-facto way to show / describe target portal group tags. Picking a different character as the tpgt would solve the issue but be non-intuitive. Would you be ok with the syntax like this ? portal=<address>[:<port>][,<tpgt>] Example: --iscsi portal=10.1.1.27:3260 --iscsi portal=10.1.1.27:3260,2 --iscsi portal=10.1.1.27:3260,2,portal=1.1.27:3262,3 --iscsi portal=10.1.1.27:3260,portal=1.1.27:3262,3 In this case ',' is sometimes a argument separator and sometimes a tpgt separator. Not optimal but I could live with this syntax. Are you ok with this syntax or would you prefer a different syntax? > > And how can we see the binding of a target and portals I would like to do that part later, once the add/remove portals is finished and merged first. But with TPGT support I could imagine it could be something like * each target is assigned to one single tpgt * default is that a target is bound to tgpt:1 but a new tgtadm command could be used to change it * discovery and login support are enhanced to only allow and filter based on the tpgt bound to that target. * discovery checks the portal that the discovery session is bound to and uses this to find which tpgt this portal belongs to this is used to filter the list of returned targets. I.e. if you connected to a portal in tpgt:5 you will only discover targets that belong to that same tpgt. Other targets on other portal groups are not shown. * During login, find which portal group the session connected to and verify that the requested target belongs to that group. Fail the login otherwise. But lets do the portal groups/targets/... things later once we have the ability to add / delete portals first. regards ronnie sahlberg -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
