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
