[stgt] [PATCH] iscsi: target redirect support

[Chandra Seetharaman]

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?

yes
> 
> 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.
lsscsi
[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
tgtd. 
> 
> 
> > 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...
but...

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 
   backing store
 - 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