RDQM makes IBM MQ highly available by using DRBD disk replication and a cluster stack (Pacemaker/Corosync). That’s great – until a routine RHEL patch window updates the Linux kernel.

Here’s the hidden dependency: RDQM relies on a DRBD kernel module that must be compatible with the running kernel. If the kernel changes but the DRBD module does not, RDQM can’t load replication – and the node can’t host your queue manager. If multiple nodes are in that state, your HA queue manager may not start anywhere.

Update – August 20, 2026: IBM’s current RDQM kernel-module reference lists RHEL 9 kernel versions 5.14.0-570.12.1 through 5.14.0-570.15.1 as having known compatibility issues that require a new kernel module. IBM’s RHEL 7 and RHEL 8 rows currently show no known compatibility issues. Because IBM updates this information as kernels and MQ maintenance levels change, confirm the live reference before every maintenance window

You’ll usually see one or more of the following after a kernel update on one or more nodes:

• The queue manager fails over unexpectedly, or won’t start anywhere in the RDQM HA group.
• rdqmstatus shows the DRBD kernel module is only partially loaded, or shows a mismatch between OS kernel version and DRBD OS kernel version.
• drbdadm status or drbdsetup status fails because the drbd module can’t be found/loaded.
• Errors from the RDQM/DRBD component during start-up (for example AMQ3752E) that point to DRBD initialization problems.
• Pacemaker logs warn that the DRBD kernel module isn’t available.

If the RHEL kernel level changes, you may need a different validated DRBD (kmod-drbd) package for RDQM. Until the compatible DRBD module is installed for that kernel, RDQM resources on that node can’t run.

A failed queue manager is only the first visible symptom. Applications may lose access to required queues, channels may stop moving messages, and dependent integrations may begin timing out. If monitoring focuses only on whether the Linux server restarted, the maintenance window can appear successful while the messaging service remains unavailable.

The problem can also cross team boundaries. Linux administrators may see a healthy operating system, application teams may see failed transactions, and the MQ team may see a queue manager that will not start. Without shared visibility and a defined escalation path, each team can investigate its own layer before anyone connects the outage to the kernel change.

Kernel updates often occur during overnight or weekend maintenance windows, when fewer application owners and specialists are available. A clear MQ alert, paired with the time of the host restart, gives responders a much stronger starting point than a general report that an application cannot connect.

Before you approve the maintenance window, capture three things for every node:

• Current kernel level (and the target kernel level you plan to reboot into).
• Current RDQM / DRBD status (so you can prove “good” before you change anything).
• Which DRBD kernel module is validated for the target kernel level (and whether your current MQ maintenance level supports it).

Commands you can use to capture this baseline:

To validate kernel-module compatibility, IBM provides a public “RDQM kernel modules” reference page and a helper script called modver. It can tell you which DRBD kernel module is required for a given kernel level, and (with newer versions) can also show the minimum MQ maintenance level required.

Note: The modver utility is included in the IBM MQ installation media and subsequent iFix bundles (from version 9.2+)

Practical approach:

• Look up your target kernel level in IBM’s RDQM kernel-module reference (or JSON metadata).
  Run modver to confirm which kmod-drbd package matches that kernel level.
• If modver indicates a minimum MQ maintenance level, confirm you meet it before the window.
• Download only the validated kernel-module bundle for your MQ level and install it per IBM guidance.

Tip: Disable unattended kernel updates (or at least gate kernel packages) so the OS kernel doesn’t drift ahead of the available validated RDQM kernel module.

Some IBM MQ maintenance levels ship a helper script called updateRDQMsupport. When present, it can automate updating RDQM support packages (including DRBD kernel modules and related cluster components) so they match the kernel you’re moving to. If you have it in your installation, run it as root on each RDQM node as part of your pre-reboot steps – and still validate the result with rdqmstatus after the reboot.

If you don’t have updateRDQMsupport (or your version’s docs don’t use it), the modver + validated-kernel workflow above is still the safe way to avoid guessing.

