Re: Obtaining initiator hex address for srpt acls, not /sys/class/infiniband/mlx4_0/ports/1/gids/0

[james harvey]

After more digging, I found out this out of no where hex string is
referred to as "initiator_ext", and is being sent since srp_daemon.sh
give srp_daemon the "-n" flag.  Since there's no user-set
initiator_ext, srp_daemon grabs it from somewhere.

If I want to continue using the "-n" flag, how can I find out what my
initiator is going to send as initiator_ext, so the target can be set
up to work with it?

Or, can I set my own initiator_ext, it looks by appending it to
/etc/srp_daemon.conf ?

Why doesn't ibsrpdm give the initiator_ext value?

On Wed, Jan 6, 2016 at 3:07 AM, james harvey  wrote:
> I think:
>
> TL;DR - I can find my initiator's guid, but targetcli doesn't work
> with that in acls.  I have to give it the i_port_id to work.  How do I
> find the i_port_id, other than having a failed connection attempt and
> looking at dmesg?
>
> On Wed, Jan 6, 2016 at 3:02 AM, james harvey  wrote:
>> I'm at a loss on how to get the hex address to go underneath acls when
>> setting up srpt.  If I use the fe80 prefix I see everywhere including
>> /sys, it gets rejected.  If I use the prefix shown in the kernel
>> rejection method, which I can't find anywhere else, it works fine.
>>
>> I am using targetcli, but I don't think this is a targetcli issue,
>> because it's the kernel showing in dmesg the bizzare prefix that I
>> can't figure out where it's coming from.
>>
>> Was linux 4.2.5 (-1 Arch) on both machines.  Target upgraded to 4.3.2
>> (-2 Arch) with no change.  Been acting like this for months, since I
>> started with InfiniBand.
>>
>> Just upgraded from ConnectX to ConnectX-2 cards, and seeing the same 
>> behavior.
>>
>> targetcli configuration:
>>
>> /> ls
>> o- / 
>> .
>> [...]
>>   o- backstores
>> ..
>> [...]
>>   | o- block 
>> ..
>> [Storage Objects: 3]
>>   | | o- kvm1 
>> 
>> [/dev/disk1/kvm1 (100.0GiB) write-thru activated]
>>   | | o- kvm2 
>> 
>> [/dev/disk2/kvm2 (100.0GiB) write-thru activated]
>>   | | o- kvm3 
>> 
>> [/dev/disk3/kvm3 (100.0GiB) write-thru activated]
>>   | o- fileio 
>> .
>> [Storage Objects: 0]
>>   | o- pscsi 
>> ..
>> [Storage Objects: 0]
>>   | o- ramdisk 
>> 
>> [Storage Objects: 0]
>>   o- iscsi 
>> 
>> [Targets: 0]
>>   o- loopback 
>> .
>> [Targets: 0]
>>   o- sbp 
>> ..
>> [Targets: 0]
>>   o- srpt 
>> .
>> [Targets: 1]
>>   | o- ib.fe82c9031679
>> ...
>> [no-gen-acls]
>>   |   o- acls 
>> 
>> [ACLs: 1]
>>   |   | o- ib.fe82c9031e79
>> 
>> [Mapped LUNs: 3]
>>   |   |   o- mapped_lun0
>> 
>> [lun0 block/kvm1 (rw)]
>>   |   |   o- mapped_lun1
>> 
>> [lun1 block/kvm2 (rw)]
>>   |   |   o- mapped_lun2
>> 
>> [lun2 block/kvm3 (rw)]
>>   |   o- luns 
>> 
>> [LUNs: 3]
>>   | o- lun0
>> .
>> [block/kvm1 (/dev/disk1/kvm1)]
>>   | o- lun1
>> .
>> [block/kvm2 (/dev/disk2/kvm2)]
>>   | o- lun2
>> .
>> [block/kvm3 

Obtaining initiator hex address for srpt acls, not /sys/class/infiniband/mlx4_0/ports/1/gids/0

[james harvey]

I'm at a loss on how to get the hex address to go underneath acls when
setting up srpt.  If I use the fe80 prefix I see everywhere including
/sys, it gets rejected.  If I use the prefix shown in the kernel
rejection method, which I can't find anywhere else, it works fine.

I am using targetcli, but I don't think this is a targetcli issue,
because it's the kernel showing in dmesg the bizzare prefix that I
can't figure out where it's coming from.

Was linux 4.2.5 (-1 Arch) on both machines.  Target upgraded to 4.3.2
(-2 Arch) with no change.  Been acting like this for months, since I
started with InfiniBand.

Just upgraded from ConnectX to ConnectX-2 cards, and seeing the same behavior.

targetcli configuration:

/> ls
o- / 
.
[...]
  o- backstores
..
[...]
  | o- block 
..
[Storage Objects: 3]
  | | o- kvm1 

[/dev/disk1/kvm1 (100.0GiB) write-thru activated]
  | | o- kvm2 

[/dev/disk2/kvm2 (100.0GiB) write-thru activated]
  | | o- kvm3 

[/dev/disk3/kvm3 (100.0GiB) write-thru activated]
  | o- fileio 
.
[Storage Objects: 0]
  | o- pscsi 
..
[Storage Objects: 0]
  | o- ramdisk 

[Storage Objects: 0]
  o- iscsi 

[Targets: 0]
  o- loopback 
.
[Targets: 0]
  o- sbp 
..
[Targets: 0]
  o- srpt 
.
[Targets: 1]
  | o- ib.fe82c9031679
...
[no-gen-acls]
  |   o- acls 

[ACLs: 1]
  |   | o- ib.fe82c9031e79

[Mapped LUNs: 3]
  |   |   o- mapped_lun0

[lun0 block/kvm1 (rw)]
  |   |   o- mapped_lun1

[lun1 block/kvm2 (rw)]
  |   |   o- mapped_lun2

[lun2 block/kvm3 (rw)]
  |   o- luns 

[LUNs: 3]
  | o- lun0
.
[block/kvm1 (/dev/disk1/kvm1)]
  | o- lun1
.
[block/kvm2 (/dev/disk2/kvm2)]
  | o- lun2
.
[block/kvm3 (/dev/disk3/kvm3)]
  o- vhost 

[Targets: 0]
  o- xen_pvscsi
...
[Targets: 0]

NOTE my InfiniBand cards have similar IDs, and only differ by one
character -- compare the end, 1679 vs 1e79.

On the target (host):
$ cat /sys/class/infiniband/mlx4_0/ports/1/gids/0
fe80::::0002:c903::1679
{It's my understanding this should be used underneath srpt, as the wwn}

On the initiator (client):
$ cat /sys/class/infiniband/mlx4_0/ports/1/gids/0
fe80::::0002:c903::1e79
{It's my understanding this should be used underneath acls, and mapped
with the luns}
# ibsrpdm -c
id_ext=0002c9031678,ioc_guid=0002c9031678,dgid=fe82c9031679,pkey=,service_id=0002c9031678
{so, its /etc/srp_daemon.conf is just comments and the line}
a 
id_ext=0002c9031678,ioc_guid=0002c9031678,dgid=fe82c9031679,pkey=,service_id=0002c9031678

But, after starting service target on the target, and service
srpdaemon on the initiator, dmesg on