We need a STONITH/fencing agent for our Pacemaker cluster. What's a reliable, hardware-agnostic one?

Strictly speaking, a completely hardware-agnostic and reliable STONITH solution for Pacemaker Go to product viewer dialog for this item. usually means moving away from vendor-specific power distribution units (PDUs) or out-of-band management cards (like IPMI, iDRAC, or iLO) and moving toward software-based / watchdog-driven fencing.

The industry standard approach for this is SBD (Storage-Based Death / STONITH Block Device) paired with a hardware watchdog.

The Best Hardware-Agnostic Option: sbd (with a Watchdog)

Instead of depending on external hardware to cut power, sbd relies on a local hardware watchdog timer embedded in your server motherboard/kernel (e.g., /dev/watchdog).

• How it works (Diskless / Watchdog mode): If a node loses communication with the cluster or freezes, it fails to "kick" the watchdog timer. When the timeout expires, the local watchdog automatically triggers a hard system reset/panic.
• Why it's hardware-agnostic: It doesn't care if you are running Dell, HPE, Supermicro, white-box servers, or KVM virtual machines—as long as the OS has a functional kernel watchdog driver.
• Reliability: Extremely high. It eliminates network dependencies and remote management authentication failures (like expired IPMI passwords or locked BMC interfaces) during a split-brain scenario.

Alternative: fence_watchdog

If you are already running Pacemaker and just need a direct software fencing plugin that leverages the local watchdog without the full SBD daemon layer, fence_watchdog is built right into Pacemaker's ecosystem.

• How it works: It acts as a STONITH agent (fence_watchdog ) that essentially tells a node to self-fence by letting its local watchdog expire if it's targeted for isolation.
• Caveat: Watchdog fencing is a self-fencing mechanism. It requires that the node is still healthy enough to execute the fence command, or that the watchdog timer naturally trips when communication ceases. It is often combined with network/other fencing in a dual-device environment to ensure absolute safety.

If You Need External Network-Based Agnosticism: fence_ipmi

If "hardware-agnostic" to you means standardized across different server vendors rather than purely software-only, IPMI (fence_ipmi) is universally built into almost all enterprise server baseboard management controllers (BMC).

• It works across Supermicro, Dell, HPE, and Cisco out of the box, provided you configure standard IPMI/LAN over BMC credentials. However, it relies heavily on network stability and BMC health.

If you'd like, let me know:

• Are you running bare metal or virtual machines?
• Do you have shared storage available (like a SAN or shared disk), or do you need a diskless setup?

I can provide a concrete configuration example for either sbd or fence_watchdog.

If you mean truly hardware-agnostic, the best answer is usually not a single STONITH agent, but a fencing method that is independent of the server vendor. In Pacemaker, the most broadly applicable choices are:

1. fence_sbd — often the closest thing to hardware-agnostic

SBD (STONITH Block Device) is commonly used when you want fencing that does not depend on IPMI, iLO, iDRAC, or a PDU. It uses a shared block device (or sometimes watchdog-based setups) as the arbitration mechanism.

Pros

• Vendor-neutral
• Works across many physical and virtual platforms
• Good fit for shared-storage clusters
• Avoids dependency on a server management controller

Cons

• Requires careful shared-storage design
• A broken storage path can complicate fencing design
• Needs proper watchdog configuration for robust deployments

Example:

pcs stonith create sbd-fence fence_sbd \
  devices=/dev/shared/sbd-device \
  pcmk_host_list="node1 node2"

(Exact parameters depend on your SBD layout.)

---

2. fence_ipmilan — the practical default for physical servers

If your nodes have BMC/IPMI support, fence_ipmilan is probably the most common production choice. It works with many vendors because IPMI is a standard interface. Supported agents commonly include IPMI and vendor variants such as iLO/iDRAC.

Pros

• Works with Dell, HPE, Supermicro, Lenovo, etc.
• Simple operational model: power off/reset the failed node
• Well understood by cluster administrators

Cons

• Depends on the BMC being reachable
• Some older IPMI implementations are unreliable

---

3. Cloud/virtual environments: use the platform fence agent

For VMs, do not use SSH fencing. Pacemaker documentation specifically warns that fencing should not depend on the target node being functional; SSH shutdown is suitable only for testing.

Use the hypervisor/cloud API instead:

• VMware → fence_vmware_soap
• KVM/libvirt → fence_virsh
• AWS → fence_aws
• Azure → fence_azure_arm
• GCP → fence_gce

---

My recommendation by environment

A good production design often uses two independent fencing paths where possible (for example, IPMI plus SBD/storage fencing), because the fencing mechanism itself becomes a critical dependency.

If you tell me whether your nodes are bare metal vs VMs, and whether you have shared storage (SAN/DRBD/etc.), I can suggest the most appropriate STONITH design.

If by hardware-agnostic you mean “doesn't depend on a particular server vendor,” my first choice is SBD (Storage-Based Death) rather than a vendor-specific BMC agent.

• SBD + a real hardware watchdog is a very solid Pacemaker fencing mechanism. It uses a watchdog to forcibly reset/self-fence a node, and can optionally use shared storage for coordination. ClusterLabs describes SBD as a highly reliable fencing mechanism for Pacemaker.
• It is largely vendor-independent: you need a usable hardware watchdog and, for storage-backed SBD, shared block storage accessible to the nodes—not Dell iDRAC, HPE iLO, etc.
• Use a hardware watchdog in production. ClusterLabs explicitly cautions that software watchdogs depend on the OS continuing to function and are therefore less reliable for fencing.
• Pacemaker integrates SBD through stonith:external/sbd; it should be configured as a primitive rather than a clone.

What I'd choose

Physical servers + shared storage: SBD + hardware watchdog is probably the best hardware-agnostic choice.

No shared storage, but servers have IPMI/Redfish: Use fence_ipmilan/fence_redfish. fence_ipmilan is itself vendor-neutral at the protocol level and supports machines controlled through IPMI; the same fence-agent framework also provides vendor-specific aliases such as iDRAC and iLO.

VM cluster: Fence through the hypervisor/platform rather than trying to make guest-level watchdog fencing your primary mechanism.

One important caveat: don't confuse “hardware-agnostic” with “hardware-independent.” SBD still benefits greatly from a real hardware watchdog, and watchdog-only SBD has quorum requirements; ClusterLabs notes that watchdog-only resource recovery requires true quorum, such as three or more nodes or a two-node cluster with external quorum.

If you tell me whether your nodes are physical or VMs, 2-node or 3+ node, and whether you have shared SAN/iSCSI storage, I can recommend the exact Pacemaker fencing topology and pcs stonith configuration.

The gold standard for a reliable, hardware-agnostic (and hypervisor-agnostic) STONITH mechanism in a Pacemaker cluster is SBD (Storage-Based / Self-Fencing Block Device).

Instead of relying on IPMI, iLO, DRAC, or cloud-provider API fence agents—which often break or behave inconsistently across different server models and firmware versions—SBD uses a block device and local watchdog timers.

Why SBD is Hardware-Agnostic

• Storage-less or Shared Storage: It can operate via shared disk (SAN, iSCSI, or multipath LUN accessible by all nodes) or in a diskless/watchdog-only "self-fencing" mode.
• No BMC/IPMI Dependency: It doesn’t care if your nodes are Dell, HP, white-box, or virtualized; it communicates via disk or internal system timeouts.
• Low Latency & High Reliability: If a node stops refreshing its heartbeat or explicitly receives a panic/reset message from a peer through the SBD device, the local kernel's watchdog immediately forces a hard system reset.

How to Implement SBD

• Step 1. Configure a Watchdog Device: Ensure a hardware or software watchdog module (e.g., softdog or iTCO_wdt ) is loaded on every node. Hardware watchdogs are strongly preferred for production.
• Step 2. Initialize the SBD Device: If using shared storage, create and initialize the SBD message slots on a shared LUN:bash``` sbd -d /dev/disk/by-id/your-shared-luns create

Use code with caution.[[1]](https://oneuptime.com/blog/post/2026-03-04-sbd-fencing-rhel-9-ha-clusters/view)
- **Step 3. Configure Pacemaker to use SBD:** Set up the SBD daemon configuration (typically in `/etc/sysconfig/sbd` or `/etc/default/sbd` ) to point to your watchdog and device, then configure the `stonith:external/sbd` resource inside Pacemaker so it knows how to interface with the daemon.[[1]](https://manpages.ubuntu.com/manpages/jammy/man8/sbd.8.html)[[2]](https://kb.linbit.com/pacemaker-stack/stonith/stonith-using-sbd-storage-based-death/)

If you'd like to proceed, tell me:

- Are you deploying a **2-node** or **multi-node (3+)** cluster?
- Do you have **shared block storage** available (like iSCSI/SAN), or do you need a **diskless/watchdog-only** setup?

I can provide the **exact configuration commands** and **Pacemaker primitive syntax** for your layout.

If by hardware-agnostic you mean “doesn't depend on a particular server vendor or IPMI controller,” my first choice is SBD (Storage-Based Death) with a watchdog.

Best fit: SBD + watchdog

SBD is a Pacemaker-native fencing mechanism that uses a node's watchdog to force a hard reset, optionally using shared storage for “poison-pill” fencing. It works independently of Dell iDRAC, HPE iLO, Supermicro IPMI, etc.

There are two useful variants:

• Watchdog-only SBD — each node has a functional hardware/software watchdog; a node that must be fenced self-reboots.
• SBD with shared block storage — Pacemaker/SBD writes a fencing message to shared storage, and the target node's SBD daemon sees it and forces a reset. This gives you stronger fencing semantics when shared storage is available.

For example, on current RHEL, the watchdog approach can be exposed to Pacemaker as:

pcs stonith create sbd_watchdog fence_watchdog

Red Hat documents sbd as a supported alternative to traditional fence-agent-based devices, including on RHEL 8/9/10.

One important caveat

I wouldn't call SBD universally hardware-agnostic. It requires a reliable watchdog on every node for watchdog fencing, and shared-storage SBD requires storage that remains accessible under the failure scenarios you're trying to protect against. Red Hat specifically notes that storage compatibility has to be evaluated for the particular environment.

If your machines expose BMC/IPMI, then fence_ipmilan is generally the conventional production choice—but that's hardware-dependent. Pacemaker deliberately abstracts these technologies behind fence agents.

My rule of thumb:

And whatever mechanism you choose, actually test fencing (pcs stonith fence <node>) before trusting the cluster; a configured-but-untested STONITH device isn't much protection.

If you tell me whether your nodes are bare metal, VMs, or mixed, and whether you have shared storage/watchdogs, I can recommend the exact fencing topology and pcs configuration.

When looking for a hardware-agnostic and reliable fencing solution for a Pacemaker cluster that doesn't tie you down to a specific vendor's IPMI, iLO, or proprietary PDU, the gold standard is SBD (STONITH Block Device).

Instead of toggling physical power via a network management board, SBD uses shared storage (or a shared block device/disk) and a watchdog timer to achieve robust, software-defined self-fencing.

How SBD Works

• Shared Storage (Poison Pill): All cluster nodes have access to a small shared block device (like a shared SAN LUN, a tiny iSCSI/FC disk, or multiple redundant disks). If a node loses cluster communication or misbehaves, the surviving nodes write a "poison pill" message to the shared disk targeting the bad node.
• Watchdog Timer: Every node runs the sbd daemon, which continuously pets a local hardware watchdog device. When a node sees its own ID flagged on the shared disk—or if Corosync/Pacemaker crashes locally—the daemon stops petting the watchdog. The hardware watchdog immediately triggers a hard system reset/panic.

Why it's Reliable and Hardware-Agnostic

• No Vendor Lock-in: It doesn't care if you're running Dell, HPE, Supermicro, white-box servers, or virtual machines; as long as they can access a tiny shared block device and have a working watchdog, it works.
• No Network Dependencies on IPMI: IPMI/iLO interfaces frequently suffer from authentication failures, locked BMC firmware, or isolated management networks going down. SBD bypasses this by leveraging your existing high-availability storage path.
• Fast and Deterministic: Hard resets via a hardware watchdog are virtually instantaneous.

Quick Setup Overview

1. Provision a Watchdog: Ensure a hardware watchdog module (e.g., iTCO_wdt or IPMI watchdog) is loaded on every node.
2. Configure Storage: Allocate a tiny shared LUN (even 1MB to 10MB is plenty) accessible by all cluster members.
3. Initialize SBD: Format and initialize the block device using sbd -d /dev/disk/by-id/... create.
4. Integrate with Pacemaker: Configure the stonith:external/sbd agent inside Pacemaker so it knows how to interface with the local daemon.

(Note: If shared storage isn't an option and you are running in a public cloud, cloud-specific API fence agents like fence_aws, fence_gce , or fence_azure_arm serve a similarly hardware-agnostic role for virtual environments.)

Would you like the exact configuration steps and commands for setting up SBD, or are you running this in a cloud environment (AWS, Azure, GCP) where a cloud-native API fence agent might fit better?

If by hardware-agnostic you mean “not tied to a server vendor’s iLO/iDRAC/IPMI implementation,” the best fit is usually SBD (STONITH Block Device).

• SBD + a watchdog is a mature Pacemaker fencing mechanism. It uses a shared block device (SAN/iSCSI/etc.) to deliver fencing messages and a watchdog on each node to guarantee that a node actually reboots if it becomes unresponsive.
• It avoids dependence on vendor-specific management controllers/firmware, which is explicitly one of SBD's advantages.
• You can also use diskless SBD with just node-local watchdogs, but there are important topology constraints: in particular, don't use diskless SBD as the sole fencing mechanism for a two-node cluster.
• Pacemaker itself recommends real fencing; simply using something like SSH to tell the failed node to shut itself down is not considered reliable fencing because the target may be precisely what has failed.

What I'd choose

For a conventional Pacemaker cluster, I'd favor SBD with stonith-enabled=true, rather than trying to find a magical “software-only” fence agent. SBD is specifically designed to provide fencing without requiring a particular server-management vendor.

If you tell me whether this is 2 or 3+ nodes, physical vs VMs, and whether you have shared storage, I can recommend the exact fencing topology and pcs configuration.

When you need a reliable, hardware-agnostic (and vendor-neutral) STONITH solution for a Pacemaker cluster, software-based fencing via SBD (STONITH Block Device) or SCSI persistent reservations (fence_scsi) are the gold standards. They eliminate any dependency on IPMI, iLO, iDRAC, or specific PDU hardware.

The two best hardware-agnostic approaches include:

• SBD (STONITH Block Device / Storage-Based Death)
  • How it works: It runs a small daemon (sbd ) on each cluster node that communicates via a shared block device (SAN, iSCSI, or shared disk). If a node loses cluster communication or is designated for fencing, a "poison pill" message is written to the disk, or the local software/hardware watchdog triggers a hard reset/panic on the node.
  • Hardware agnostic aspect: It works identically whether your nodes are physical servers, KVM/VMware VMs, or cloud instances—as long as they can access a tiny shared LUN/disk or use a watchdog.
  • Requirement: A reliable hardware watchdog device (e.g., /dev/watchdog ) on each node.
• SCSI Fencing (fence_scsi / fence_mpath)
  • How it works: Uses SCSI-3 Persistent Reservations (PR) over shared storage. When a node is fenced, the surviving nodes command the shared storage array to revoke the misbehaving node's reservation key. If the fenced node attempts to keep writing to the LUN, a local watchdog check trips and forcefully resets/panics the node.
  • Hardware agnostic aspect: Completely independent of server vendor or power management firmware; it relies entirely on your shared storage infrastructure supporting SCSI-3 PR.
  • Requirement: You must have shared block storage that supports SCSI-3 persistent reservations, and your cluster must actually use that shared storage for clustered resources (like OCFS2 or clustered LVM).

If you can tell me a bit more about your stack:

• Are you running on bare-metal, virtual machines (KVM/VMware) , or public cloud?
• Do you have shared storage (like iSCSI/SAN/NFS) already available to the cluster nodes?

I can help you choose between SBD and SCSI fencing and walk you through the exact setup commands.

For a truly hardware-agnostic and robust STONITH solution in a Pacemaker cluster, SBD (STONITH Block Device) using a shared block storage or a local hardware watchdog is the industry standard. Instead of relying on specific server vendor management boards (like IPMI, iLO, or iDRAC) or hypervisor APIs, SBD uses a software watchdog timer combined with shared storage or diskless messaging to safely self-fence or poison-pill an unresponsive node.

Why SBD is Hardware-Agnostic

• Storage-Based SBD: Relies on a tiny shared block device (like a shared LUN or iSCSI target) accessible by all cluster nodes. Nodes write heartbeats to the disk; if a node stops updating its heartbeat, the others declare it dead and signal the block device to force-reset or panic the target node.
• Watchdog-Only (Diskless) SBD: Relies strictly on a local hardware or software watchdog timer (/dev/watchdog ) on each node, often paired with a cluster quorum daemon (corosync-qdevice ), eliminating external storage dependencies while remaining completely independent of server brand.

Comparison of Hardware-Agnostic / General Fencing Agents

If you can share whether your cluster is running on bare-metal or virtual machines , and whether you have shared storage (like iSCSI/SAN) available, I can provide the exact configuration commands to set up your fencing agent.

Yes. If by hardware-agnostic you mean “doesn't depend on Dell iDRAC, HPE iLO, IPMI, a particular PDU, etc.”, my first choice is SBD (Storage-Based Death) with a watchdog.

SBD integrates with Pacemaker and uses a shared block device plus a watchdog to ensure a failed node self-fences. It is explicitly supported as an alternative to a traditional fence-agent device.

Why SBD is a good fit

• Hardware independent: works across physical servers and VMs as long as the nodes have appropriate shared storage and watchdog support.
• Doesn't rely on the failed node's network stack: a key requirement for reliable fencing. Pacemaker specifically warns against fencing mechanisms that depend on the target node functioning correctly.
• Mature Pacemaker integration: typically exposed as stonith:fence_sbd, with pcs stonith sbd tooling on RHEL-family systems.
• Watchdog makes the failure mode stronger: if a node receives a fencing condition but can't communicate/respond normally, the watchdog can force it to reboot rather than merely relying on the node cooperating.

A typical architecture is:

             Shared block device
              ┌───────────────┐
              │   SBD device  │
              └───────┬───────┘
                      │
          ┌───────────┴───────────┐
          │                       │
       Node A                   Node B
     Pacemaker                Pacemaker
        +                        +
       SBD                      SBD
        +                        +
    watchdog                 watchdog

One important caveat: SBD isn't magically hardware-independent. It depends on a fencing-capable watchdog and, in the traditional configuration, shared storage. Red Hat currently recommends a hardware watchdog where possible; software-emulated watchdogs such as softdog are supported but have weaker guarantees if the kernel/OS is severely starved or malfunctioning.

If you don't have shared storage, I'd instead use a power-based fence agent appropriate to whatever infrastructure you have (IPMI/iLO/iDRAC, cloud API, PDU, hypervisor API, etc.). A generic SSH-based “run shutdown on the other node” agent is not suitable for production STONITH because the exact failure you're fencing may leave SSH unusable or the node partially alive.

Bottom line:
Shared storage + watchdog available → fence_sbd is probably the best hardware-agnostic choice.
No shared storage → tell me whether these are bare metal, VMs, or cloud instances and I can recommend the most robust fence agent for that topology.