Every environment is different, so follow IBM’s docs and your own change controls. The key pattern is: keep at least one good node available, and make sure the node has the compatible DRBD module installed before it becomes eligible to host the queue manager.

A typical rolling approach for a 3-node RDQM HA group:

1. Fail over the queue manager away from the node you are about to patch (so it’s not the active host).
2. On the node to be patched: apply OS updates, install/upgrade the validated DRBD kernel module for the target kernel, then reboot into the target kernel.
3. After reboot: verify rdqmstatus and DRBD state. Only then make the node eligible again (or proceed to the next node).
4. Repeat node-by-node until all nodes are patched.

One more gotcha that shows up in real-world RDQM patch windows: if your OS patching process pulls in unexpected updates to Pacemaker/Corosync/resource-agents, you can introduce new variables in the same window. If your plan is “OS patches only,” consider gating or excluding cluster-stack packages unless you are explicitly coordinating that upgrade with IBM’s RDQM guidance.

If you patch via yum/dnf, consider an explicit exclude list (example):

“The queue manager started” isn’t enough. Validate these in order:

• RDQM/DRBD health (rdqmstatus shows the module loaded and no kernel mismatch symptoms).
• Queue manager status and listeners.
• An end-to-end canary or synthetic transaction that uses the relevant message headers and confirms the expected downstream processing – not merely a successful put/get.
• Failover behavior (if your change plan includes it) – confirm the standby node can take over cleanly.

Record the results with the change ticket so the team has a known-good RHEL, IBM MQ, and RDQM combination for the next maintenance cycle. That evidence is more useful than a server-level health check because it proves the messaging service the business actually depends on.

Infrared360 does not install or update IBM’s RDQM kernel module, and it cannot make an incompatible module work. Its role begins where the compatibility failure becomes an operational incident: at the MQ layer.

After maintenance, Infrared360 gives the MQ team an immediate view of queue manager status across the environment and supports alerts based on queue manager state. That makes it possible to confirm whether expected queue managers returned to service instead of relying on manual checks or waiting for an application user to report a problem.

• Immediate status confirmation: See queue manager state and Primary Host information across the environment.
• MQ-specific impact context: Examine queue and channel status, connection activity, message counts, message age, command server status, and related MQ conditions from the same interface.
• Targeted notification: Route critical events through email, SNMP, or third-party integrations so the appropriate responders receive the alert.
• Governed response: Use Trusted Spaces role-based visibility and permissions, audit logging, and approved alert actions or automated workflows with appropriate guardrails.
• End-to-end verification: Use synthetic transactions after maintenance to validate a message path instead of stopping at a green server status.

The correct IBM-supported module fixes the technical incompatibility. Infrared360 helps reduce the detection and response gap by showing whether MQ recovered, alerting the appropriate responders, and providing the MQ context needed to act quickly and safely.

If you want a one-page, printable version of the workflow above (pre-flight, execution, post-checks, rollback triggers), grab the checklist here:

Download the IBM MQ HA Maintenance Window Checklist

Do I need a new DRBD kernel module every time the kernel changes?
Not always – but you must confirm your target kernel level is compatible with an available validated RDQM DRBD module. Use IBM’s kernel-module reference and modver to avoid guessing.

What if the target kernel level is listed as incompatible or under test?
Treat that as a stop sign for production HA. Either hold the kernel update, or coordinate the maintenance window with the validated module availability and MQ maintenance level.

Can I make this less fragile long-term?
Yes: gate kernel updates, standardize a pre-flight checklist, and automate the “compare target kernel -> required kmod -> minimum MQ level” decision so it’s repeatable.

Can Infrared360 install or update the RDQM kernel module?
No. Administrators must obtain and install the appropriate IBM-supported module. Infrared360 monitors and manages the MQ layer, helping teams detect an unavailable queue manager, examine the impact, and coordinate the response.

What should teams verify after a RHEL kernel upgrade?
Verify the running kernel, the appropriate RDQM module, queue manager and RDQM status, listeners, channels, queues, connections, and an end-to-end application or synthetic message path.