[stgt] tgt-admin and a -C, --control-port argument

[Chandra Seetharaman]

On Tue, 2010-04-06 at 11:45 +0900, FUJITA Tomonori wrote:
> On Mon, 05 Apr 2010 19:15:47 -0700
> Chandra Seetharaman <sekharan at us.ibm.com> wrote:
> 
> > 
> > On Sun, 2010-04-04 at 16:49 +0900, FUJITA Tomonori wrote:
> > > On Sat, 3 Apr 2010 08:16:29 +1100
> > > ronnie sahlberg <ronniesahlberg at gmail.com> wrote:
> > > 
> > > > What I think Chandra is asking about is if we plan to or want to make
> > > > tgtd listen on several addresses at once.
> > > > Right now tgtd can listen on one address, or on all addresses.
> > > > 
> > > > Listening on several addresses I guess would look something like this
> > > > for iscsi :
> > > >  --iscsi portal=192.0.2.1:3260,198.51.100.1:3260
> > > >
> > > > Making tgtd listen on two addresses.
> > > 
> > > I'm still not sure what he is asking but the above is fine by me.
> > > When we discussed 'portal' option, I think that we agreed the above
> > > option.
> > 
> > Consider the scenario where I have 8 ip addresses that are in different
> > subnets with 4 ip address in both subnets, and I want to export 4
> > targets in one subnet and another 4 targets in the other subnet.
> > 
> > The feature about is required to provide that kind of service.
> 
> Can you live in most of situations if you run tgtd on all addresses
> then you configure ACL on each targets?
> 
> For example, with the following command, only initiators on
> 198.51.100.0/24 can discover and connect to #1 target.
> 
> host:~/tgt# ./usr/tgtadm --lld iscsi --op bind --mode target --tid 1 -I 198.51.100.0/24

Here is the actual problem I hit with using single tgtd and with ACL. 
(simplified for easy digestion :)

Have a cluster that serves two ip addresses: 10.0.0.51 and 10.0.2.52
and there is one target associated with each ip address target_51 and
target_52. target_51 10.0.0.1 and target_52 is available from 10.0.2.1.

When I started both ip addresses were served by cluster node node1.

>From the initiator, I did 

# iscsiadm -m discovery -t st -p 10.0.0.51 -I virbr2
# iscsiadm -m discovery -t st -p 10.0.2.52 -I virbr2
# iscsiadm -m node -p 10.0.0.51 -I virbr2 -l
# iscsiadm -m node -p 10.0.2.52 -I virbr2 -l

Note that this is in error that I used virbr2 (which is actually
10.0.1.1 :-)

I had both the targets connected and I could do my IOs all good.

Then some cluster event happened and 10.0.2.52 moved to the cluster node
node2. 

Cluster scripts in node1, released the ip address 10.0.2.52 (so it
stopped serving target_52), and node2 took over the address (so, it
started a new tgtd and started serving target_52).

Initiator saw both of the targets go away, saw target_51 come back and
never saw target_52 come back.

----------------

With tgtd serving dedicated ip address, I tried the exact same thing
(including connecting thru virbr2, which also connects), but at the end
target_52 connects back to the initiator (after the ip address moves to
the node2)



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