4.58. fence-agents

BZ#731166

Due to a change in REST API, the fence_rhevm utility incorrectly reported status "UP" as "RUNNING". Consequently, the "fence_rhevm -o status" command always reported "OFF". This bug has been fixed, and fence_rhevm now reports status correctly.

BZ#718924

The fence_drac5 agent failed to clear its SSH sessions on exit as expected by firmware. Consequently, the fence agent appeared to be still connected to the device, and once the connection limit was reached, further logins to the device were not allowed. This bug has been fixed, and fence_drac5 now clears its SSH sessions properly.

BZ#693428

The "monitor" and "status" commands of the fence_ipmilan agent returned chassis status instead of the fence device status. As a result, when a server chassis was powered off, the fence_ipmilan agent exited with the incorrect result code "2" when passed one of these commands. Now, fence_ipmilan returns the correct result code "0" in the described scenario.

BZ#708052

When a blade server was removed from a blade chassis and was fenced via the fence_bladecenter utility with the "--missing-as-off" option enabled, and was scheduled with the "reboot" action, the fence failed. This bug has been fixed, and fence_bladecenter no longer returns an error if a blade server is missing.

BZ#718196

A list operation on fence_drac5 agents resulted in unexpected termination of fence agents. A patch has been provided to address this issue, and fence_drac5 agents now work correctly in the described scenario.

BZ#718207

When the pyOpenSSL package was not present in the system, when an error occurred, the fence_ilo agent terminated with a generic error message, making it difficult to debug the problem. Now, fence_ilo reports that a dependent package is missing in the described scenario, thus fixing this bug.

BZ#732372

The verbose mode of the fence_ipmilan agent exposed user passwords when the whole command was logged by an IPMI tool. Now, the fence_ipmilan output has been changed, and passwords remain undisclosed in the described scenario.

BZ#738384

During simultaneous unfencing operations performed via the fence_scsi agent, all nodes launched their reservation commands at the same time. Consequently, some of the commands failed. Now, fence_scsi retries to unfence a node until its reservation command succeeds.

BZ#734429

A null dereference was discovered in the fence_kdump agent, when the strchr() function returned the NULL value. With this update, the dereference has been fixed in the code and no longer occurs.

BZ#624673

With this update, the new fence_vmware_soap() function has been provided to enable fencing of VMware guests in ESX environments.

BZ#461948

The fence_kdump utility has been updated to integrate fencing with the kernel dump environment.

BZ#698365

With this update, the RelaxNG schema generation for fence-agents has been updated with the rha:description and rha:name attributes in its output to fence attribute group elements.

BZ#726571

The fence_ipmilan agent has been updated to support the -L option of the ipmilan daemon, thus supporting fencing with user session privileges level.

BZ#785816

The fence_rhevm fencing agent uses the Red Hat Enterprise Virtualization API to check the power status ("on" or "off") of a virtual machine. In addition to the states of "up" and "down", the API includes other states like "unassigned", "powering_up", "paused", "migrating", "unknown", "not_responding", "wait_for_launch", "reboot_in_progress", "saving_state", "restoring_state", "suspended", "image_illegal", "image_locked" or "powering_down". Previously, only if the machine was in the "up" state, the "on" power status was returned. The "off" status was returned for all other states although the machine was actually running. This allowed for successful fencing even before the machine was really powered off. With this update, the fence_rhevm agent detects power status of a cluster node more conservatively, and the "off" status is returned only if the machine is really powered off, it means in the "off" state.

BZ#811873

Previously, the fence_vmware_soap fence agent did not expose the full path to a virtual machine that is required for fencing. With this update, fence_vmware_soap has been modified to support identification of virtual machines as expected.

BZ#814843

Previously, fencing a Red Hat Enterprise Linux cluster node with the fence_soap_vmware fence agent running in a virtual machine on VMWare could fail with the following error message:

KeyError: 'config.uuid'

This was because the fence agent was not able to work with more than one hundred machines in a cluster. With this update, the underlying source code has been modified to support fencing of such clusters.

Bug Fix

BZ#1012574

Prior to this update, the fence agent for IPMI (Intelligent Platform Management Interface) could return an invalid return code when the "-M cycle" option was used. This invalid return code could cause invalid interpretation of success of a fence action, eventually causing the cluster to become unresponsive. This bug has been fixed and only predefined return codes are now returned in the described scenario.