[stgt] [PATCH] iscsi: target redirect support
sekharan at us.ibm.com
Tue Jun 15 21:13:32 CEST 2010
On Tue, 2010-06-15 at 11:53 +0900, FUJITA Tomonori wrote:
> On Mon, 14 Jun 2010 18:13:53 -0700
> Chandra Seetharaman <sekharan at us.ibm.com> wrote:
> > Hi Tomo,
> > I tested with two tgtds one the redirector tgtd and the other, serving
> > tgtd. Hope this is the model you intended. (Let me know if otherwise).
> > I tried two different things, and both of them worked as expected.
> > 1. Ran the redirector tgtd and the serving tgtd in a same node listening
> > to different portal.
> Sorry, I'm not sure what you did. I suspect that you run two tgtd
> daemons on the single node?
> Can you tell me the exact commands that you run?
# start the server
/tmp/tgtd -d 10 -f -C 1 --iscsi portal=10.0.2.51:860
# Associate the targets with the serving tgtd
tgt-admin -C 1 -e -c /home/chandra/targets.conf
# "show" of -C 1 shows all the luns defined in targets.conf
# start the redirector
/tmp/tgtd -d 10 -f -C 2 --iscsi portal=10.0.0.51
# Associate the targets with the redirector tgtd
tgt-admin -C 2 -e -c /home/chandra/targets.conf
# "show" of -C 2 shows the targets but _no_ luns
# Run the redirector commands to redirect both the targets.
tgtadm -C 2 --op update --mode target --tid 1 --name RedirectAddress --value 10.0.2.51
tgtadm -C 2 --op update --mode target --tid 1 --name RedirectPort --value 860
tgtadm -C 2 --op update --mode target --tid 1 --name RedirectReason --value Temporary
tgtadm -C 2 --op update --mode target --tid 2 --name RedirectAddress --value 10.0.2.51
tgtadm -C 2 --op update --mode target --tid 2 --name RedirectPort --value 860
tgtadm -C 2 --op update --mode target --tid 2 --name RedirectReason --value Temporary
# From the initiator side, run discovery and login to the redirector.
iscsiadm -m discovery -t st -p 10.0.0.51 -I virbr1
iscsiadm -m node -p 10.0.0.51 -l -I virbr1
#lsscsi shows the targets and luns at the initiator.
[0:0:0:0] disk IBM-ESXS MAY2073RC T107 -
[0:0:1:0] disk IBM-ESXS MAY2073RC T107 -
[0:1:0:0] disk LSILOGIC Logical Volume 3000 /dev/sda
[50:0:0:0] storage IET Controller 0001 -
[50:0:0:1] disk cluster1 target1 0001 /dev/sdb
[51:0:0:0] storage IET Controller 0001 -
[51:0:0:1] disk cluster2 target1 0001 /dev/sdc
> > 2. Ran the redirector tgtd on one node and the service tgtd on another.
> Sorry, again. I'm not sure what 'Ran the redirector tgtd on one node'
> means. I guess that you run tgtd daemons on the two nodes.
yes, same commands as above but serving tgtd on one node and redirector
tgtd on another.
> > In case one, I have to first start the serving tgtd first in order for
> > it to grab the luns the target is supposed to serve (or modify the
> > targets.conf file to not have luns in them). If I used the same
> > targets.conf file and changed the order, the serving tgtd doesn't get
> > the access to the backing store, which is not correct.
> Why tgtd doesn't get the access? That's your targets.conf problem,
> isn't it? targets.conf for the first tgtd daemon can have a target
> without lun (except for lun0).
> I also think that tgtd doesn't lock backing files so two daemons can
> open the same backing file.
aah.. Running tgt-admin with "-p" shows that tgt-admin prevents creation
of lun if the backing store is being used.
Ran tgtadm directly and it _does_ create the lun under the redirector
> > In effect, (1) I think we need to be able to mark the redirector tgtd as
> > such (with an option in the command line or such),
> I'm not sure why we need this since sounds like you can avoid the
> issue with a proper targets.conf.
Looks like using the targets.conf file itself avoids the problem...
having a separate "designated" redirector would allow
- to have single node to which the initiators always connect
- to run the "redirector" in a node which doesn't actually have the
- avoid unnecessary creation of the threads for the luns (with 1 lun in
both of my targets, i see 10 more threads og tgtd).
- Have the redirector definition in targets.conf itself (which would
mostly be the case ?!)
What do you think ?
> btw, I think that we need to modify the redirect configuration on the
> fly so I avoided the command line.
I see that as a plus, but in a deployed environment won't the user want
to have these in a static place, like targets.conf ?
> > --
> > To unsubscribe from this list: send the line "unsubscribe stgt" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> To unsubscribe from this list: send the line "unsubscribe stgt" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the stgt