TOPIC:

Is it possible to have the iscsi-ha floating IP on a different subnet than the replication network, given you have an appropriate number of adapters in the system?

I am not entirely sure. I have a feeling it would fail. You can try a quick experiment to see if the secondary ip can be added.

ip addr add <ip on another Subnet>/mask dev xapi?

Insert your test ip/mask into the above and replace the ? At the end with the interface number. If you get an error with this test, it would not be supported by iscsi-ha

Actually, now that I think about it, even if you were to add the ip, it would not work as the secondary host would not know how to route to the foreign Subnet, which would result in a failure to mount the iSCSI storage

I'm talking under this scenario:
You have 3 hosts in an HA pool. 2 of the 3 are participating in a DRBD/iscsi-ha replication pool. You have multiple 10Gbe interfaces in each system. You want two to be dedicated to the replication network, and the others to be used for iSCSI traffic to host 3.
So, you configure:
1) Network 10.100.1.0/30 for the replication network.
2) Network 10.100.2.0/24 for the traffic network.
3) Assign 10.100.1.1 and 10.100.2.1 to host A, 10.100.1.2 and 10.100.2.2 to host B.
4) You configure 10.100.2.3 as the floating iSCSI IP.

Since all systems have a dedicated IP on the traffic network, there shouldn't be any routing issues?

Ok. Relative to routing, this sounds like it would work, however, now that I see there are 3 hosts there is another challenge.

Should the pool master fail, you run the risk of the the 3rd host (the one that is not participating in the DRBD/iscsi SR) being promoted to the new pool master. This would leave you with a pool where the VMs have no access to the storage at all. In this case, you would need to manually expose the storage on the remaining slave (the one with the DRBD disk) by entering manual mode there and promoting the host to the primary DRBD role (iscsi-cfg enable-manual-mode && iscsi-cfg become-primary)

Another option is to slightly hack the HA-Lizard code such that Only the slave with the DRBD disk can ever be promoted to Pool Master.

Under normal operating conditions, the master checks for available slaves every few seconds and elects a single slave as being eligible to become master. The logic for selecting the slave is rather simple. You can hard code something such that only the slave you want gets selected.

Makes sense. If you're going to run a pool of more than 3 hosts, it sounds like this is a necessity.

I'm fighting another issue with my new pool now ; XenCenter sees the target, and detects the LUN - but when I tell it to format the LUN, it's returning "The storage repository is not available".