- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- With this update, the new fence_vmware_soap() function has been provided to enable fencing of VMware guests in ESX environments.
- The fence_kdump utility has been updated to integrate fencing with the kernel dump environment.
- 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.
- The fence_ipmilan agent has been updated to support the -L option of the ipmilan daemon, thus supporting fencing with user session privileges level.
- 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.
- 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.
- 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.
- 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.