Can VPD Unit Serial Number be persistent?

[Lee Duncan]

Hi:

I am creating an iSCSI LUNs using iblock back end storage.

I notice that my VPD Unit Serial Number is different each time my server
reboots. That does not seem right.

Is this a bug?

I looked back through the list archives and saw that you do not allow
this attribute to be set at back store creation time, but there is an
option to tell it not generate a WWN. (using generate_wwn=false)

But when I do that I get no VPD Page 0x83 data at all, and the name of
the resulting target, once connected, in /dev/disk/by-id is scsi-1LIO-ORG.

It does not seem right that the identity of the disc changes each time
the server is rebooted.

[Lee Duncan]

Post by Lee Duncan
I am creating an iSCSI LUNs using iblock back end storage.
I notice that my VPD Unit Serial Number is different each time my server
reboots. That does not seem right.

I take it by the lack of response that this is either an issue that has
been discussed before, or one that nobody else cares about?

In my case, this bug means that when my target nodes reboot and I get
new Serial Numbers the cluster using that node as part of a logical
volume cannot find it.

I will work on a patch for submission.

Post by Lee Duncan
Is this a bug?
I looked back through the list archives and saw that you do not allow
this attribute to be set at back store creation time, but there is an
option to tell it not generate a WWN. (using generate_wwn=false)
But when I do that I get no VPD Page 0x83 data at all, and the name of
the resulting target, once connected, in /dev/disk/by-id is scsi-1LIO-ORG.
It does not seem right that the identity of the disc changes each time
the server is rebooted.

[Andy Grover]

Post by Lee Duncan

Post by Lee Duncan
I am creating an iSCSI LUNs using iblock back end storage.
I notice that my VPD Unit Serial Number is different each time my server
reboots. That does not seem right.

I take it by the lack of response that this is either an issue that has
been discussed before, or one that nobody else cares about?

Or it was the weekend :)

Post by Lee Duncan
In my case, this bug means that when my target nodes reboot and I get
new Serial Numbers the cluster using that node as part of a logical
volume cannot find it.
I will work on a patch for submission.

Yup. BTW this is a user tools (rtslib and/or targetcli) issue, not
kernel code. The issue is not present in targetcli-fb.

Regards -- Andy

[Christoph Hellwig]

Post by Lee Duncan
I will work on a patch for submission.

Yup. BTW this is a user tools (rtslib and/or targetcli) issue, not kernel
code. The issue is not present in targetcli-fb.

Btw, what's the status of the targetcli trees? I though with the
licensing updates we'd be able to get a unified version again.

Can anyone in the loop explain what the current set of major differences
are?

[Andy Grover]

Post by Christoph Hellwig
Btw, what's the status of the targetcli trees? I though with the
licensing updates we'd be able to get a unified version again.

The status of the trees is.. they've diverged. targetcli-fb in many
smaller ways, and Datera targetcli in the addition of a new config API.
See below.

Both are Apache-licensed now, so licensing is fixed. The remaining
issues I see are reunifying the code and cooperating on development.

Regarding the code, Jerome, I'd really like to carry across the
improvements in -fb, but think there were things that I removed
(loadable .specs? backwards compat?) that prevented you from basing your
new development on it. Can you talk a little about what you'd need in a
converged version?

Regarding development cooperation, I'm for it. But licensing wasn't the
only issue that resulted in the -fb branch, so we'd need to work through
those issues (release engineering, public discussion of future plans,
ensuring timely bugfixes) too for it to be successful.

Post by Christoph Hellwig
Can anyone in the loop explain what the current set of major differences
are?

Maybe Jerome wants to add more, but for Datera targetcli, it's the new
config API:

http://thread.gmane.org/gmane.linux.scsi.target.devel/5838

For targetcli-fb:

* targetcli commands can be invoked from cmdline and return an error code
* python 3 support
* lio-utils is gone, config saved in .json format
* Easier storage-ACL setup
* WWN format standardized
* Only show HW fabrics that are present
* 10 previous configs saved
* initiator ACL grouping
* More info in summaries
* iSER support
* Caching for better scalability
* added a manpage
* rtslib: Remove .specfiles in favor of Python (fabric.py)

Regards -- Andy

[Lee Duncan]

Andy:

Thanks for your reply.

Post by Andy Grover

Post by Lee Duncan

Post by Lee Duncan
I am creating an iSCSI LUNs using iblock back end storage.
I notice that my VPD Unit Serial Number is different each time my server
reboots. That does not seem right.

I take it by the lack of response that this is either an issue that has
been discussed before, or one that nobody else cares about?

Or it was the weekend :)

I forget time sometimes when I'm behind this keyboard.

Post by Andy Grover

Post by Lee Duncan
In my case, this bug means that when my target nodes reboot and I get
new Serial Numbers the cluster using that node as part of a logical
volume cannot find it.
I will work on a patch for submission.

Yup. BTW this is a user tools (rtslib and/or targetcli) issue, not
kernel code. ...

Is there a different mailing list for that?

Post by Andy Grover
...The issue is not present in targetcli-fb.

Please explain, if you would. In SLES we have a slightly older version
of targetcli and targetcli-fb, but I could not find any documentation on
targetcli-fb.

I just want the ability to save the current target configuration
including the WWN so that I can restore it after restart or reboot. I am
more than willing to write some custom python or work on patching the
python libraries we are using. But, honestly, it seems like
functionality that should already be in rtslib/targetcli[-fb], at least
as an option.

Post by Andy Grover
Regards -- Andy

[Andy Grover]

Post by Lee Duncan

Post by Andy Grover
Yup. BTW this is a user tools (rtslib and/or targetcli) issue, not
kernel code. ...

