On Tue, 2010-06-15 at 11:53 +0900, FUJITA Tomonori wrote: > On Mon, 14 Jun 2010 18:13:53 -0700 > Chandra Seetharaman <sekharan@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx > > 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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
