improve sg_luns output for iscsi

improve sg_luns output for iscsi

[Olaf Hering]

Upcoming IBM pSeries firmware can boot from iscsi. To configure the
openfirmware boot-device string, we need to construct a correct
devicepath. This path includes the lun. Its currently not 100% clear
how exactly this lun value has to look like.

sg_luns may be the tool to get the value. But its current output is not
parseable by scripts. It even gives the same output for two different
scsi devices:

girgendwas:~ # lsscsi
[0:0:0:0]    disk    DGC      RAID 5           0219  /dev/sda
[0:0:0:1]    disk    DGC      RAID 5           0219  /dev/sdb
[0:0:0:2]    disk    DGC      RAID 5           0219  /dev/sdc
[0:0:0:3]    disk    DGC      RAID 5           0219  /dev/sdd
girgendwas:~ # sg_luns -V
sg_luns: version: 1.05 20060127
girgendwas:~ # sg_luns /dev/sdd
Lun list length = 32 which imples 4 lun entries
Report luns [select_report=0]:
    0000000000000000
    0001000000000000
    0002000000000000
    0003000000000000
girgendwas:~ # sg_luns /dev/sdc
Lun list length = 32 which imples 4 lun entries
Report luns [select_report=0]:
    0000000000000000
    0001000000000000
    0002000000000000
    0003000000000000

Is it possible to print the lun only for the requested scsi device?

Re: improve sg_luns output for iscsi

[Doug Maxey]

On Tue, 06 Mar 2007 19:04:28 +0100, Olaf Hering wrote:
> 
> Upcoming IBM pSeries firmware can boot from iscsi. To configure the
> openfirmware boot-device string, we need to construct a correct
> devicepath. This path includes the lun. Its currently not 100% clear
> how exactly this lun value has to look like.
> 
> sg_luns may be the tool to get the value. But its current output is not
> parseable by scripts. It even gives the same output for two different
> scsi devices:
> 
> girgendwas:~ # lsscsi
> [0:0:0:0]    disk    DGC      RAID 5           0219  /dev/sda
> [0:0:0:1]    disk    DGC      RAID 5           0219  /dev/sdb
> [0:0:0:2]    disk    DGC      RAID 5           0219  /dev/sdc
> [0:0:0:3]    disk    DGC      RAID 5           0219  /dev/sdd
> girgendwas:~ # sg_luns -V
> sg_luns: version: 1.05 20060127
> girgendwas:~ # sg_luns /dev/sdd
> Lun list length = 32 which imples 4 lun entries
> Report luns [select_report=0]:
>     0000000000000000
>     0001000000000000
>     0002000000000000
>     0003000000000000
> girgendwas:~ # sg_luns /dev/sdc
> Lun list length = 32 which imples 4 lun entries
> Report luns [select_report=0]:
>     0000000000000000
>     0001000000000000
>     0002000000000000
>     0003000000000000
> 
> Is it possible to print the lun only for the requested scsi device?

In the simple test I did on pseries, I just determined the boot device, 
and passed that path to sg_luns.  For pseries, there will be only a 
single lun for boot.  At least for the time being primary storage 
will be on another (possibly raid/lvm) device.

So to me, using 
sg_luns |tail -1 
should get the line with the singleton lun in it, albeit with some 
amount of leading whitespace.

Can you extract some value from the installer that will give you the 
path to the target?

++doug

Re: improve sg_luns output for iscsi

[Olaf Hering]

On Tue, Mar 06, Doug Maxey wrote:

> So to me, using 
> sg_luns |tail -1 
> should get the line with the singleton lun in it, albeit with some 
> amount of leading whitespace.

In the example above, if installing onto sdc, tail -n 1 would give the
lun value from sdd.

> Can you extract some value from the installer that will give you the 
> path to the target?

Its hopefully somewhere in sysfs, just where?

You can not expect that the bootfile was loaded from iscsi when installing
onto iscsi.

Re: improve sg_luns output for iscsi

[Douglas Gilbert]

Olaf Hering wrote:
> Upcoming IBM pSeries firmware can boot from iscsi. To configure the
> openfirmware boot-device string, we need to construct a correct
> devicepath. This path includes the lun. Its currently not 100% clear
> how exactly this lun value has to look like.
> 
> sg_luns may be the tool to get the value. But its current output is not
> parseable by scripts. It even gives the same output for two different
> scsi devices:
> 
> girgendwas:~ # lsscsi
> [0:0:0:0]    disk    DGC      RAID 5           0219  /dev/sda
> [0:0:0:1]    disk    DGC      RAID 5           0219  /dev/sdb
> [0:0:0:2]    disk    DGC      RAID 5           0219  /dev/sdc
> [0:0:0:3]    disk    DGC      RAID 5           0219  /dev/sdd
> girgendwas:~ # sg_luns -V
> sg_luns: version: 1.05 20060127
> girgendwas:~ # sg_luns /dev/sdd
> Lun list length = 32 which imples 4 lun entries
> Report luns [select_report=0]:
>     0000000000000000
>     0001000000000000
>     0002000000000000
>     0003000000000000
> girgendwas:~ # sg_luns /dev/sdc
> Lun list length = 32 which imples 4 lun entries
> Report luns [select_report=0]:
>     0000000000000000
>     0001000000000000
>     0002000000000000
>     0003000000000000
> 
> Is it possible to print the lun only for the requested scsi device?

Olaf,
sg_luns is an application client driving the SCSI
REPORT LUNS command. It is a "trick" SCSI command
since even though it addresses a logical unit, it
is really the target that replies (as it is the target
that knows about the sibling logical units) ***.
The REPORT LUNS response gives no indication which
(if any) 64 bit lun was addressed.

Now I would not want to break the link between sg_luns
and the SCSI REPORT LUNS command. Adding an extra
parameter to try and find the lun associated with the
file descriptor has a few problems (from my point
of view):
   - it would be OS specific (sg_luns isn't currently)
   - within Linux there are different mechanisms in
     the 2.4 and 2.6 series kernels.

In your example above a combination of lsscsi and sg_luns
gives the answer ("0003000000000000") but lsscsi is
linux 2.6 series specific. sg_scan would probably work
as a replacement for lsscsi (and sg_scan also works in the
lk 2.4 series (and Windows)).


To address the parsability of sg_luns output, I recently
added a '--quiet' option to suppress the extraneous
output.


In summary sg_luns is probably not what you want!
What about the lu _name_? For iSCSI the lu should
yield a world wide unique "SCSI name" designator
in the device identification VPD page (see SPC-4
and SAM-4 Annex A; the iSCSI standard woffles in
this area).


*** a better way to get a target to report its active
luns is to use the REPORT LUNS well known logical
unit but hardly anyone implements that.

Doug Gilbert

Re: improve sg_luns output for iscsi

[Olaf Hering]

On Tue, Mar 06, Douglas Gilbert wrote:

> In summary sg_luns is probably not what you want!

Yes, it can be done in bash.

cd /sys/block/sde/device ; i=`pwd -P` ; printf '%x%012x\n' ${i##*:}