Is there a different mailing list for that?

Datera targetcli/rtslib use this list, targetcli-fb and rtslib-fb use

Post by Lee Duncan

Post by Andy Grover
...The issue is not present in targetcli-fb.

Please explain, if you would. In SLES we have a slightly older version
of targetcli and targetcli-fb, but I could not find any documentation on
targetcli-fb.

You do? SLES includes both versions?

What version of targetcli-fb and friends are you using? Saving and
restoring WWNs has been supported for a very long time.

Targetcli-fb docs are mostly the targetcli.8 manpage, or, what docs
exactly were you looking for? For reference:

https://fedorahosted.org/targetcli-fb/

Post by Lee Duncan
I just want the ability to save the current target configuration
including the WWN so that I can restore it after restart or reboot. I am
more than willing to write some custom python or work on patching the
python libraries we are using. But, honestly, it seems like
functionality that should already be in rtslib/targetcli[-fb], at least
as an option.

Absolutely, this should be working.

Regards -- Andy

[Nicholas A. Bellinger]

Hi Lee,

Post by Lee Duncan

Post by Lee Duncan
I am creating an iSCSI LUNs using iblock back end storage.
I notice that my VPD Unit Serial Number is different each time my server
reboots. That does not seem right.

I take it by the lack of response that this is either an issue that has
been discussed before, or one that nobody else cares about?
In my case, this bug means that when my target nodes reboot and I get
new Serial Numbers the cluster using that node as part of a logical
volume cannot find it.
I will work on a patch for submission.

Post by Lee Duncan
Is this a bug?
I looked back through the list archives and saw that you do not allow
this attribute to be set at back store creation time, but there is an
option to tell it not generate a WWN. (using generate_wwn=false)
But when I do that I get no VPD Page 0x83 data at all, and the name of
the resulting target, once connected, in /dev/disk/by-id is scsi-1LIO-ORG.
It does not seem right that the identity of the disc changes each time
the server is rebooted.

Can you be a bit more specific about the version of userspace code your
using..?

For rtslib + targetcli v2, the unit serial is saved via lio-utils for
each device into /etc/target/tcm_start.sh, that ends up looking like the
following:

tcm_node --setunitserialwithmd rd_mcp_1/ramdisk_large 758fe0a4-af72-495a-adf0-afde7926e9a5

For at rtslib + targetcli v3-pre code, this should be getting saved into
/etc/target/scsi_target.lio, but IIRC some of the earlier v3 code was
not saving /sys/kernel/config/target/core/$HBA/$DEV/wwn/vpd_unit_serial.

Jerome (CC'ed), can you confirm if this has been fixed already..?

Thanks,

--nab

[Lee Duncan]

Post by Nicholas A. Bellinger
Hi Lee,

Post by Lee Duncan

Post by Lee Duncan
I am creating an iSCSI LUNs using iblock back end storage.
I notice that my VPD Unit Serial Number is different each time my server
reboots. That does not seem right.

I take it by the lack of response that this is either an issue that has
been discussed before, or one that nobody else cares about?
In my case, this bug means that when my target nodes reboot and I get
new Serial Numbers the cluster using that node as part of a logical
volume cannot find it.
I will work on a patch for submission.

Post by Lee Duncan
Is this a bug?
I looked back through the list archives and saw that you do not allow
this attribute to be set at back store creation time, but there is an
option to tell it not generate a WWN. (using generate_wwn=false)
But when I do that I get no VPD Page 0x83 data at all, and the name of
the resulting target, once connected, in /dev/disk/by-id is scsi-1LIO-ORG.
It does not seem right that the identity of the disc changes each time
the server is rebooted.

Can you be a bit more specific about the version of userspace code your
using..?

rtslib (python-rtslib in our system) is 2.2 plus quite a few patches. I
did not set it up, so not exactly sure exactly which patches without a
bit of detective work.

For targetcli it's version 2.1 with some patches.

Post by Nicholas A. Bellinger
For rtslib + targetcli v2, the unit serial is saved via lio-utils for
each device into /etc/target/tcm_start.sh, that ends up looking like the
tcm_node --setunitserialwithmd rd_mcp_1/ramdisk_large 758fe0a4-af72-495a-adf0-afde7926e9a5
For at rtslib + targetcli v3-pre code, this should be getting saved into
/etc/target/scsi_target.lio, but IIRC some of the earlier v3 code was
not saving /sys/kernel/config/target/core/$HBA/$DEV/wwn/vpd_unit_serial.

I think I was under the misconception that my versions of rtslib and
targetcli explicitly did not need lio-utils. But I'm seeing now that was
wrong and at the heart of my problem.

Sure enough, when I enable the lio-utils service (using systemd), the
WWN becomes persistent. This is of course become part of the service
starting includes running the initialization shell files in /etc/target.

Post by Nicholas A. Bellinger
Jerome (CC'ed), can you confirm if this has been fixed already..?
Thanks,
--nab

Thanks!

[Jerome Martin]

Hi Lee,

Sorry for being slow on this, as mentioned there was the week-end but
also some pretty hectic traveling for me as well these last days...

Post by Lee Duncan
I think I was under the misconception that my versions of rtslib and
targetcli explicitly did not need lio-utils. But I'm seeing now that was
wrong and at the heart of my problem.

Yes, the 2.x series rely on lio-utils, and the 3.x rtslib has the new
configuration system mentioned earlier by Andy, which replaces lio-utils
altogether along with initscripts.

Post by Lee Duncan
Sure enough, when I enable the lio-utils service (using systemd), the
WWN becomes persistent. This is of course become part of the service
starting includes running the initialization shell files in /etc/target.

Excellent, thanks for confirming this.

Best Regards,
--
Jerome