improve sg_luns output for iscsi

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

Yes, it can be done in bash.

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

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

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

Its hopefully somewhere in sysfs, just where?

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