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

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.fe800000000000000002c90300001679
...........................................................................
[no-gen-acls]
  |   o- acls ............................................................................................................
[ACLs: 1]
  |   | o- ib.fe800000000000000002c90300001e79
....................................................................
[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:0000:0000:0000:0002:c903:0000: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:0000:0000:0000:0002:c903:0000:1e79
{It's my understanding this should be used underneath acls, and mapped
with the luns}
# ibsrpdm -c
id_ext=0002c90300001678,ioc_guid=0002c90300001678,dgid=fe800000000000000002c90300001679,pkey=ffff,service_id=0002c90300001678
{so, its /etc/srp_daemon.conf is just comments and the line}
a id_ext=0002c90300001678,ioc_guid=0002c90300001678,dgid=fe800000000000000002c90300001679,pkey=ffff,service_id=0002c90300001678

But, after starting service target on the target, and service
srpdaemon on the initiator, dmesg on target shows:
[  849.710278] ib_srpt Received SRP_LOGIN_REQ with i_port_id
0x7916000003c90200:0x2c90300001e79, t_port_id
0x2c90300001678:0x2c90300001678 and it_iu_len 260 on port 1
(guid=0xfe80000000000000:0x2c90300001679)
[  849.714528] ib_srpt Session : kernel thread ib_srpt_compl (PID 24481) started
[  849.714601] ib_srpt Rejected login because no ACL has been
configured yet for initiator 0x7916000003c902000002c90300001e79.
[  849.714613] ib_srpt Session 0x7916000003c902000002c90300001e79:
kernel thread ib_srpt_compl (PID 24481) stopped

And, dmesg on initiator shows:
[  976.616221] scsi host11: ib_srp: REJ received
[  976.616229] scsi host11: ib_srp: SRP LOGIN from
fe80:0000:0000:0000:0002:c903:0000:1e79 to
fe80:0000:0000:0000:0002:c903:0000:1679 REJECTED, reason 0x00010001
[  976.616269] scsi host11: ib_srp: Connection 0/4 failed
[  976.616276] scsi host11: ib_srp: Sending CM DREQ failed

Why is the target machine, in the srp context only, seeing the ports
as starting with 0x7916000003c90200 and 0x2c90300001678, and the
client machine seeing the ports as starting with fe80:0000:0000:0000?
What are these 0x7916... and 0x2c90... prefixes, and how can I find
them besides getting a rejection and looking at the kernel logs?  I
haven't seen these prefixes anywhere else on either system.

In targetcli, if I use acls with 0x7916000003c902000002c90300001e79,
then everything works great.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[james harvey]

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 <jamespharvey20-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.fe800000000000000002c90300001679
> ...........................................................................
> [no-gen-acls]
>   |   o- acls ............................................................................................................
> [ACLs: 1]
>   |   | o- ib.fe800000000000000002c90300001e79
> ....................................................................
> [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:0000:0000:0000:0002:c903:0000: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:0000:0000:0000:0002:c903:0000:1e79
> {It's my understanding this should be used underneath acls, and mapped
> with the luns}
> # ibsrpdm -c
> id_ext=0002c90300001678,ioc_guid=0002c90300001678,dgid=fe800000000000000002c90300001679,pkey=ffff,service_id=0002c90300001678
> {so, its /etc/srp_daemon.conf is just comments and the line}
> a id_ext=0002c90300001678,ioc_guid=0002c90300001678,dgid=fe800000000000000002c90300001679,pkey=ffff,service_id=0002c90300001678
>
> But, after starting service target on the target, and service
> srpdaemon on the initiator, dmesg on target shows:
> [  849.710278] ib_srpt Received SRP_LOGIN_REQ with i_port_id
> 0x7916000003c90200:0x2c90300001e79, t_port_id
> 0x2c90300001678:0x2c90300001678 and it_iu_len 260 on port 1
> (guid=0xfe80000000000000:0x2c90300001679)
> [  849.714528] ib_srpt Session : kernel thread ib_srpt_compl (PID 24481) started
> [  849.714601] ib_srpt Rejected login because no ACL has been
> configured yet for initiator 0x7916000003c902000002c90300001e79.
> [  849.714613] ib_srpt Session 0x7916000003c902000002c90300001e79:
> kernel thread ib_srpt_compl (PID 24481) stopped
>
> And, dmesg on initiator shows:
> [  976.616221] scsi host11: ib_srp: REJ received
> [  976.616229] scsi host11: ib_srp: SRP LOGIN from
> fe80:0000:0000:0000:0002:c903:0000:1e79 to
> fe80:0000:0000:0000:0002:c903:0000:1679 REJECTED, reason 0x00010001
> [  976.616269] scsi host11: ib_srp: Connection 0/4 failed
> [  976.616276] scsi host11: ib_srp: Sending CM DREQ failed
>
> Why is the target machine, in the srp context only, seeing the ports
> as starting with 0x7916000003c90200 and 0x2c90300001678, and the
> client machine seeing the ports as starting with fe80:0000:0000:0000?
> What are these 0x7916... and 0x2c90... prefixes, and how can I find
> them besides getting a rejection and looking at the kernel logs?  I
> haven't seen these prefixes anywhere else on either system.
>
> In targetcli, if I use acls with 0x7916000003c902000002c90300001e79,
> then everything works great.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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 <jamespharvey20-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 <jamespharvey20-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.fe800000000000000002c90300001679
>> ...........................................................................
>> [no-gen-acls]
>>   |   o- acls ............................................................................................................
>> [ACLs: 1]
>>   |   | o- ib.fe800000000000000002c90300001e79
>> ....................................................................
>> [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:0000:0000:0000:0002:c903:0000: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:0000:0000:0000:0002:c903:0000:1e79
>> {It's my understanding this should be used underneath acls, and mapped
>> with the luns}
>> # ibsrpdm -c
>> id_ext=0002c90300001678,ioc_guid=0002c90300001678,dgid=fe800000000000000002c90300001679,pkey=ffff,service_id=0002c90300001678
>> {so, its /etc/srp_daemon.conf is just comments and the line}
>> a id_ext=0002c90300001678,ioc_guid=0002c90300001678,dgid=fe800000000000000002c90300001679,pkey=ffff,service_id=0002c90300001678
>>
>> But, after starting service target on the target, and service
>> srpdaemon on the initiator, dmesg on target shows:
>> [  849.710278] ib_srpt Received SRP_LOGIN_REQ with i_port_id
>> 0x7916000003c90200:0x2c90300001e79, t_port_id
>> 0x2c90300001678:0x2c90300001678 and it_iu_len 260 on port 1
>> (guid=0xfe80000000000000:0x2c90300001679)
>> [  849.714528] ib_srpt Session : kernel thread ib_srpt_compl (PID 24481) started
>> [  849.714601] ib_srpt Rejected login because no ACL has been
>> configured yet for initiator 0x7916000003c902000002c90300001e79.
>> [  849.714613] ib_srpt Session 0x7916000003c902000002c90300001e79:
>> kernel thread ib_srpt_compl (PID 24481) stopped
>>
>> And, dmesg on initiator shows:
>> [  976.616221] scsi host11: ib_srp: REJ received
>> [  976.616229] scsi host11: ib_srp: SRP LOGIN from
>> fe80:0000:0000:0000:0002:c903:0000:1e79 to
>> fe80:0000:0000:0000:0002:c903:0000:1679 REJECTED, reason 0x00010001
>> [  976.616269] scsi host11: ib_srp: Connection 0/4 failed
>> [  976.616276] scsi host11: ib_srp: Sending CM DREQ failed
>>
>> Why is the target machine, in the srp context only, seeing the ports
>> as starting with 0x7916000003c90200 and 0x2c90300001678, and the
>> client machine seeing the ports as starting with fe80:0000:0000:0000?
>> What are these 0x7916... and 0x2c90... prefixes, and how can I find
>> them besides getting a rejection and looking at the kernel logs?  I
>> haven't seen these prefixes anywhere else on either system.
>>
>> In targetcli, if I use acls with 0x7916000003c902000002c90300001e79,
>> then everything works great.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 6287 bytes --]

On 01/06/2016 04:05 AM, james harvey wrote:
> 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?

As I recall, the value you will get here varies based upon the
hardware/driver in use.  On some cards, you get the local GID reversed,
on other cards you get something else.  What I ended up doing when
setting up the ACLs for srp was to do this:

# ssh to srp target to add an ACL for this client
# targetcli uses srp names of the format:
# "ib.<32 hex chars>"
# for both target wwn and client wwn.
__setup_srp_client_path() {
        local server="$1"
        local fabric="$2"
        local path_num="$3"
        local dgid=${SRP_DGID[$server-$fabric]}
        local var_file=/etc/rdma/srp_client_variables
        local tmp_conf=/etc/rdma/srp_client_tmp_conf
        local conf_file=/etc/srp_daemon.conf
        echo -e "a pkey=ffff,dgid=$dgid\nd\n" > $tmp_conf
        pushd /dev/infiniband
        for umad in umad*; do
                srp_daemon -n -c -o -f $tmp_conf -d ./$umad | sed -e
'y/,/\n/' > $var_file
                [ -s $var_file ] && break
        done
        local ibdev=`cat /sys/class/infiniband_mad/$umad/ibdev`
        local ibport=`cat /sys/class/infiniband_mad/$umad/port`
        rm $tmp_conf
        popd
        [ ! -s $var_file ] && return
        port_guid=`ibstat $ibdev $ibport | grep "Port GUID" | cut -f 2
-d 'x'`
        init_ext=`grep initiator_ext $var_file | cut -f 2 -d '='`
        sgid="${init_ext}${port_guid}"
        # assuming targetcli global pref auto_add_mapped_luns=true (the
default)
        # just creating the acl should map existing target luns to this
client.
        # We have auto mapped luns turned off, so we also map our
specific lun
        # to our ACL
        ssh $server "targetcli /srpt/ib.$dgid/acls create ib.$sgid;
targetcli /srpt/ib.$dgid/acls/ib.$sgid create 0
/backstores/block/srp-$host_part; targetcli saveconfig"
        sed -e "/.*dgid=$dgid.*/ d" -i $conf_file
        echo "a pkey=ffff,dgid=$dgid,queue_size=128,max_cmd_per_lun=128"
>> $conf_file
        rm $var_file
        if [ $path_num -eq 0 ]; then
                mkdir -p /srv/$server/SRP
        fi
}

# Call this to set up possible SRP device definitions.
# @1 - Server name to create logins too
# @2+ - List of fabrics to access devices via, or empty for all possible
#
# If there is more than one path to the device, we automatically use
# lvm multipath to access the device.
#
# Once paths/logins are established, create a mount point on the system,
# add the device to the fstab, create an fs on the device, but don't
# mount the device
Setup_Srp_Client_Mounts() {
        if [ -z "$1" ]; then
                echo "Usage: "
                echo -e "\tSetup_Srp_Client_Mounts <server> [fabrics ...]"
                echo -e "\t\tserver - Required, we will ssh to this
server to"
                echo -e "\t\t  add ourselves to the ACLs and map our LUN"
                echo -e "\t\tfabric - One or more fabrics you wish to
enable"
                echo -e "\t\t  access to the LUN via.  The fabrics will be"
                echo -e "\t\t  checked to make sure that both the server
and"
                echo -e "\t\t  this host have connections to the
fabrics.  If"
                echo -e "\t\t  empty, then the union of all fabrics for the"
                echo -e "\t\t  server and this host will be used.  If there"
                echo -e "\t\t  is more than one fabric configured,
multipath"
                echo -e "\t\t  will be enabled by default."
                return
        fi
        local server="$1"
        local paths=""
        local num_paths=0
        shift 1
        __if_x_in_y "$server" "$SRP_SERVERS" || return
        # Turn off the disallow all option in the config file while we do
        # our work, we restore this at the end
        Enable_Service srpd
        sed -e '/^d$/ d' -i /etc/srp_daemon.conf
        [ -n "$1" ] && paths="$*" || paths="${SRP_FABRICS[$server]}"
        for fabric in $paths; do
                __if_x_in_y "$fabric" "$HOST_FABRICS" || continue
                __if_x_in_y "$fabric" "${SRP_FABRICS[$server]}" || continue
                __setup_srp_client_path "$server" "$fabric" $num_paths
                let num_paths++
        done
        if [ $num_paths -gt 1 ]; then
                if [ ! -f /etc/multipath.conf ]; then
                        cp
/usr/share/doc/device-mapper-multipath-*/multipath.conf /etc
                fi
                Enable_Service multipathd
                Start_Service multipathd
        fi
        echo "d" >> /etc/srp_daemon.conf
        Start_Service srpd
        echo "Your SRP client mounts from $server have been added to the"
        echo "system.  If you enabled more than one path to the device,"
        echo "please find your new multipath device, otherwise find the
newly"
        echo "added SCSI device, then perform the following actions:"
        echo "  1) Make sure no partitions got automounted due to existing"
        echo "     data once you added the device"
        echo "  2) Create or select a partition to use"
        echo "  3) Create a filesystem on the partition (if needed)"
        echo "  4) Run blkid on the partition to get the fs UUID"
        echo "  5) Add the line UUID=\"uuid\" /srv/<server>/SRP ... to the"
        echo "     fstab so the device is automounted on reboots"
        echo "     eg:"
        echo "          UUID=\"c37e3e64-25bb-44e5-96d2-937800e0e3e3\"
/srv/rdma-storage-01/SRP        xfs     defaults,_netdev        1 2"
}


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]