Just looked up how Xen does things, in terms of identifying a disk, and
it does not seem very sane. It seems that you were indeed spot-on when
mentionning SCSI ID specifically. It did not seem to make sense at
first, but still seems to be the way they do it :-(
A couple of reads for thought :
Linus' take on it:
http://yarchive.net/comp/linux/scsi_ids.html
Which end with the obvious: "Trying to make more people use UUID's is
the way to _really_ distinguish devices from each other."
Clarification (sort of) of what Xen does:
http://support.citrix.com/article/CTX118641#Identify%20the%20SCSI%20ID%20mapping%20which%20has%20issue
So, basically the tools are there to save/restore PR metadata, sharing
it with a secondary node is an exercise left to the cluster admin but is
trivial (csync2 just works), and a 2-lines python script using rtslib
can restore arbitrary metadata from file on a different node if the WWNs
have changed. Unfortunately, dealing with broken logic from Xen will
still require some head-scratching I am afraid :-(
One thing I could do to maybe help you integrate this a bit more would
be to export a targetcli command to load PR APTPL data directly from
CLI, that you could use to script your way out of that quagmire without
resorting to python code. Would that help?
On 11/05/2015 07:43 AM, Jerome Martin wrote:
Hi,
On 11/05/2015 02:47 AM, Sam McLeod wrote:
Hello,
I'm trying to figure out how to enable APTPL using TargetCLI but I
can't see any parameters / attributes within the config tree to do so
however I can see the persistent reservation support is present in
ConfigFS:
Nothing is needed to enable it, it is enabled by default, you just
need to issue PR commands to populate the data.
/sys/kernel/config/target/core/iblock_0/iscsi_lun_r0/pr # ls
res_aptpl_active res_aptpl_metadata res_holder res_pr_all_tgt_pts
res_pr_generation res_pr_holder_tg_port res_pr_registered_i_pts
res_pr_type res_type
Right, this is the configfs part. The metadata is actually stored in
/var/target/pr, and is reloaded/restored by rtslib/targetcli whenever
a storage object is instanciated.
The reason I'm trying to do this is that we've found the SCSIid to
change after creation / ha-failover which breaks authentication with
XenServer as per https://github.com/agrover/targetcli-fb/issues/53
Not sure about this specific report, and I am talking here about the
main branch of targetcli / rtlib that I maintain, not Andy's fork. But
if you want to restore PR after an HA failover, you want a way to copy
over the PR metadata to the secondary host from the primary whenever
it is changed. This can be acheived either manually, with some custom
script of even better with something like csync2 (files syncs on
distant servers using inotify to detect the file changes) or some
other mechanism (DRBD, shared NFS, anything).
If by SCSIid you mean the WWN of the backend device changes, then of
course this wont work automatically. Not sure why the WWN would change
for the same device being failed over though. Two options, either you
find a way to change the PR WWN on the secondary host, or you add
provision to reload the proper PR metadata by calling rtslib. See
restore_pr_aptpl() in rtslib StorageObject that can reload your PR
APTPL metadata from file.
Hope this help, tell me if you need clarifications.
Best,
--
Jerome
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
