Hi Jerome, Sorry for the delayed response (AEDT timezone) and thank you for your replies - particularly the second which confirmed my suspicions around Xen. > 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 :-( I use Corosync+Pacemaker to manage some high performance HA storage clusters and several of these use iSCSI w/ Xen or XenServer. What I'm trying to do is avoid is: A) Adding configuration or state managed outside of the clusters visibility, i.e. stored on a shared LV or filesystem. B) Creating more managed resources and dependancies within the cluster design. > 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? That would be fantastic and a great help with configuration / state automation and repeatability. With the PR information provided to TargetCLI from the OCF resource agent this would allow the LUN to shift between hosts and essentially appear unchanged to Xen. Parameters are passed to TargetCLI as follows and would need to be extended to accept the PR metadata: https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/iSCSILogicalUnit#L362 I can submit a PR for the iSCSILogicalUnit resource agent if you're able to add and document the functionality to TargetCLI? -- Sam McLeod ��.n��������+%������w��{.n����j� ����{ay� ʇڙ���f���h������_�(�階�ݢj"��������G����?���&��
