[ClusterLabs] is SFEX valid for Pacemaker on VMware with fence_vmware_soap?

Satoshi Suzuki tight2loop at gmail.com
Fri Sep 14 07:30:55 EDT 2018

 Hi Andrei,
thanks for your interest and response.

*>> As for the disk exclusive control and fencing mechanism with Pacemaker,
*>> our IT vendor is proposing to use SFEX (Shared Disk File EXclusiveness)
*>> and fence_vmware_soap (to reset the failing node via vCenter). *

*>* * What is SFEX? I could not find this abbreviation anywhere. *

It looks like *"Shared Disk File EXclusiveness" *.  Pls take look at the

*> Interesting point. In general pacemaker timeouts are supposed to always *
*> be larger than underlying infrastructure timeouts. I.e. you need to *
*> account for multipath failover as well as internal ESXi failover. I.e. *

OK, in my case, two paths of FC from each of ESXi hosts to the storage,
so we consider 60+sec (30x2+some seconds) or 120sec for the timeout.

* > if ESXi host is unresponsive long enough, it is kicked out of HA
cluster *
*> and VMs are restarted elsewhere. Disk access in this case should be *
*> regulated by internal ESXXi locking.*

Suppose if the ESXi hangs longer than 120s then it comes back,
fence_vmware_soap would not work timely (as the target ESXi was hanging)
and pacemaker timeout itself would not work immediately(as SW watchdog
then the queued I/Os before the hang would override the disks.

Sorry, I can't understand how your saying "internal ESXi locking" with SFEX
would protect my concerned scenario above.

* So I think SFEX is valid only if combined with STONITH IPMI for *>>*
baremetal servers or even VMware hosts, *
>>* and we should use fence_scsi for the recent SPC-3 compliant disk
storage *
>>* with fence_vmware_soap on VMware. Am I right? *

*> This depends on your storage configuration. SCSI-3 reservation across *
*> ESXi hosts is supported only with RDM in physical compatibility mode.*

Sure, my disk configuration is RDM in physical compatibility mode, as
required by VMware.

Thanks for further guidance or suggestions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20180914/6191736d/attachment-0002.html>

More information about the Users mailing list