- 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, cman did not handle idle connection timeout correctly when fencing a cluster node. Consequently, a connection to a fence device timed out and fencing failed if the "delay" option was set to more than 5 seconds. With this update, the "delay" option is applied before the connection is opened and the fencing thus no longer fails in this scenario.
- The speed of fencing is critical because otherwise, broken nodes have more time to corrupt data. Previously, the operation of the fence_vmware_soap fencing agent was slow when used on the VMWare vSphere platform with hundreds of virtual machines. This update fixes a problem with virtual machines that do not have a valid UUID, which can be created during failed P2V (Physical-to-Virtual) processes. Now, the fencing process is also much faster and it does not terminate if a virtual machines without an UUID is encountered.
- With this update, several typographical errors in the
fence/agents/scsi/fence_scsi.plfile have been fixed. As a result, the debug messages of this file are now typographically correct.
- Prior to this update, the VMware vSphere 5.0 SOAP API was not listed as a version supported by the fence_vmware_soap fence agent. Consequently, the fence agent did not function properly with virtual machines managed by VMware vSphere 5.0. With this update, VMware vSphere 5.0 has been added to the list of supported interfaces, and is fully compatible with fence_vmware_soap.
- Previously, the
fence_scsiman page contained incorrect information about the limitations of the fence_scsi agent. The correct description of these limitations can be found in the in the Cluster Administration guide. With this update, the misleading section has been removed from the manual page in order to avoid the potential confusion.
- Prior to this update, when attempting to create registrations on a multipath device with the
fence_scsi_test -ocommand, some registrations failed without signalization. Consequently, there was a need to verify that all registrations had been successfully created. With this update, a
--strictoption has been added into the fence_scsi_test program. This option forces the verification step to compare the number of paths to the number of times the registration key appears on the device. Without this option, the verification step only inspects the existence of a registration key on the device. Although it is usually safe to omit the
--strictoption, it is strongly recommended to use
--stricton multipath devices.
- 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", "paused", etc. (14 in sum). Previously, only when the machine was in the "up" state, the "on" power status was returned. The "off" status was returned for all other states even though the machine was actually running. This behavior allowed for successful fencing even before the machine was powered off. The bug has been fixed and the "off" status is now returned only in a case the machine is in the "off" state.
- Previously, the cman utility did not apply the
--delayoption correctly when fencing a cluster node. Consequently, a connection to a fence device timed out and fencing failed when
--delaywas set to more than 5 seconds. With this update,
--delayis applied before the connection is opened and the fencing no longer fails in the described scenario.
- Prior to this update, when the
method namesetting was left empty in the
/etc/cluster/cluster.confconfiguration file, an unintended core file was created. Consequently, a fenced cloud terminated with a segmentation fault. This bug has been fixed, and the termination no longer occurs in the aforementioned scenario.
- Due to a bug in the
fence_scsi_testfunction, failing to create a reservation led to an incorrect reset of the error count to zero. The bug has been fixed, and the error count is now incremented properly when the error occurs.
- Previously, the fence_vmware_soap fencing agent operated slowly on the VMware vSphere platform with hundreds of virtual machines (VM). This behavior was caused by requesting for needless attributes. With this update, the unnecessary requests have been removed. This update also handles the VMs with invalid UUIDs, which can occur as a result of the failed P2V (physical to virtual machine) process. As a result, fence_vmware_soap performs fencing with increased speed and the process is no longer terminated when a VM without an UUID is encountered.
- In certain cases, the fence_xvm fencing agent incorrectly reported successful fencing, and ignored a communication issue between the agent and the fence_xvmd fencing host. This bug has been fixed and the communication errors are now reported correctly.
- The new href attribute on the /vms/vm element in the Red Hat Enterprise Virtualization Manager 3.1 API caused the get_id regular expression of the fence_rhevm fencing agent to fail. Consequently, the plug status was not available. With this update, get_id has been modified to allow arbitrary attributes to be added to the element. As a result, the plug status is now correctly shown.
- RHEL5 Cluster Suite now supports using RHEV shared storage disks as the shared storage between cluster nodes. Highly Available Logical Volume Manager (HA-LVM), Clustered Logical Volume Manager (CLVM), and the qDisk daemon are all supported on this storage. Fencing via
fence_scsiwill not work as shared disks are only exposed as VirtIO or IDE devices.
- A new fence agent, fence_ipdu, that handles the IBM iPDU fence device over the Simple Network Management Protocol (SNMP) has been added. As a result, the cman package now provides compatibility with IBM iPDU.
- Previously, using the qdiskd daemon for multipath devices required tuning with the device-mapper-multipath tool, which was a complex and error-prone process. With this update, the qdiskd input and output operations have been improved to automatically detect the multipath-related timeouts without requiring a manual configuration. As a result, qdiskd can now be easily deployed with device-mapper-multipath.
- Various cman fence agents differ in handling of the end-of-line (EOL) markers. Previously, changing the universal
\r\nEOL could make the login process impossible for the fence agent. With this update, an automatic detection of EOL has been added to a fencing library and the described error no longer occurs.
- Prior to this update, it was not possible to specify more than four fencing devices per method with the cman utility. With this update, the maximum number of devices per method has increased to eight.
- The Distributed Lock Manager (DLM) now allows tuning of DLM hash table sizes from the
/etc/sysconfig/cmanfile. The following parameters can be set in the
<size_of_table>which, in turn, modifies the values in the following files respectively:
/sys/kernel/config/dlm/cluster/lkbtbl_size /sys/kernel/config/dlm/cluster/rsbtbl_size /sys/kernel/config/dlm/cluster/dirtbl_size
- Previously, it was not possible to modify the default TCP port (21064) of the Distributed Lock Manager (DLM). With this update, the
DLM_TCP_PORTconfiguration parameter has been added into the
/etc/sysconfig/cmanfile. As a result, the DLM TCP port can be manually configured.
- Support for clusters utilizing VMware's VMDK disk image technology with the
multi-writeroption is now provided. It is now possible to deploy Global File System 2 (GFS2) on top of VMDK.