Chapter 61. Storage No support for thin provisioning on top of RAID in a cluster While RAID logical volumes and thinly provisioned logical volumes can be used in a cluster when activated exclusively, there is currently no support for thin provisioning on top of RAID in a cluster. This is the case even if the combination is activated exclusively. Currently this combination is only supported in LVM's single machine non-clustered mode. (BZ# 1014758 ) Interaction problems with the lvmetad daemon when mirror segment type is used. When the legacy mirror segment type is used to create mirrored logical volumes with 3 or more legs, there can be interaction problems with the lvmetad daemon. Problems observed occur only after a second device failure, when mirror fault policies are set to the non-default allocate option, when lvmetad is used, and there has been no reboot of the machine between device failure events. The simplest workaround is to disable lvmetad by setting use_lvmetad = 0 in the lvm.conf file. These issues do not arise with the raid1 segment type, which is the default type for Red Hat Enterprise Linux 7. (BZ# 1380521 ) Important restrictions for Red Hat Enterprise Linux 7.3 upgrades on systems with RAID4 and RAID10 logical volumes The following important restrictions apply to Red Hat Enterprise Linux 7.3 upgrades on systems with RAID4 and RAID10 logical volumes: Do not upgrade any systems with existing LVM RAID4 or RAID10 logical volumes to Red Hat Enterprise Linux 7.3 because these logical volumes will fail to activate. All other types are unaffected. If you do not have any existing RAID4 or RAID10 logical volumes and you upgrade, do not create any new RAID4 logical volumes because those may fail to activate with later releases and updates. It is safe to create RAID10 logical volumes on Red Hat Enterprise Linux 7.3. A z-stream fix is being worked on to allow for the activation of existing RAID4 and RAID10 logical volumes and the creation of new RAID4 logical volumes with Red Hat Enterprise Linux 7.3. (BZ#1385149) The system sometimes becomes unresponsive if there are no working network paths to the iSCSI target When using iSCSI targets, it is required to have a continuous multipathing from initiator to target, as it is required for zfcp attached SCSI logical unit number (LUNs). If swap is on iSCSI and the system is under memory pressure when an error recovery occurs in the network path, then the system needs some additional memory for the error recovery. As a consequence, the system can become unresponsive. To work around this problem, have at least one working network path to the iSCSI target to make obtaining memory from swap possible. (BZ#1389245) Exit code returned from the lvextend command has changed Previously, if the lvextend or lvresize commands were run in a way that would result in no change to the size of the logical volume, an attempt was still made to resize the file system. The unnecessary attempt to resize the file system is no longer made and this has caused the exit code of the command to change. LVM makes no guarantees of the consistency of exit codes beyond zero (success) and non-zero (failure). (BZ# 1354396 )

Commands: