OCF_HEARTBEAT_OVSMON(7)

💖 OCF_HEARTBEAT_OVSMON(7) — the ocf_heartbeat_ovsmonitor page, bestie edition 💖

okay so this is a page from the OCF resource agents manual, and honestly? it's giving "niche but slay." let's get into it ✨

---

🌸 NAME 🌸

ocf_heartbeat_ovsmonitor — literally just here to monitor ovs bonding bonds. no cap. 👑

---

✨ SYNOPSIS ✨

ovsmonitor [start | stop | status | monitor | meta-data | validate-all]

that's it. that's the whole vibe check. 🎀

---

🦋 DESCRIPTION 🦋

so the whole point of this icon: it monitors the vitality of a local ovs bond. that's the gig. 💅

you may set this RA up as a clone resource to monitor the network bonds on different nodes — with the same bond name. and listen, this is not related to the IP address or the network on which a bond is configured, okay? those are different things, don't mix them. you can use this RA to move resources away from a node that has a faulty bond, or to prevent moving resources to such a node at all. it's giving independent control of your resources, without involving cluster intercommunication. 🫶 but — and this is the catch — it requires your nodes to have more than one network bond. more than one. periodt.

the resource configuration requires a monitor operation, because the monitor is the one doing the main part of the work. main character energy, honestly. in addition to the resource configuration, you also need to configure some location constraints, based on a CIB attribute value. and the name of that attribute value is configured in the name option of this RA. iykyk 💫

example constraint configuration using crmsh:

location loc_connected_node my_resource_grp rule ="rule_loc_connected_node" -INF: ovsmonitor-bond-public eq 0

example constraint configuration using pcs — only allow my_resource to run on nodes where the eth0 ethernet device is available:

pcs constraint location my_resource rule score=-INFINITY ovsmonitor-bond-public ne 1

now, the ethmonitor works in 3 different modes to test the bond vitality (yes, it says "ethmonitor" in the source, we're keeping it, faithful besties only):

1. call ovs-appctl to see if at least one of the bonding's link status is up (if link is down → error)
2. call ovs-ofctl and watch the RX counter (if packets come around in a certain time → success)
3. return error

three modes, one bond, so much drama. 🔥

---

💜 SUPPORTED PARAMETERS 💜

• bond — the name of the network bond that should be monitored (e.g. bond-public). the whole reason we're here fr. (unique, required, string, no default)
• bridge — the name of the ovs bridge that contains the bridge. yes that's how it's worded, and no i'm not gonna "fix" it, we keep it exactly. 🫡 (unique, required, string, no default)
• name — the name of the CIB attribute to set. this is the name to be used in the constraints. defaults to "ovsmonitor-'bond_name'". it's the one your constraints point at, so don't lose it 💀 (unique, optional, string, no default)
• multiplier — multiplier for the value of the CIB attribute specified in parameter name. multiply responsibly ✨ (optional, integer, default 1)
• repeat_count — specify how often the bond will be monitored, before the status is set to failed. and heads up: you need to set the timeout of the monitoring operation to at least repeat_count * repeat_interval. do the math bestie, or your monitor op will ghost you 😭 (optional, integer, default 5)
• repeat_interval — specify how long to wait, in seconds, between the repeat_counts. the pause between the chaos. ⏳ (optional, integer, default 10)
• pktcnt_timeout — timeout for the RX packet counter. stop listening for packet counter changes after the given number of seconds. it's not ghosting, it's a deadline. 🎀 (optional, integer, default 5)
• link_status_only — only report success based on link status. do not perform RX counter related connectivity tests. short and sweet, no extra credit. 🦋 (optional, boolean, default false)

---

👑 SUPPORTED ACTIONS 👑

this resource agent supports the following actions (operations), and yes, every single one of them has a suggested minimum timeout, so let's go:

• start — starts the resource. suggested minimum timeout: 60s.
• stop — stops the resource. suggested minimum timeout: 20s.
• status — performs a status check. suggested minimum timeout: 60s. suggested interval: 10s.
• monitor — performs a detailed status check. suggested minimum timeout: 60s. suggested interval: 10s. this is the main character, remember.
• meta-data — retrieves resource agent metadata (internal use only). suggested minimum timeout: 5s. don't touch, it's for the internals 💅
• validate-all — performs a validation of the resource configuration. suggested minimum timeout: 20s.

---

🍓 EXAMPLE CRM SHELL 🍓

here's an example configuration for a ovsmonitor resource using the crm(8) shell — copy, paste, slay:

primitive p_ovsmonitor ocf:heartbeat:ovsmonitor \
  params \
    bond=string \
    bridge=string \
  op monitor depth="0" timeout="60s" interval="10s"

---

🌈 EXAMPLE PCS 🌈

and here's the same energy for a ovsmonitor resource using pcs(8):

pcs resource create p_ovsmonitor ocf:heartbeat:ovsmonitor \
  bond=string \
  bridge=string \
  op monitor OCF_CHECK_LEVEL="0" timeout="60s" interval="10s"

pick your tool, both ate. 🔥

---

⭐ SEE ALSO ⭐

• http://clusterlabs.org/ — go be nosy, bestie 🌸

---

🧚 AUTHOR 🧚

ClusterLabs contributors (see the resource agent source for information about individual authors) 🫶

---

okay and for the cute sign-off: this whole thing is from resource-agents, version UNKNOWN (iconic of them honestly), dated 10/01/2026. and that's the page, mwah 💋💖