RHEL8 Update6 platform support patch

Translation Notice

Please note that this content includes text that has been machine-translated from English. Veritas does not guarantee the accuracy regarding the completeness of the translation. You may also refer to the English Version of this knowledge base article for up-to-date information.

RHEL8 Update6 platform support patch

Patch

Update ID: UPD356743

Version: 7.4.1.3200

Platform: Linux

Release date: 2022-09-08

Abstract

RHEL8 Update6 platform support patch

Description

SORT ID: 18798

Fixes the below incidents:

4085646,4050664,4051040,4054272,4054697,4058763,4053179,4022791,4029112,4037049,3999398,4002584,4003442,4010546,
4016483,4019676,4012089,4002151,3990017,4087567,4056672,3983992,4052886,4040934,4037955,4018202,4011973,4001381,
3989416,4062578,3984175,4011097,4039527,4045494,4051815,4051887,4051889,4051896,4055653,4055660,4055668,4055697,
4055772,4055895,4055899,4055905,4055925,4055938,4056107,4056124,4056144,4056146,4056832,3984156,4041285,4042039,
4050892,4051457,4051968,4051985,4053231,4017284,4039240,4039242,4039244,4039249,4039525,4039526,4040842,4044174,
4045502,4013643,4023762,4031342,4033162,4033163,4033172,4033173,4033216,4033515,4035313,4036426,4037331,4037810,
3984155,4016283,4016291,4016768,4017194,4017502,4019781,3984163,4010517,4010996,4011027,4011105,3992902,3997906,
4000388,4001399,4001736,4001745,4001746,4001748,4001750,4001752,4001755,4001757,3984139,3984731,3988238,3988843,
4085648,4054323,4045476,4053181,4044340,4037950,4019003,4019679,4002154,3990020,4085614,4051532,4053182,4028780,
4037951,4000746,4019680,4085645,4054264,4054265,4060792,4053180,4037949,4016486,4016487,4019677,4002152,3990018

Patch IDs:

VRTSamf-7.4.1.3500-RHEL8 for VRTSamf
VRTSgab-7.4.1.3400-RHEL8 for VRTSgab
VRTSllt-7.4.1.3400-RHEL8 for VRTSllt
VRTSodm-7.4.1.3500-RHEL8 for VRTSodm
VRTSvxfen-7.4.1.3400-RHEL8 for VRTSvxfen
VRTSvxfs-7.4.1.3500-RHEL8 for VRTSvxfs
VRTSvxvm-7.4.1.3400-RHEL8 for VRTSvxvm

* * * READ ME * * *
* * * InfoScale 7.4.1 * * *
* * * Patch 3200 * * *
Patch Date: 2022-09-02

This document provides the following information:

* PATCH NAME
* OPERATING SYSTEMS SUPPORTED BY THE PATCH
* PACKAGES AFFECTED BY THE PATCH
* BASE PRODUCT VERSIONS FOR THE PATCH
* SUMMARY OF INCIDENTS FIXED BY THE PATCH
* DETAILS OF INCIDENTS FIXED BY THE PATCH
* INSTALLATION PRE-REQUISITES
* INSTALLING THE PATCH
* REMOVING THE PATCH

PATCH NAME
----------
InfoScale 7.4.1 Patch 3200

OPERATING SYSTEMS SUPPORTED BY THE PATCH
----------------------------------------
RHEL8 x86-64

PACKAGES AFFECTED BY THE PATCH
------------------------------
VRTSamf
VRTSgab
VRTSllt
VRTSodm
VRTSvxfen
VRTSvxfs
VRTSvxvm

BASE PRODUCT VERSIONS FOR THE PATCH
-----------------------------------
* InfoScale Availability 7.4.1
* InfoScale Enterprise 7.4.1
* InfoScale Foundation 7.4.1
* InfoScale Storage 7.4.1

SUMMARY OF INCIDENTS FIXED BY THE PATCH
---------------------------------------
Patch ID: VRTSllt-7.4.1.3400
* 4085646 (4072335) Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 6(RHEL8.6).
Patch ID: VRTSllt-7.4.1.3300
* 4050664 (4046199) LLT configurations over UDP accept only ethernet interface names as link tag names.
* 4051040 (3989372) When the CPU load and memory consumption is high in a VMware environment, some nodes in an InfoScale cluster may get fenced out.
* 4054272 (4045607) Performance improvement of the UDP multiport feature of LLT on 1500 MTU-based networks.
* 4054697 (3985775) Sometimes, the system log may get flooded with LLT heartbeat loss messages that do not necessarily indicate any actual issues with LLT.
* 4058763 (4057310) After an InfoScale upgrade, the updated values of LLT and GAB tunables that are used when loading the corresponding modules fail to persist.
Patch ID: VRTSllt-7.4.1.3200
* 4053179 (4053171) Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 5(RHEL8.5).
Patch ID: VRTSllt-7.4.1.2900
* 4022791 (4022792) A cluster node panics during an FSS I/O transfer over LLT.
* 4029112 (4029253) LLT may not reuse the buffer slots on which NAK is received from the earlier RDMA writes.
* 4037049 (4037048) Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 4(RHEL8.4).
Patch ID: VRTSllt-7.4.1.2800
* 3999398 (3989440) The dash (-) in the device name may cause the LLT link configuration to fail.
* 4002584 (3994996) Adding -H miscellaneous flag to add new functionalities in lltconfig. Add a tunable to allow skb alloc with SLEEP flag.
* 4003442 (3983418) In a rare case, after a panic or a reboot of a node, it may fail to join the CVM master due to an inconsistent LLT port state on the master.
* 4010546 (4018581) The LLT module fails to start and the system log messages indicate missing IP address.
* 4016483 (4016484) The vxexplorer utility panics the node on which it runs if the LLT version on the node is llt-rhel8_x86_64-Patch-7.4.1.2100 or later.
* 4019676 (4019674) Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8 Update 3(RHEL8.3).
Patch ID: VRTSllt-7.4.1.2200
* 4012089 (4002150) Veritas Cluster Server does not support Red Hat Enterprise Linux 8 Update 2(RHEL8.2).
Patch ID: VRTSllt-7.4.1.2100
* 4002151 (4002150) Veritas Cluster Server does not support Red Hat Enterprise Linux 8 Update 2(RHEL8.2).
Patch ID: VRTSllt-7.4.1.1600
* 3990017 (3990016) Veritas Cluster Server does not support Red Hat Enterprise Linux 8
Update 1(RHEL8.1).
Patch ID: VRTSodm-7.4.1.3500
* 4087567 (4087566) VRTSodm driver will not load with VRTSvxfs patch.
Patch ID: VRTSodm-7.4.1.3400
* 4056672 (4056673) Rebooting the system results into emergency mode due to corruption of module dependency files. Incorrect vxgms dependency in odm service file.
Patch ID: VRTSodm-7.4.1.3200
* 3983992 (3868609) High CPU usage by vxfs thread.
* 4052886 (4052885) ODM support for RHEL 8.5.
Patch ID: VRTSodm-7.4.1.3100
* 4040934 (4040933) VRTSodm driver will not load with VRTSvxfs patch.
Patch ID: VRTSodm-7.4.1.2900
* 4037955 (4037575) ODM module failed to load on RHEL8.4
Patch ID: VRTSodm-7.4.1.2800
* 4018202 (4018200) ODM module failed to load on RHEL8.3
Patch ID: VRTSodm-7.4.1.2600
* 4011973 (4012094) VRTSodm driver will not load with 7.4.1.2600 VRTSvxfs patch.
Patch ID: VRTSodm-7.4.1.2100
* 4001381 (4001380) ODM module failed to load on RHEL8.2
Patch ID: VRTSodm-7.4.1.1600
* 3989416 (3989415) ODM module failed to load on RHEL8.1
Patch ID: VRTSvxvm-7.4.1.3400
* 4062578 (4062576) hastop -local never finishes on Rhel8.4 and RHEL8.5 servers with latest minor kernels due to hang in vxdg deport command.
Patch ID: VRTSvxvm-7.4.1.3300
* 3984175 (3917636) Filesystems from /etc/fstab file are not mounted automatically on boot through systemd on RHEL7 and SLES12.
* 4011097 (4010794) When storage activity was going on, Veritas Dynamic Multi-Pathing (DMP) caused system panic in a cluster.
* 4039527 (4018086) The system hangs when the RVG in DCM resync with SmartMove is set to ON.
* 4045494 (4021939) The "vradmin syncvol" command fails due to recent changes related to binding sockets without specifying IP addresses.
* 4051815 (4031597) vradmind generates a core dump in __strncpy_sse2_unaligned.
* 4051887 (3956607) A core dump occurs when you run the vxdisk reclaim command.
* 4051889 (4019182) In case of a VxDMP configuration, an InfoScale server panics when applying a patch.
* 4051896 (4010458) In a Veritas Volume Replicator (VVR) environment, the rlink might inconsistently disconnect due to unexpected transactions.
* 4055653 (4049082) I/O read error is displayed when remote FSS node rebooting.
* 4055660 (4046007) The private disk region gets corrupted if the cluster name is changed in FSS environment.
* 4055668 (4045871) vxconfigd crashed at ddl_get_disk_given_path.
* 4055697 (4047793) Unable to import diskgroup even replicated disks are in SPLIT mode
* 4055772 (4043337) logging fixes for VVR
* 4055895 (4038865) The system panics due to deadlock between inode_hash_lock and DMP shared lock.
* 4055899 (3993242) vxsnap prepare command when run on vset sometimes fails.
* 4055905 (4052191) Unexcepted scripts or commands are run due to an incorrect comments format in the vxvm-configure script.
* 4055925 (4031064) Master switch operation is hung in VVR secondary environment.
* 4055938 (3999073) The file system corrupts when the cfsmount group goes into offline state.
* 4056107 (4036181) Volumes that are under a RVG (Replicated Volume Group), report an IO error.
* 4056124 (4008664) System panic when signal vxlogger daemon that has ended.
* 4056144 (3906534) After Dynamic Multi-Pathing (DMP) Native support is enabled, /boot should to be mounted on the DMP device.
* 4056146 (3983832) VxVM commands hang in CVR environment.
* 4056832 (4057526) Adding check for init while accessing /var/lock/subsys/ path in vxnm-vxnetd.sh script.
Patch ID: VRTSvxvm-7.4.1.3200
* 3984156 (3852146) A shared disk group (DG) fails to be imported when "-c" and "-o noreonline" are specified together.
* 3984175 (3917636) Filesystems from /etc/fstab file are not mounted automatically on boot
through systemd on RHEL7 and SLES12.
* 4041285 (4044583) A system goes into the maintenance mode when DMP is enabled to manage native devices.
* 4042039 (4040897) Add support for HPE MSA 2060 arrays in the current ASL.
* 4050892 (3991668) In a Veritas Volume Replicator (VVR) configuration where secondary logging is enabled, data inconsistency is reported after the "No IBC message arrived" error is encountered.
* 4051457 (3958062) After a boot LUN is migrated, enabling and disabling dmp_native_support fails.
* 4051815 (4031597) vradmind generates a core dump in __strncpy_sse2_unaligned.
* 4051887 (3956607) A core dump occurs when you run the vxdisk reclaim command.
* 4051889 (4019182) In case of a VxDMP configuration, an InfoScale server panics when applying a patch.
* 4051896 (4010458) In a Veritas Volume Replicator (VVR) environment, the rlink might inconsistently disconnect due to unexpected transactions.
* 4051968 (4023390) Vxconfigd keeps dump core as invalid private region offset on a disk.
* 4051985 (4031587) Filesystems are not mounted automatically on boot through systemd.
* 4053231 (4053230) VxVM support for RHEL 8.5
Patch ID: VRTSvxvm-7.4.1.3100
* 4017284 (4011691) High CPU consumption on the VVR secondary nodes because of high pending IO load.
* 4039240 (4027261) World writable permission not required for /var/VRTSvxvm/in.vxrsyncd.stderr and /var/adm/vx/vxdmpd.log
* 4039242 (4008075) Observed with ASL changes for NVMe, This issue observed in reboot scenario. For every reboot machine was hitting panic And this was happening in loop.
* 4039244 (4010612) This issue observed for NVMe and ssd. where every disk has separate enclosure like nvme0, nvme1... so on. means every nvme/ssd disks names would be
hostprefix_enclosurname0_disk0, hostprefix_enclosurname1_disk0....
* 4039249 (3984240) AIX builds were failing on AIX7.2
* 4039525 (4012763) IO hang may happen in VVR (Veritas Volume Replicator) configuration when SRL overflows for one rlink while another one rlink is in AUTOSYNC mode.
* 4039526 (4034616) vol_seclog_limit_ioload tunable needs to be enabled on Linux only.
* 4040842 (4009353) Post enabling dmp native support machine is going in to mantaince mode
* 4044174 (4044072) I/Os fail for NVMe disks with 4K block size on the RHEL 8.4 kernel.
* 4045494 (4021939) The "vradmin syncvol" command fails due to recent changes related to binding sockets without specifying IP addresses.
* 4045502 (4045501) The VRTSvxvm and the VRTSaslapm packages fail to install on Centos 8.4 systems.
Patch ID: VRTSvxvm-7.4.1.2900
* 4013643 (4010207) System panicked due to hard-lockup due to a spinlock not released properly during the vxstat collection.
* 4023762 (4020046) DRL log plex gets detached unexpectedly.
* 4031342 (4031452) vxesd core dump in esd_write_fc()
* 4033162 (3968279) Vxconfigd dumping core for NVME disk setup.
* 4033163 (3959716) System may panic with sync replication with VVR configuration, when the RVG is in DCM mode.
* 4033172 (3994368) vxconfigd daemon abort cause I/O write error
* 4033173 (4021301) Data corruption issue observed in VxVM on RHEL8.
* 4033216 (3993050) vxdctl dumpmsg command gets stuck on large node cluster
* 4033515 (3984266) DCM flag in on the RVG volume may get deactivated after a master switch, which may cause excessive RVG recovery after subsequent node reboots.
* 4035313 (4037915) VxVM 7.4.1 support for RHEL 8.4 compilation errors
* 4036426 (4036423) Race condition while reading config file in docker volume plugin caused the issue in Flex Appliance.
* 4037331 (4037914) BUG: unable to handle kernel NULL pointer dereference
* 4037810 (3977101) Hitting core in write_sol_part()
Patch ID: VRTSvxvm-7.4.1.2800
* 3984155 (3976678) vxvm-recover: cat: write error: Broken pipe error encountered in syslog.
* 4016283 (3973202) A VVR primary node may panic due to accessing already freed memory.
* 4016291 (4002066) Panic and Hang seen in reclaim
* 4016768 (3989161) The system panic occurs when dealing with getting log requests from vxloggerd.
* 4017194 (4012681) If vradmind process terminates due to some reason, it is not properly restarted by RVG agent of VCS.
* 4017502 (4020166) Vxvm Support on RHEL8 Update3
* 4019781 (4020260) Failed to activate/set tunable dmp native support for Centos 8
Patch ID: VRTSvxvm-7.4.1.2700
* 3984163 (3978216) 'Device mismatch warning' seen on boot when DMP native support is enabled with LVM snapshot of root disk present
* 4010517 (3998475) Unmapped PHYS read I/O split across stripes gives incorrect data leading to data corruption.
* 4010996 (4010040) Configuring VRTSvxvm package creates a world writable file: /etc/vx/.vxvvrstatd.lock
* 4011027 (4009107) CA chain certificate verification fails in SSL context.
* 4011097 (4010794) Veritas Dynamic Multi-Pathing (DMP) caused system panic in a cluster while there were storage activities going on.
* 4011105 (3972433) IO hang might be seen while issuing heavy IO load on volumes having cache objects.
Patch ID: VRTSvxvm-7.4.1.2200
* 3992902 (3975667) Softlock in vol_ioship_sender kernel thread
* 3997906 (3987937) VxVM command hang may happen when snapshot volume is configured.
* 4000388 (4000387) VxVM support on RHEL 8.2
* 4001399 (3995946) CVM Slave unable to join cluster - VxVM vxconfigd ERROR V-5-1-11092 cleanup_client: (Memory allocation failure) 12
* 4001736 (4000130) System panic when DMP co-exists with EMC PP on rhel8/sles12sp4.
* 4001745 (3992053) Data corruption may happen with layered volumes due to some data not re-synced while attaching a plex.
* 4001746 (3999520) vxconfigd may hang waiting for dmp_reconfig_write_lock when the DMP iostat tunable is disabled.
* 4001748 (3991580) Deadlock may happen if IO performed on both source and snapshot volumes.
* 4001750 (3976392) Memory corruption might happen in VxVM (Veritas Volume Manager) while processing Plex detach request.
* 4001752 (3969487) Data corruption observed with layered volumes when mirror of the volume is detached and attached back.
* 4001755 (3980684) Kernel panic in voldrl_hfind_an_instant while accessing agenode.
* 4001757 (3969387) VxVM(Veritas Volume Manager) caused system panic when handle received request response in FSS environment.
Patch ID: VRTSvxvm-7.4.1.1600
* 3984139 (3965962) No option to disable auto-recovery when a slave node joins the CVM cluster.
* 3984731 (3984730) VxVM logs warning messages when the VxDMP module is stopped or removed for the first time after the system is rebooted
* 3988238 (3988578) Encrypted volume creation fails on RHEL 8
* 3988843 (3989796) RHEL 8.1 support for VxVM
Patch ID: VRTSamf-7.4.1.3500
* 4085648 (4072335) Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 6(RHEL8.6).
Patch ID: VRTSamf-7.4.1.3400
* 4054323 (4001565) On Solaris 11.4, IMF fails to provide notifications when Oracle processes stop.
Patch ID: VRTSamf-7.4.1.3300
* 4045476 (4041596) A cluster node panics when the arguments passed to a process that is registered with AMF exceeds 8K characters.
* 4053181 (4053171) Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 5(RHEL8.5).
Patch ID: VRTSamf-7.4.1.3200
* 4044340 (4041703) The system panics when the Mount and the CFSMount agents fail to register with AMF.
Patch ID: VRTSamf-7.4.1.2900
* 4037950 (4037048) Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 4(RHEL8.4).
Patch ID: VRTSamf-7.4.1.2800
* 4019003 (4018791) A cluster node panics when the AMF module attempts to access an executable binary or a script using its absolute path.
* 4019679 (4019674) Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8 Update 3(RHEL8.3).
Patch ID: VRTSamf-7.4.1.2100
* 4002154 (4002150) Veritas Cluster Server does not support Red Hat Enterprise Linux 8 Update 2(RHEL8.2).
Patch ID: VRTSamf-7.4.1.1600
* 3990020 (3990016) Veritas Cluster Server does not support Red Hat Enterprise Linux 8
Update 1(RHEL8.1).
Patch ID: VRTSvxfen-7.4.1.3400
* 4085614 (4072335) Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 6(RHEL8.6).
Patch ID: VRTSvxfen-7.4.1.3300
* 4051532 (4057308) After an InfoScale upgrade, the updated values of vxfen tunables that are used when loading the corresponding module fail to persist.
Patch ID: VRTSvxfen-7.4.1.3200
* 4053182 (4053171) Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 5(RHEL8.5).
Patch ID: VRTSvxfen-7.4.1.2900
* 4028780 (4029261) An entire InfoScale cluster may go down unexpectedly if one of its nodes receives a RECONFIG message during a shutdown or a restart operation.
* 4037951 (4037048) Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 4(RHEL8.4).
Patch ID: VRTSvxfen-7.4.1.2800
* 4000746 (4000745) The VxFEN process fails to start due to late discovery of the VxFEN disk group.
* 4019680 (4019674) Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8 Update 3(RHEL8.3).
Patch ID: VRTSgab-7.4.1.3400
* 4085645 (4072335) Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 6(RHEL8.6).
Patch ID: VRTSgab-7.4.1.3300
* 4054264 (4046413) After a node is added to or removed from a cluster, the GAB node count or the fencing quorum is not updated.
* 4054265 (4046418) The GAB module starts up even if LLT is not configured.
* 4060792 (4057312) Load time GAB tunables fail to persist the updated value after upgrade.
Patch ID: VRTSgab-7.4.1.3200
* 4053180 (4053171) Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 5(RHEL8.5).
Patch ID: VRTSgab-7.4.1.2900
* 4037949 (4037048) Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 4(RHEL8.4).
Patch ID: VRTSgab-7.4.1.2800
* 4016486 (4011683) The GAB module failed to start and the system log messages indicate failures with the mknod command.
* 4016487 (4007726) When a GAB message that is longer than the value specified by GAB_MAX_MSGSIZE is transfered, an error message is added to the VCS logs. However the error message is not sufficiently descriptive.
* 4019677 (4019674) Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8 Update 3(RHEL8.3).
Patch ID: VRTSgab-7.4.1.2100
* 4002152 (4002150) Veritas Cluster Server does not support Red Hat Enterprise Linux 8 Update 2(RHEL8.2).
Patch ID: VRTSgab-7.4.1.1600
* 3990018 (3990016) Veritas Cluster Server does not support Red Hat Enterprise Linux 8
Update 1(RHEL8.1).

DETAILS OF INCIDENTS FIXED BY THE PATCH
---------------------------------------
This patch fixes the following incidents:

Patch ID: VRTSllt-7.4.1.3400

* 4085646 (Tracking ID: 4072335)

SYMPTOM:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 6(RHEL8.6).

DESCRIPTION:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux
versions later than RHEL8 Update 5.

RESOLUTION:
Veritas Infoscale Availability support for Red Hat Enterprise Linux 8 Update
6(RHEL8.6) is now introduced.

Patch ID: VRTSllt-7.4.1.3300

* 4050664 (Tracking ID: 4046199)

SYMPTOM:
LLT configurations over UDP accept only ethernet interface names as link tag names.

DESCRIPTION:
The tag field in the link definition accepts only the ethernet interface name as a value.

RESOLUTION:
The LLT module is updated to accept any string a as link tag name.

* 4051040 (Tracking ID: 3989372)

SYMPTOM:
When the CPU load and memory consumption is high in a VMware environment, some nodes in an InfoScale cluster may get fenced out.

DESCRIPTION:
Occasionally, in a VMware environment, the operating system may not schedule LLT contexts on time. Consequently, heartbeats from some of the cluster nodes may be lost, and those nodes may get fenced out. This situation typically occurs when the CPU load or the memory usage is high or when the VMDK snapshot or vMotion operations are in progress.

RESOLUTION:
This fix attempts to make clusters more resilient to transient issues by heartbeating using threads bound to every vCPU.

* 4054272 (Tracking ID: 4045607)

SYMPTOM:
LLT over UDP support for transmission and reception of data over 1500 MTU networks.

DESCRIPTION:
The UDP multiport feature in LLT performs poorly in case of 1500 MTU-based networks. Data packets larger than 1500 bytes cannnot be transmitted over 1500 MTU-based networks, so the IP layer fragments them appropriately for transmission. The loss of a single fragment from the set leads to a total packet (I/O) loss. LLT then retransmits the same packet repeatedly until the transmission is successful. Eventually, you may encounter issues with the Flexible Storage Sharing (FSS) feature. For example, the vxprint process or the disk group creation process may stop responding, or the I/O-shipping performance may degrade severely.

RESOLUTION:
The UDP multiport feature of LLT is updated to fragment the packets such that they can be accommodated in the 1500-byte network frame. The fragments are rearranged on the receiving node at the LLT layer. Thus, LLT can track every fragment to the destination, and in case of transmission failures, retransmit the lost fragments based on the current RTT time.

* 4054697 (Tracking ID: 3985775)

SYMPTOM:
Sometimes, the system log may get flooded with LLT heartbeat loss messages that do not necessarily indicate any actual issues with LLT.

DESCRIPTION:
LLT heartbeat loss messages can appear in the system log either due to actual heartbeat drops in the network or due to heartbeat packets arriving out of order. In either case, these messages are only informative and do not indicate any issue in the LLT functionality. Sometimes, the system log may get flooded with these messages, which are not useful.

RESOLUTION:
The LLT module is updated to lower the frequency of printing LLT heartbeat loss messages. This is achieved by increasing the number of missed sequential HB packets required to print this informative message.

* 4058763 (Tracking ID: 4057310)

SYMPTOM:
After an InfoScale upgrade, the updated values of LLT and GAB tunables that are used when loading the corresponding modules fail to persist.

DESCRIPTION:
When the value of a tunable in /etc/sysconfig/llt or /etc/sysconfig/gab is changed before an RPM upgrade, the existing value gets reset to the default value.

RESOLUTION:
The LLT and the GAB modules are updated so that their tunable values in /etc/sysconfig/llt and /etc/sysconfig/gab can retain the existing values even after an RPM upgrade.

Patch ID: VRTSllt-7.4.1.3200

* 4053179 (Tracking ID: 4053171)

SYMPTOM:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 5(RHEL8.5).

DESCRIPTION:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux
versions later than RHEL8 Update 4.

RESOLUTION:
Veritas Infoscale Availability support for Red Hat Enterprise Linux 8 Update
5(RHEL8.5) is now introduced.

Patch ID: VRTSllt-7.4.1.2900

* 4022791 (Tracking ID: 4022792)

SYMPTOM:
A cluster node panics during an FSS I/O transfer over LLT.

DESCRIPTION:
In a Flexible Storage Sharing (FSS) setup, LLT uses sockets to transfer data between nodes. If a remote node is rebooted while the FSS I/O is running on the local node, the socket that was closed as part of the reboot process may still be used. If a NULL socket is thus accidentally used by the socket selection algorithm, it results in a node panic.

RESOLUTION:
This hotfix updates the LLT module to avoid the selection of such closed sockets.

* 4029112 (Tracking ID: 4029253)

SYMPTOM:
LLT may not reuse the buffer slots on which NAK is received from the earlier RDMA writes.

DESCRIPTION:
On receiving the buffer advertisement after an RDMA write, LLT also waits for the hardware/OS ACK for that RDMA write. Only after the ACK is received, LLT sets the state of the buffers to free (usable). If the connection between the cluter nodes breaks after LLT receives the buffer advertisement but before receiving the ACK, the local node generates a NAK. LLT does not acknowledge this NAK, and so, that specific buffer slot remains unusable. Over time, the number of buffer slots in the unusable state increases, which sets the flow control for the LLT client. This conditions leads to an FSS I/O hang.

RESOLUTION:
This hotfix updates the LLT module to mark a buffer slot as free (usable) even when a NAK is received from the previous RDMA write.

* 4037049 (Tracking ID: 4037048)

SYMPTOM:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 4(RHEL8.4).

DESCRIPTION:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux
versions later than RHEL8 Update 3.

RESOLUTION:
Veritas Infoscale Availability support for Red Hat Enterprise Linux 8 Update
4(RHEL8.4) is now introduced.

Patch ID: VRTSllt-7.4.1.2800

* 3999398 (Tracking ID: 3989440)

SYMPTOM:
The dash (-) in the device name may cause the LLT link configuration to fail.

DESCRIPTION:
While configuring LLT links, if the LLT module finds a dash in the device name, it assumes that the device name is in the 'eth-<mac-address>' format and considers the string after the dash as the mac address. However, if the user specifies an interface name that includes a dash, the string after the dash is not intended to be a MAC address. In such a case, the LLT link configuration fails.

RESOLUTION:
The LLT module is updated to check for the string 'eth-' before validating the device name with the 'eth-<mac-address>' format. If the string 'eth-' is not found, LLT assumes the name to be an interface name.

* 4002584 (Tracking ID: 3994996)

SYMPTOM:
Adding -H miscellaneous flag to add new functionalities in lltconfig. Add a tunable to allow skb alloc with SLEEP flag.

DESCRIPTION:
Adding -H miscellaneous flag, which we will use to add new functionalities in lltconfig, as very less alphabets are left to be able to assign an alphabet to each functionality.

RESOLUTION:
Inside -H flag
1. Add a tunable to allow skb alloc with SLEEP flag, in case memory is scarce.
2. Add skb_alloc failure count in lltstat output.

* 4003442 (Tracking ID: 3983418)

SYMPTOM:
In a rare case, after a panic or a reboot of a node, it may fail to join the CVM master due to an inconsistent LLT port state on the master.

DESCRIPTION:
When a node tries to join the cluster after a reboot or a panic, in a rare case, on one of the remaining nodes the port state of CVM or any other port may be in an inconsistent state with respect to LLT.

RESOLUTION:
This hotfix updates the LLT module to fix the issue by not accepting a particular type of a packet when not connected to the remote node and also adds more states to log into the LLT circular buffer.

* 4010546 (Tracking ID: 4018581)

SYMPTOM:
The LLT module fails to start and the system log messages indicate missing IP address.

DESCRIPTION:
When only the low priority LLT links are configured over UDP, UDPBurst mode must be disabled. UDPBurst mode must only be enabled when the high priority LLT links are configured over UDP. If the UDPBurst mode gets enabled while configuring the low priority links, the LLT module fails to start and logs the following error: "V-14-2-15795 missing ip address / V-14-2-15800 UDPburst:Failed to get link info".

RESOLUTION:
This hotfix updates the LLT module to not enable the UDPBurst mode when only the low priority LLT links are configured over UDP.

* 4016483 (Tracking ID: 4016484)

SYMPTOM:
The vxexplorer utility panics the node on which it runs if the LLT version on the node is llt-rhel8_x86_64-Patch-7.4.1.2100 or later.

DESCRIPTION:
The vxexplorer utility panics the node on which it runs if the LLT version on the node is llt-rhel8_x86_64-Patch-7.4.1.2100 or later.

RESOLUTION:
This hotfix addresses the issue so that vxexplorer utility does not panic nodes that run on the RHEL 8 platform.

* 4019676 (Tracking ID: 4019674)

SYMPTOM:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8 Update 3(RHEL8.3).

DESCRIPTION:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux versions later than RHEL8 Update 2.

RESOLUTION:
Veritas Infoscale Availability support for Red Hat Enterprise Linux 8 Update 3(RHEL8.3) is now introduced.

Patch ID: VRTSllt-7.4.1.2200

* 4012089 (Tracking ID: 4002150)

SYMPTOM:
Veritas Cluster Server does not support Red Hat Enterprise Linux 8 Update 2(RHEL8.2).

DESCRIPTION:
Veritas Cluster Server does not support Red Hat Enterprise Linux versions later than RHEL8.1 .

RESOLUTION:
Veritas Cluster Server support for Red Hat Enterprise Linux 8 Update 2(RHEL8.2) is now introduced.

Patch ID: VRTSllt-7.4.1.2100

* 4002151 (Tracking ID: 4002150)

SYMPTOM:
Veritas Cluster Server does not support Red Hat Enterprise Linux 8 Update 2(RHEL8.2).

DESCRIPTION:
Veritas Cluster Server does not support Red Hat Enterprise Linux versions later than RHEL8.1 .

RESOLUTION:
Veritas Cluster Server support for Red Hat Enterprise Linux 8 Update 2(RHEL8.2) is now introduced.

Patch ID: VRTSllt-7.4.1.1600

* 3990017 (Tracking ID: 3990016)

SYMPTOM:
Veritas Cluster Server does not support Red Hat Enterprise Linux 8
Update 1(RHEL8.1).

DESCRIPTION:
Veritas Cluster Server does not support Red Hat Enterprise Linux
versions later than RHEL8.0 .

RESOLUTION:
Veritas Cluster Server support for Red Hat Enterprise Linux 8 Update
1(RHEL8.1) is now introduced.

Patch ID: VRTSodm-7.4.1.3500

* 4087567 (Tracking ID: 4087566)

SYMPTOM:
VRTSodm driver will not load with VRTSvxfs patch.

DESCRIPTION:
Need recompilation of VRTSodm due to recent changes in VRTSvxfs
header files due to which some symbols are not being resolved.

RESOLUTION:
Recompiled the VRTSodm with new changes in VRTSvxfs header files.

Patch ID: VRTSodm-7.4.1.3400

* 4056672 (Tracking ID: 4056673)

SYMPTOM:
Rebooting the system results into emergency mode.

DESCRIPTION:
Module dependency files get corrupted due to parallel invocation of depmod.

RESOLUTION:
Serialized the invocation of depmod through file lock. Corrected vxgms dependency in odm service file.

Patch ID: VRTSodm-7.4.1.3200

* 3983992 (Tracking ID: 3868609)

SYMPTOM:
While applying Oracle redo logs, a significant increase is observed in the CPU usage by the vxfs thread.

DESCRIPTION:
To avoid memory deadlocks and to track exiting threads with outstanding ODM requests, the kernels memory management was analysed. While the Oracle threads are being rescheduled, they hold the mmap_sem. The FDD threads keep waiting for mmap_sem to be released, which causes the contention and the high CPU usage.

RESOLUTION:
The bouncing of the spinlock between the CPUs is removed to reduce the CPU spike.

* 4052886 (Tracking ID: 4052885)

SYMPTOM:
The ODM module fails to load on RHEL 8.5.

DESCRIPTION:
This issue occurs due to changes in the RHEL 8.5 kernel.

RESOLUTION:
The ODM module is updated to accommodate the changes in the kernel and load as expected on RHEL 8.5.

Patch ID: VRTSodm-7.4.1.3100

* 4040934 (Tracking ID: 4040933)

SYMPTOM:
VRTSodm driver will not load with VRTSvxfs patch.

DESCRIPTION:
Need recompilation of VRTSodm due to recent changes in VRTSvxfs
header files due to which some symbols are not being resolved.

RESOLUTION:
Recompiled the VRTSodm with new changes in VRTSvxfs header files.

Patch ID: VRTSodm-7.4.1.2900

* 4037955 (Tracking ID: 4037575)

SYMPTOM:
ODM module failed to load on RHEL8.4

DESCRIPTION:
The RHEL8.4 is new release and it has some changes in kernel which caused ODM module failed to load
on it.

RESOLUTION:
Added code to support ODM on RHEL8.4.

Patch ID: VRTSodm-7.4.1.2800

* 4018202 (Tracking ID: 4018200)

SYMPTOM:
ODM module failed to load on RHEL8.3

DESCRIPTION:
The RHEL8.3 is new release and it has some changes in kernel which caused ODM module failed to load
on it.

RESOLUTION:
Added code to support ODM on RHEL8.3.

Patch ID: VRTSodm-7.4.1.2600

* 4011973 (Tracking ID: 4012094)

SYMPTOM:
VRTSodm driver will not load with 7.4.1.2600 VRTSvxfs patch.

DESCRIPTION:
Need recompilation of VRTSodm due to recent changes in VRTSvxfs
header files due to which some symbols are not being resolved.

RESOLUTION:
Recompiled the VRTSodm with new changes in VRTSvxfs header files.

Patch ID: VRTSodm-7.4.1.2100

* 4001381 (Tracking ID: 4001380)

SYMPTOM:
ODM module failed to load on RHEL8.2

DESCRIPTION:
The RHEL8.2 is new release and it has some changes in kernel which caused ODM module failed to load
on it.

RESOLUTION:
Added code to support ODM on RHEL8.2

Patch ID: VRTSodm-7.4.1.1600

* 3989416 (Tracking ID: 3989415)

SYMPTOM:
ODM module failed to load on RHEL8.1

DESCRIPTION:
The RHEL8.1 is new release and it has some changes in kernel which caused ODM module failed to load
on it.

RESOLUTION:
Added code to support ODM on RHEL8.1

Patch ID: VRTSvxvm-7.4.1.3400

* 4062578 (Tracking ID: 4062576)

SYMPTOM:
When hastop -local is used to stop the cluster, dg deport command hangs. Below stack trace is observed in system logs :

#0 [ffffa53683bf7b30] __schedule at ffffffffa834a38d
#1 [ffffa53683bf7bc0] schedule at ffffffffa834a868
#2 [ffffa53683bf7bd0] blk_mq_freeze_queue_wait at ffffffffa7e4d4e6
#3 [ffffa53683bf7c18] blk_cleanup_queue at ffffffffa7e433b8
#4 [ffffa53683bf7c30] vxvm_put_gendisk at ffffffffc3450c6b [vxio]
#5 [ffffa53683bf7c50] volsys_unset_device at ffffffffc3450e9d [vxio]
#6 [ffffa53683bf7c60] vol_rmgroup_devices at ffffffffc3491a6b [vxio]
#7 [ffffa53683bf7c98] voldg_delete at ffffffffc34932fc [vxio]
#8 [ffffa53683bf7cd8] vol_delete_group at ffffffffc3494d0d [vxio]
#9 [ffffa53683bf7d18] volconfig_ioctl at ffffffffc3555b8e [vxio]
#10 [ffffa53683bf7d90] volsioctl_real at ffffffffc355fc8a [vxio]
#11 [ffffa53683bf7e60] vols_ioctl at ffffffffc124542d [vxspec]
#12 [ffffa53683bf7e78] vols_unlocked_ioctl at ffffffffc124547d [vxspec]
#13 [ffffa53683bf7e80] do_vfs_ioctl at ffffffffa7d2deb4
#14 [ffffa53683bf7ef8] ksys_ioctl at ffffffffa7d2e4f0
#15 [ffffa53683bf7f30] __x64_sys_ioctl at ffffffffa7d2e536

DESCRIPTION:
This issue is seen due to some updation from kernel side w.r.t to handling request queue.Existing VxVM code set the request handling area (make_request_fn) as vxvm_gen_strategy, this functionality is getting impacted.

RESOLUTION:
Code changes are added to handle the request queues using blk_mq_init_allocated_queue.

Patch ID: VRTSvxvm-7.4.1.3300

* 3984175 (Tracking ID: 3917636)

SYMPTOM:
Filesystems from /etc/fstab file are not mounted automatically on boot through systemd on RHEL7 and SLES12.

DESCRIPTION:
While bootup, when systemd tries to mount using the devices mentioned in the /etc/fstab file on the device, the device cannot be accessed leading to the failure of the mount operation. As the device is discovered through udev infrastructure, the udev-rules for the device should be applied when the volumes are created so that the device gets registered with systemd. In case, udev rules are executed even before the device in the "/dev/vx/dsk" directory is created, the device will not be registered with systemd leading to the failure of mount operation.

RESOLUTION:
To register the device, create all the volumes and run the "udevadm trigger" to execute all the udev rules.

* 4011097 (Tracking ID: 4010794)

SYMPTOM:
Veritas Dynamic Multi-Pathing (DMP) caused system panic in a cluster with below stack when storage activities were going on:
dmp_start_cvm_local_failover+0x118()
dmp_start_failback+0x398()
dmp_restore_node+0x2e4()
dmp_revive_paths+0x74()
gen_update_status+0x55c()
dmp_update_status+0x14()
gendmpopen+0x4a0()

DESCRIPTION:
The system panic occurred due to invalid dmpnode's current primary path when disks were attached/detached in a cluster. When DMP accessed the current primary path without doing sanity check, the system panics due to an invalid pointer.

RESOLUTION:
Code changes have been made to avoid accessing any invalid pointer.

* 4039527 (Tracking ID: 4018086)

SYMPTOM:
vxiod with ID as 128 was stuck with below stack:

#2 [] vx_svar_sleep_unlock at [vxfs]
#3 [] vx_event_wait at [vxfs]
#4 [] vx_async_waitmsg at [vxfs]
#5 [] vx_msg_send at [vxfs]
#6 [] vx_send_getemapmsg at [vxfs]
#7 [] vx_cfs_getemap at [vxfs]
#8 [] vx_get_freeexts_ioctl at [vxfs]
#9 [] vxportalunlockedkioctl at [vxportal]
#10 [] vxportalkioctl at [vxportal]
#11 [] vxfs_free_region at [vxio]
#12 [] vol_ru_start_replica at [vxio]
#13 [] vol_ru_start at [vxio]
#14 [] voliod_iohandle at [vxio]
#15 [] voliod_loop at [vxio]

DESCRIPTION:
With SmartMove feature set to ON, the vxiod with ID as 128 starts the replication where RVG is in DCM mode. Thus, the vxiod awaits the filesystem's response if the given region is used by filesystem or not. Filesystem will trigger MDSHIP IO on logowner. Due to a bug in the code, MDSHIP IO always gets queued in vxiod with ID as 128. Hence a deadlock situation occurs.

RESOLUTION:
Code changes have been made to avoid handling the MDSHIP IO in vxiod whose ID is bigger than 127.

* 4045494 (Tracking ID: 4021939)

SYMPTOM:
The "vradmin syncvol" command fails and the following message is logged: "VxVM VVR vxrsync ERROR V-5-52-10206 no server host systems specified".

DESCRIPTION:
VVR sockets now bind without specifying IP addresses. This recent change causes issues when such interfaces are used to identify whether the associated remote host is same as the localhost. For example, in case of the "vradmin syncvol" command, VVR incorrectly assumes that the local host has been provided as the remote host, logs the error message and exits.

RESOLUTION:
Updated the vradmin utility to correctly identify the remote hosts that are passed to the "vradmin syncvol" command.

* 4051815 (Tracking ID: 4031597)

SYMPTOM:
vradmind generates a core dump in __strncpy_sse2_unaligned.

DESCRIPTION:
The following core dump is generated:
(gdb)bt
Thread 1 (Thread 0x7fcd140b2780 (LWP 90066)):
#0 0x00007fcd12b1d1a5 in __strncpy_sse2_unaligned () from /lib64/libc.so.6
#1 0x000000000059102e in IpmServer::accept (this=0xf21168, new_handlesp=0x0) at Ipm.C:3406
#2 0x0000000000589121 in IpmHandle::events (handlesp=0xf12088, new_eventspp=0x7ffc8e80a4e0, serversp=0xf120c8, new_handlespp=0x0, ms=100) at Ipm.C:613
#3 0x000000000058940b in IpmHandle::events (handlesp=0xfc8ab8, vlistsp=0xfc8938, ms=100) at Ipm.C:645
#4 0x000000000040ae2a in main (argc=1, argv=0x7ffc8e80e8e8) at srvmd.C:722

RESOLUTION:
vradmind is updated to properly handle getpeername(), which addresses this issue.

* 4051887 (Tracking ID: 3956607)

SYMPTOM:
When removing a VxVM disk using the vxdg-rmdisk operation, the following error occurs while requesting a disk reclaim:
VxVM vxdg ERROR V-5-1-0 Disk <device_name> is used by one or more subdisks which are pending to be reclaimed.
Use "vxdisk reclaim <device_name>" to reclaim space used by these subdisks, and retry "vxdg rmdisk" command.
Note: The reclamation operation is irreversible. However, a core dump occurs when vxdisk-reclaim is executed.

DESCRIPTION:
This issue occurs due to a memory allocation failure in the disk-reclaim code, which fails to be detected and causes an invalid address to be referenced. Consequently, a core dump occurs.

RESOLUTION:
The disk-reclaim code is updated to handle memory allocation failures properly.

* 4051889 (Tracking ID: 4019182)

SYMPTOM:
In case of a VxDMP configuration, an InfoScale server panics when applying a patch. The following stack trace is generated:
unix:panicsys+0x40()
unix:vpanic_common+0x78()
unix:panic+0x1c()
unix:mutex_enter() - frame recycled
vxdmp(unloaded text):0x108b987c(jmpl?)()
vxdmp(unloaded text):0x108ab380(jmpl?)(0)
genunix:callout_list_expire+0x5c()
genunix:callout_expire+0x34()
genunix:callout_execute+0x10()
genunix:taskq_thread+0x42c()
unix:thread_start+4()

DESCRIPTION:
Some VxDMP functions create callouts. The VxDMP module may already be unloaded when a callout expires, which may cause the server to panic. VxDMP should cancel any previous timeout function calls before it unloads itself.

RESOLUTION:
VxDMP is updated to cancel any previous timeout function calls before unloading itself.

* 4051896 (Tracking ID: 4010458)

SYMPTOM:
In a VVR environment, the rlink might inconsistently disconnect due to unexpected transactions, and the following message might get logged:
"VxVM VVR vxio V-5-0-114 Disconnecting rlink <rlink_name> to permit transaction to proceed"

DESCRIPTION:
In a VVR environment, a transaction is triggered when a change in the VxVM or the VVR objects needs to be persisted on disk. In some scenarios, a few unnecessary transactions get triggered in a loop, which was causes multiple rlink disconnects and the aforementioned message gets logged frequently. One such unexpected transaction occurs when the open/close command is issued for a volume as part of SmartIO caching. The vradmind daemon also issues some open/close commands on volumes as part of the I/O statistics collection, which triggers unnecessary transactions. Additionally, some unexpected transactions occur due to incorrect references to some temporary flags on the volumes.

RESOLUTION:
VVR is updated to first check whether SmartIO caching is configured on a system. If it is not configured, VVR disables SmartIO caching on the associated volumes. VVR is also updated to avoid the unexpected transactions that may occur due to incorrect references on certain temporary flags on the volumes.

* 4055653 (Tracking ID: 4049082)

SYMPTOM:
I/O read error is displayed when remote FSS node rebooting.

DESCRIPTION:
When rebooting remote FSS node, I/O read requests to a mirror volume that is scheduled on the remote disk from the FSS node should be redirected to the remaining plex. However, current vxvm does not handle this correctly. The retrying I/O requests could still be sent to the offline remote disk, which cause to final I/O read failure.

RESOLUTION:
Code changes have been done to schedule the retrying read request on the remaining plex.

* 4055660 (Tracking ID: 4046007)

SYMPTOM:
In FSS environment if the cluster name is changed then the private disk region gets corrupted.

DESCRIPTION:
Under some conditions, when vxconfigd tries to update the TOC (table of contents) blocks of disk private region, the allocation maps cannot be initialized in the memory. This could make allocation maps incorrect and lead to corruption of the private region on the disk.

RESOLUTION:
Code changes have been done to avoid corruption of private disk region.

* 4055668 (Tracking ID: 4045871)

SYMPTOM:
vxconfigd crashed at ddl_get_disk_given_path with following stacks:
ddl_get_disk_given_path
ddl_reconfigure_all
ddl_find_devices_in_system
find_devices_in_system
mode_set
setup_mode
startup
main
_start

DESCRIPTION:
Under some situations, duplicate paths can be added in one dmpnode in vxconfigd. If the duplicate paths are removed then the empty path entry can be generated for that dmpnode. Thus, later when vxconfigd accesses the empty path entry, it crashes due to NULL pointer reference.

RESOLUTION:
Code changes have been done to avoid the duplicate paths that are to be added.

* 4055697 (Tracking ID: 4047793)

SYMPTOM:
When replicated disks are in SPLIT mode, importing its diskgroup failed with "Device is a hardware mirror".

DESCRIPTION:
When replicated disks are in SPLIT mode, which are r/w, importing its diskgroup failed with "Device is a hardware mirror". Third party doesn't expose disk attribute to show when it's in SPLIT mode. Now DMP refers to its REPLICATED status to judge if diskgroup import is allowed or not. `-o usereplicatedev=on/off` is enhanced to archive it.

RESOLUTION:
The code is enhanced to allow diskgroup import when replicated disks are in SPLIT mode.

* 4055772 (Tracking ID: 4043337)

SYMPTOM:
rp_rv.log file uses space for logging.

DESCRIPTION:
rp_rv log files needs to be removed and logger file should have 16 mb rotational log files.

RESOLUTION:
The code changes are implemented to disabel logging for rp_rv.log files

* 4055895 (Tracking ID: 4038865)

SYMPTOM:
In IRQ stack, the system panics at VxDMP module with the following calltrace:
native_queued_spin_lock_slowpath
queued_spin_lock_slowpath
_raw_spin_lock_irqsave7
dmp_get_shared_lock
gendmpiodone
dmpiodone
bio_endio
blk_update_request
scsi_end_request
scsi_io_completion
scsi_finish_command
scsi_softirq_done
blk_done_softirq
__do_softirq
call_softirq
do_softirq
irq_exit
do_IRQ
<IRQ stack>

DESCRIPTION:
A deadlock issue occurred between inode_hash_lock and DMP shared lock when one process was holding inode_hash_lock, but acquired the DMP shared lock in IRQ context and the other processes holding the DMP shared lock acquired the inode_hash_lock.

RESOLUTION:
To avoid the deadlock issue, the code changes are done.

* 4055899 (Tracking ID: 3993242)

SYMPTOM:
vxsnap prepare on vset might throw error : "VxVM vxsnap ERROR V-5-1-19171 Cannot perform prepare operation on cloud
volume"

DESCRIPTION:
There were some wrong volume-records entries being fetched for VSET and due to which required validations were failing and triggering the issue .

RESOLUTION:
Code changes have been done to resolve the issue .

* 4055905 (Tracking ID: 4052191)

SYMPTOM:
Any scripts or command files in the / directory may run unexpectedly when the system starts and vxvm volumes will not be available until those scripts or commands are complete.

DESCRIPTION:
If this issue occurs, /var/svc/log/system-vxvm-vxvm-configure:default.log indicates that a script or a command located in the / directory has been executed.
For example,
ABC Script ran!!
/lib/svc/method/vxvm-configure[241] abc.sh not found
/lib/svc/method/vxvm-configure[242] abc.sh not found
/lib/svc/method/vxvm-configure[243] abc.sh not found
/lib/svc/method/vxvm-configure[244] app/ cannot execute
In this example, abc.sh is located in the / directory and just echoes "ABC script ran !!". vxvm-configure launched abc.sh.

RESOLUTION:
The incorrect comments format in the SunOS_5.11.vxvm-configure.sh script is corrected.

* 4055925 (Tracking ID: 4031064)

SYMPTOM:
During master switch with replication in progress, cluster wide hang is seen on VVR secondary.

DESCRIPTION:
With application running on primary, and replication setup between VVR primary & secondary, when master switch operation is attempted on secondary, it gets hung permanently.

RESOLUTION:
Appropriate code changes are done to handle scenario of master switch operation and replication data on secondary.

* 4055938 (Tracking ID: 3999073)

SYMPTOM:
Data corruption occurred when the fast mirror resync (FMR) was enabled and the failed plex of striped-mirror layout was attached.

DESCRIPTION:
To determine and recover the regions of volumes using contents of detach, a plex attach operation with FMR tracking has been enabled.

For the given volume region, the DCO region size being higher than the stripe-unit of volume, the code logic in plex attached code path was incorrectly skipping the bits in detach maps. Thus, some of the regions (offset-len) of volume did not sync with the attached plex leading to inconsistent mirror contents.

RESOLUTION:
To resolve the data corruption issue, the code has been modified to consider all the bits for given region (offset-len) in plex attached code.

* 4056107 (Tracking ID: 4036181)

SYMPTOM:
IO error has been reported when RVG is not in enabled state after boot-up.

DESCRIPTION:
When RVG is not enabled/active, the volumes under a RVG will report an IO error.
Messages logged:
systemd[1]: Starting File System Check on /dev/vx/dsk/vvrdg/vvrdata1...
systemd-fsck[4977]: UX:vxfs fsck.vxfs: ERROR: V-3-20113: Cannot open : No such device or address
systemd-fsck[4977]: fsck failed with error code 31.
systemd-fsck: UX:vxfs fsck.vxfs: ERROR: V-3-20005: read of super-block on /dev/vx/dsk/vvrdg/vvrdata1 failed: Input/output error

RESOLUTION:
Issue got fixed by enabling the RVG using vxrvg command if the RVG is in disabled/recover state.

* 4056124 (Tracking ID: 4008664)

SYMPTOM:
System panic occurs with the following stack:

void genunix:psignal+4()
void vxio:vol_logger_signal_gen+0x40()
int vxio:vollog_logentry+0x84()
void vxio:vollog_logger+0xcc()
int vxio:voldco_update_rbufq_chunk+0x200()
int vxio:voldco_chunk_updatesio_start+0x364()
void vxio:voliod_iohandle+0x30()
void vxio:voliod_loop+0x26c((void *)0)
unix:thread_start+4()

DESCRIPTION:
Vxio keeps vxloggerd proc_t that is used to send a signal to vxloggerd. In case vxloggerd has been ended for some reason, the signal may be sent to an unexpected process, which may cause panic.

RESOLUTION:
Code changes have been made to correct the problem.

* 4056144 (Tracking ID: 3906534)

SYMPTOM:
After Dynamic Multi-Pathing (DMP) Native support is enabled, /boot should to be mounted on the DMP device(Specific to Linux).

DESCRIPTION:
Typically, /boot is mounted on top of an Operating System (OS) device. When DMP Native support is enabled, only the volume groups (VGs) are migrated from the OS device to the DMP device, but /boot is not migrated. Parallely, if the OS device path is not available, the system becomes unbootable, because /boot is not available. Thus, it is necessary to mount /boot on the DMP device to provide multipathing and resiliency(Specific to Linux).

RESOLUTION:
The module is updated to migrate /boot on top of a DMP device when DMP Native support is enabled. Note: This fix is available for RHEL 6 only. For other Linux platforms, /boot will still not be mounted on the DMP device(Specific to Linux).

* 4056146 (Tracking ID: 3983832)

SYMPTOM:
When the disk groups are deleted, multiple VxVM commands get hang in CVR secondary site.

DESCRIPTION:
VxVM command hangs when a deadlock was encountered during kmsg broadcast while deleting disk group and IBC unfreeze operation.

RESOLUTION:
Changes are done in VxVM code check either by transactions or avoiding deadlock.

* 4056832 (Tracking ID: 4057526)

SYMPTOM:
Whenever vxnm-vxnetd is loaded, it reports "Cannot touch '/var/lock/subsys/vxnm-vxnetd': No such file or directory" in /var/log/messages.

DESCRIPTION:
New systemd update removed the support for "/var/lock/subsys/" directory. Thus, whenever vxnm-vxnetd is loaded on the systems supporting systemd, it
reports "cannot touch '/var/lock/subsys/vxnm-vxnetd': No such file or directory"

RESOLUTION:
Added a check to validate if the /var/lock/subsys/ directory is supported in vxnm-vxnetd.sh

Patch ID: VRTSvxvm-7.4.1.3200

* 3984156 (Tracking ID: 3852146)

SYMPTOM:
In a CVM cluster, when a shared DG is imported by specifying both, the "-c" and the "-o noreonline" options, you may encounter the following error:
VxVM vxdg ERROR V-5-1-10978 Disk group <disk_group_name>: import failed: Disk for disk group not found.

DESCRIPTION:
The "-c" option updates the disk ID and the DG ID on the private region of the disks in the DG that is being imported. Such updated information is not yet seen by the slave because the disks have not been brought online again because the "noreonline" option was specified. As a result, the slave cannot identify the disk(s) based on the updated information sent from the master, which caused the import to fail with the error: Disk for disk group not found.

RESOLUTION:
VxVM is updated so that a shared DG import completes successfully even when the "-c" and the "-o noreonline" options are specified together.

* 3984175 (Tracking ID: 3917636)

SYMPTOM:
Filesystems from /etc/fstab file are not mounted automatically on boot
through systemd on RHEL7 and SLES12.

DESCRIPTION:
While bootup, when systemd tries to mount using the devices mentioned in
/etc/fstab file on the device, the device is not accessible leading to the
failure of the mount operation. As the device discovery happens through udev
infrastructure, the udev-rules for those
devices need to be run when volumes are created so that devices get
registered with systemd. In the case udev rules are executed even before the
devices in "/dev/vx/dsk" directory are created.
Since the devices are not created, devices will not be registered with
systemd leading to the failure of mount operation.

RESOLUTION:
Run "udevadm trigger" to execute all the udev rules once all volumes are
created so that devices are registered.

* 4041285 (Tracking ID: 4044583)

SYMPTOM:
A system goes into the maintenance mode when DMP is enabled to manage native devices.

DESCRIPTION:
The "vxdmpadm gettune dmp_native_support=on" command is used to enable DMP to manage native devices. After you change the value of the dmp_native_support tunable, you need to reboot the system needs for the changes to take effect. However, the system goes into the maintenance mode after it reboots. The issue occurs due to the copying of the local liblicmgr72.so file instead of the original one while creating the vx_initrd image.

RESOLUTION:
Code changes have been made to copy the correct liblicmgr72.so file. The system successfully reboots without going into maintenance mode.

* 4042039 (Tracking ID: 4040897)

SYMPTOM:
This is new array and we need to add support for claiming HPE MSA 2060 arrays.

DESCRIPTION:
HPE MSA 2060 is new array and current ASL doesn't support it. So it will not be claimed with current ASL. This array support has been now added in the current ASL.

RESOLUTION:
Code changes to support HPE MSA 2060 array have been done.

* 4050892 (Tracking ID: 3991668)

SYMPTOM:
In a VVR configuration with secondary logging enabled, data inconsistency is reported after the "No IBC message arrived" error is encountered.

DESCRIPTION:
It might happen that the VVR secondary node handles updates with larger sequence IDs before the In-Band Control (IBC) update arrives. In this case, VVR drops the IBC update. Due to the updates with the larger sequence IDs than the one for the IBC update, data writes cannot be started, and they get queued. Data loss may occur after the VVR secondary receives an atomic commit and frees the queue. If this situation occurs, the "vradmin verifydata" command reports data inconsistency.

RESOLUTION:
VVR is modified to trigger updates as they are received in order to start data volume writes.

* 4051457 (Tracking ID: 3958062)

SYMPTOM:
After a boot LUN is migrated, disabling dmp_native_support fails with following error.

VxVM vxdmpadm ERROR V-5-1-15883 check_bosboot open failed /dev/r errno 2
VxVM vxdmpadm ERROR V-5-1-15253 bosboot would not succeed, please run
manually to find the cause of failure
VxVM vxdmpadm ERROR V-5-1-15251 bosboot check failed
VxVM vxdmpadm INFO V-5-1-18418 restoring protofile
+ final_ret=18
+ f_exit 18
VxVM vxdmpadm ERROR V-5-1-15690 Operation failed for one or more volume
groups

VxVM vxdmpadm ERROR V-5-1-15686 The following VG(s) could not be migrated as
could not disable DMP support for LVM bootability -
rootvg

DESCRIPTION:
After performing a boot LUN migration, while enabling or disabling DMP native support, VxVM performs the 'bosboot' verification with the old boot disk name instead of the name of the migrated disk. This issue occurs on AIX, where the OS command returns the old boot disk name.

RESOLUTION:
VxVM is updated to use the correct OS command to get the boot disk name after migration.

* 4051815 (Tracking ID: 4031597)

SYMPTOM:
vradmind generates a core dump in __strncpy_sse2_unaligned.

RESOLUTION:
vradmind is updated to properly handle getpeername(), which addresses this issue.

* 4051887 (Tracking ID: 3956607)

RESOLUTION:
The disk-reclaim code is updated to handle memory allocation failures properly.

* 4051889 (Tracking ID: 4019182)

RESOLUTION:
VxDMP is updated to cancel any previous timeout function calls before unloading itself.

* 4051896 (Tracking ID: 4010458)

* 4051968 (Tracking ID: 4023390)

SYMPTOM:
Vxconfigd crashes as a disk contains invalid privoffset(160), which is smaller than minimum required offset(VTOC 265, GPT 208).

DESCRIPTION:
There may have disk label corruption or stale information residents on the disk header, which caused unexpected label written.

RESOLUTION:
Add a assert when updating CDS label to ensure the valid privoffset written to disk header.

* 4051985 (Tracking ID: 4031587)

SYMPTOM:
Filesystems are not mounted automatically on boot through systemd.

DESCRIPTION:
When systemd service tries to start all the FS in /etc/fstab, the Veritas Volume
Manager (VxVM) volumes are not started since vxconfigd is still not up. The VxVM
volumes are started a little bit later in the boot process. Since the volumes are
not available, the FS are not mounted automatically at boot.

RESOLUTION:
Registered the VxVM volumes with UDEV daemon of Linux so that the FS would be
mounted when the VxVM volumes are started and discovered by udev.

* 4053231 (Tracking ID: 4053230)

SYMPTOM:
RHEL 8.5 support is to be provided with IS 7.4.1 and 7.4.2

DESCRIPTION:
RHEL 8.5 ZDS support is being provided with IS 7.4.1 and 7.4.2

RESOLUTION:
VxVM packages are available with RHEL 8.5 compatibility

Patch ID: VRTSvxvm-7.4.1.3100

* 4017284 (Tracking ID: 4011691)

SYMPTOM:
Observed high CPU consumption on the VVR secondary nodes because of high pending IO load.

DESCRIPTION:
High replication related IO load on the VVR secondary and the requirement of maintaining write order fidelity with limited memory pools created contention. This resulted in multiple VxVM kernel threads contending for shared resources and there by increasing the CPU consumption.

RESOLUTION:
Limited the way in which VVR consumes its resources so that a high pending IO load would not result into high CPU consumption.

* 4039240 (Tracking ID: 4027261)

SYMPTOM:
These log files have permissions rw-rw-rw which are being flagged during customer's security scans.

DESCRIPTION:
There have been multiple concerns about world-writeable permissions on /var/VRTSvxvm/in.vxrsyncd.stderr and /var/adm/vx/vxdmpd.log .These log files have permissions rw-rw-rw which are being flagged by customer's security scans.

RESOLUTION:
The files are just log files with no sensitive information to leak, not much of a security threat. The files may not require world write permissions and can be restricted to the root user. Hence the permission of these files have been changed now !

* 4039242 (Tracking ID: 4008075)

SYMPTOM:
Observed with ASL changes for NVMe, This issue observed in reboot scenario. For every reboot machine was hitting panic And this was happening in loop.

DESCRIPTION:
panic was hitting for such splitted bios, root cause for this is RHEL8 introduced a new field named as __bi_remaining.
where __bi_remaining is maintanins the count of chained bios, And for every endio that __bi_remaining gets atomically decreased in bio_endio() function.
While decreasing __bi_remaining OS checks that the __bi_remaining 'should not <= 0' and in our case __bi_remaining was always 0 and we were hitting OS
BUG_ON.

RESOLUTION:
>>> For scsi devices maxsize is 4194304,
[ 26.919333] DMP_BIO_SIZE(orig_bio) : 16384, maxsize: 4194304
[ 26.920063] DMP_BIO_SIZE(orig_bio) : 262144, maxsize: 4194304

>>>and for NVMe devices maxsize is 131072
[ 153.297387] DMP_BIO_SIZE(orig_bio) : 262144, maxsize: 131072
[ 153.298057] DMP_BIO_SIZE(orig_bio) : 262144, maxsize: 131072

* 4039244 (Tracking ID: 4010612)

SYMPTOM:
$ vxddladm set namingscheme=ebn lowercase=no
This issue observed for NVMe and ssd. where every disk has separate enclosure like nvme0, nvme1... so on. means every nvme/ssd disks names would be
hostprefix_enclosurname0_disk0, hostprefix_enclosurname1_disk0....

DESCRIPTION:
$ vxddladm set namingscheme=ebn lowercase=no
This issue observed for NVMe and ssd. where every disk has separate enclosure like nvme0, nvme1... so on.
means every nvme/ssd disks names would be hostprefix_enclosurname0_disk0, hostprefix_enclosurname1_disk0....
eg.
smicro125_nvme0_0 <--- disk1
smicro125_nvme1_0 <--- disk2

for lowercase=no our current code is suppressing the suffix digit of enclosurname and hence multiple disks gets same name and it is showing udid_mismatch
because whatever udid of private region is not matching with ddl. ddl database showing wrong info because of multiple disks gets same name.

smicro125_nvme_0 <--- disk1 <<<<<<<-----here suffix digit of nvme enclosure suppressed
smicro125_nvme_0 <--- disk2

RESOLUTION:
Append the suffix integer while making da_name

* 4039249 (Tracking ID: 3984240)

SYMPTOM:
AIX builds were failing on AIX7.2 BE.

DESCRIPTION:
VxVM builds were failing on AIX7.2 BE.

RESOLUTION:
Made build environment and packaging changes so as to support VxVM builds on AIX7.2 BE.

* 4039525 (Tracking ID: 4012763)

SYMPTOM:
IO hang may happen in VVR (Veritas Volume Replicator) configuration when SRL overflows for one rlink while another one rlink is in AUTOSYNC mode.

DESCRIPTION:
In VVR, if the SRL overflow happens for rlink (R1) and some other rlink (R2) is ongoing the AUTOSYNC, then AUTOSYNC is aborted for R2, R2 gets detached and DCM mode is activated on R1 rlink.

However, due to a race condition in code handling AUTOSYNC abort and DCM activation in parallel, the DCM could not be activated properly and IO which caused DCM activation gets queued incorrectly, this results in a IO hang.

RESOLUTION:
The code has been modified to fix the race issue in handling the AUTOSYNC abort and DCM activation at same time.

* 4039526 (Tracking ID: 4034616)

SYMPTOM:
vol_seclog_limit_ioload tunable needs to be enabled on Linux only.

DESCRIPTION:
vol_seclog_limit_ioload tunable needs to be enabled on Linux only.

RESOLUTION:
The code changes are implemented to disable the tunable 'vol_seclog_limit_ioload' on non-linux platforms.

* 4040842 (Tracking ID: 4009353)

SYMPTOM:
After the command, vxdmpadm settune dmp_native_support=on, machine goes into maintenance mode. Issue is produced on physical setup with root lvm disk

DESCRIPTION:
If there is '-' in native vgname, then the script is taking an inaccurate vgname.

RESOLUTION:
Code changes have been made to fix the issue.

* 4044174 (Tracking ID: 4044072)

SYMPTOM:
I/Os fail for NVMe disks with 4K block size on the RHEL 8.4 kernel.

DESCRIPTION:
This issue occurs only in the case of disks of the 4K block size. I/Os complete successfully when the disks of 512 block size are used. If disks of the 4K block size are used, the following error messages are logged:
[ 51.228908] VxVM vxdmp V-5-0-0 [Error] i/o error occurred (errno=0x206) on dmpnode 201/0x10
[ 51.230070] blk_update_request: operation not supported error, dev nvme1n1, sector 240 op 0x0:(READ) flags 0x800 phys_seg 1 prio class 0
[ 51.240861] blk_update_request: operation not supported error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x800 phys_seg 1 prio class 0

RESOLUTION:
After making the necessary code changes, no error messages are seen in dmesg and logical block size is set to 4096 (same as physical block size).

* 4045494 (Tracking ID: 4021939)

SYMPTOM:
The "vradmin syncvol" command fails and the following message is logged: "VxVM VVR vxrsync ERROR V-5-52-10206 no server host systems specified".

RESOLUTION:
Code changes made to correctly identify remote hosts in the "vradmin syncvol" command.

* 4045502 (Tracking ID: 4045501)

SYMPTOM:
The following errors occur during the installation of the VRTSvxvm and the VRTSaslapm packages on CentOS 8.4 systems:
~
Verifying packages...
Preparing packages...
This release of VxVM is for Red Hat Enterprise Linux 8
and CentOS Linux 8.
Please install the appropriate OS
and then restart this installation of VxVM.
error: %prein(VRTSvxvm-7.4.1.2500-RHEL8.x86_64) scriptlet failed, exit status 1
error: VRTSvxvm-7.4.1.2500-RHEL8.x86_64: install failed
cat: 9: No such file or directory
~

DESCRIPTION:
The product installer reads the /etc/centos-release file to identify the Linux distribution. This issue occurs because the file has changed for CentOS 8.4.

RESOLUTION:
Code Changes have been made to correctly identify the Linux distribution.

Patch ID: VRTSvxvm-7.4.1.2900

* 4013643 (Tracking ID: 4010207)

SYMPTOM:
System panic occurred with the below stack:

native_queued_spin_lock_slowpath()
queued_spin_lock_slowpath()
_raw_spin_lock_irqsave()
volget_rwspinlock()
volkiodone()
volfpdiskiodone()
voldiskiodone_intr()
voldmp_iodone()
bio_endio()
gendmpiodone()
dmpiodone()
bio_endio()
blk_update_request()
scsi_end_request()
scsi_io_completion()
scsi_finish_command()
scsi_softirq_done()
blk_done_softirq()
__do_softirq()
call_softirq()

DESCRIPTION:
As part of collecting the IO statistics collection, the vxstat thread acquires a spinlock and tries to copy data to the user space. During the data copy, if some page fault happens, then the thread would relinquish the CPU and provide the same to some other thread. If the thread which gets scheduled on the CPU requests the same spinlock which vxstat thread had acquired, then this results in a hard lockup situation.

RESOLUTION:
Code has been changed to properly release the spinlock before copying out the data to the user space during vxstat collection.

* 4023762 (Tracking ID: 4020046)

SYMPTOM:
The following IO errors are reported on VxVM sub-disks result in DRL log detached without any SCSI errors detected.

VxVM vxio V-5-0-1276 error on Subdisk [xxxx] while writing volume [yyyy][log] offset 0 length [zzzz]
VxVM vxio V-5-0-145 DRL volume yyyy[log] is detached

DESCRIPTION:
DRL plexes detached as an atomic write flag (BIT_ATOMIC) was set on BIO unexpectedly. The BIT_ATOMIC flag gets set on bio only if VOLSIO_BASEFLAG_ATOMIC_WRITE flag is set on SUBDISK SIO and its parent MVWRITE SIO's sio_base_flags. When generating MVWRITE SIO, it's sio_base_flags was copied from a gio structure, because the gio structure memory isn't initialized it may contain gabarge values, hence the issue.

RESOLUTION:
Code changes have been made to fix the issue.

* 4031342 (Tracking ID: 4031452)

SYMPTOM:
Add node operation is failing with error "Error found while invoking '' in the new node, and rollback done in both nodes"

DESCRIPTION:
Stack showed a valid address for pointer ptmap2, but still it generated core.
It suggested that it might be a double-free case. Issue lies in freeing a pointer

RESOLUTION:
Added handling for such case by doing NULL assignment to pointers wherever they are freed

* 4033162 (Tracking ID: 3968279)

SYMPTOM:
Vxconfigd dumps core with SEGFAULT/SIGABRT on boot for NVME setup.

DESCRIPTION:
For NVME setup, vxconfigd dumps core while doing device discovery as the data structure is accessed by multiple threads and can hit a race condition. For sector size other than 512, the partition size mismatch is seen because we are doing comparison with partition size from devintf_getpart() and it is in sector size of the disk. This can lead to call of NVME device discovery.

RESOLUTION:
Added mutex lock while accessing the data structure so as to prevent core. Made calculations in terms of sector size of the disk to prevent the partition size mismatch.

* 4033163 (Tracking ID: 3959716)

SYMPTOM:
System may panic with sync replication with VVR configuration, when VVR RVG is in DCM mode, with following panic stack:
volsync_wait [vxio]
voliod_iohandle [vxio]
volted_getpinfo [vxio]
voliod_loop [vxio]
voliod_kiohandle [vxio]
kthread

DESCRIPTION:
With sync replication, if ACK for data message is delayed from the secondary site, the
primary site might incorrectly free the message from the waiting queue at primary site.
Due to incorrect handling of the message, a system panic may happen.

RESOLUTION:
Required code changes are done to resolve the panic issue.

* 4033172 (Tracking ID: 3994368)

SYMPTOM:
During node 0 shutting down, vxconfigd daemon abort on node 1, and I/O write error happened on node 1

DESCRIPTION:
Examining the vxconfigd core we found that it entered into endless sigio processing which resulted in stack overflow and hence vxconfigd core dumped.
After that vxconfigd restarted and ended up in dg disable scenario.

RESOLUTION:
We have done the appropriate code changes to handle the scenario of stack overflow.

* 4033173 (Tracking ID: 4021301)

SYMPTOM:
Data corruption issue happened with the big size IO processed by Linux kernel IO split on RHEL8.

DESCRIPTION:
On RHEL8 or as of Linux kernel 3.13, it introduces some changes in Linux kernel block layer, new item of the bio iterator structure is used to represent the start offset of bio or bio vectors after the IO processed by Linux kernel IO split functions. Also, in recent version of vxfs, it can generate bio with larger size than the size limitation defined within Linux kernel block layer and VxVM, which lead the IO from vxfs could be split by Linux kernel. For such split IOs, VxVM does not take the new item of the bio iterator into account while process them, which caused the data is written to wrong position of volume/disk. Hence, data corruption.

RESOLUTION:
Code changes have been made to bypass the Linux kernel IO split functions, which seems redundant for VxVM IO processing.

* 4033216 (Tracking ID: 3993050)

SYMPTOM:
vxdctl dumpmsg command gets stuck on large node cluster during reconfiguration

DESCRIPTION:
vxdctl dumpmsg command gets stuck on large node cluster during reconfiguration with following stack. This causes /var/adm/vx/voldctlmsg.log file
to get filled with old repeated messages in GBs consuming most of /var space.
# pstack 210460
voldctl_get_msgdump ()
do_voldmsg ()
main ()

RESOLUTION:
Code changes have been done to dump correct required messages to file

* 4033515 (Tracking ID: 3984266)

SYMPTOM:
DCM flag in on the RVG (Replicated Volume Group) volume may get deactivated after a master switch in CVR (Clustered Volume Replicator) which may cause excessive RVG recovery after subsequent node reboots.

DESCRIPTION:
After master switch, the DCM flag needs to be updated on the new CVM master node. Due to a transaction initiated in parallel with master switch, the DCM flag was getting lost. This was causing excessive RVG recovery during next node reboots as the DCM write position was NOT updated for a long time.

RESOLUTION:
The code is fixed to handle the race in updating the DCM flag during a master switch.

* 4035313 (Tracking ID: 4037915)

SYMPTOM:
Getting compilation errors due to RHEL's source code changes

DESCRIPTION:
While compiling the RHEL 8.4 kernel (4.18.0-304) the build compilation fails due to certain RH source changes.

RESOLUTION:
Following changes have been fixed to work with VxVM 7.4.1
__bdevname - depreciated
Solution: Have a struct block_device and use bdevname

blkg_tryget_closest - placed under EXPORT_SYMBOL_GPL
Solution: Locally defined the function where compilation error was hit

sync_core - implicit declaration
The implementation of function sync_core() has been moved to header file sync_core.h, so including this header file fixes the error

* 4036426 (Tracking ID: 4036423)

SYMPTOM:
Race condition while reading config file in docker volume plugin caused the issue in Flex Appliance.

DESCRIPTION:
If 2 simultaneous requests come for say MountVolume, then both of them update the global variables and it leads to wrong parameter values
in some cases.

RESOLUTION:
Fix is to read this file only once during startup in init() function. If the user wants to change default values in the config file,
then he will have to restart the vxinfoscale-docker service.

* 4037331 (Tracking ID: 4037914)

SYMPTOM:
Crash while running VxVM cert.

DESCRIPTION:
While running the VM cert, there is a panic reported and the

RESOLUTION:
Setting bio and submitting to IOD layer in our own vxvm_gen_strategy() function

* 4037810 (Tracking ID: 3977101)

SYMPTOM:
While testing on VM cert a core dump is produced, no functionality breaks were observed

DESCRIPTION:
A regression caused by read_sol_label using same return varible (ret) more than once. Added code to get sector size and used same return variable, the function was returning presence of label even if it does not exist

RESOLUTION:
Code repositioned in vxpart.c to assign only in presence of label to return value

Patch ID: VRTSvxvm-7.4.1.2800

* 3984155 (Tracking ID: 3976678)

SYMPTOM:
vxvm-recover: cat: write error: Broken pipe error encountered in syslog multiple times.

DESCRIPTION:
Due to a bug in vxconfigbackup script which is started by vxvm-recover "cat : write error: Broken pipe" is encountered in syslog
and it is reported under vxvm-recover. In vxconfigbackup code multiple subshells are created in a function call and the first subshell is for cat command. When a particular if condition is satistfied, return is called exiting the later subshells even when there is data to be read in the created cat subshell, which results in broken pipe error.

RESOLUTION:
Changes are done in VxVM code to handle the broken pipe error.

* 4016283 (Tracking ID: 3973202)

SYMPTOM:
A VVR primary node may panic with below stack due to accessing the freed memory:
nmcom_throttle_send()
nmcom_sender()
kthread ()
kernel_thread()

DESCRIPTION:
After sending the data to VVR (Veritas Volume Replicator) secondary site, the code was accessing some variables for which the memory was already released due to the data ACK getting processed quite early. This was a rare race condition which may happen due to accessing the freed memory.

RESOLUTION:
Code changes have been made to avoid the incorrect memory access.

* 4016291 (Tracking ID: 4002066)

SYMPTOM:
System panic with below stack when do reclaim:
__wake_up_common_lock+0x7c/0xc0
sbitmap_queue_wake_all+0x43/0x60
blk_mq_tag_wakeup_all+0x15/0x30
blk_mq_wake_waiters+0x3d/0x50
blk_set_queue_dying+0x22/0x40
blk_cleanup_queue+0x21/0xd0
vxvm_put_gendisk+0x3b/0x120 [vxio]
volsys_unset_device+0x1d/0x30 [vxio]
vol_reset_devices+0x12b/0x180 [vxio]
vol_reset_kernel+0x16c/0x220 [vxio]
volconfig_ioctl+0x866/0xdf0 [vxio]

DESCRIPTION:
With recent kernel, it is expected that kernel will return the pre-allocated sense buffer. These sense buffer pointers are supposed to be unchanged across multiple uses of a request. They are pre-allocated and expected to be unchanged until such a time as the request memory is to be freed. DMP overwrote the original sense buffer, hence the issue.

RESOLUTION:
Code changes have been made to avoid tampering the pre-allocated sense buffer.

* 4016768 (Tracking ID: 3989161)

SYMPTOM:
The system panic occurs because of hard lockup with the following stack:

#13 [ffff9467ff603860] native_queued_spin_lock_slowpath at ffffffffb431803e
#14 [ffff9467ff603868] queued_spin_lock_slowpath at ffffffffb497a024
#15 [ffff9467ff603878] _raw_spin_lock_irqsave at ffffffffb4988757
#16 [ffff9467ff603890] vollog_logger at ffffffffc105f7fa [vxio]
#17 [ffff9467ff603918] vol_rv_update_childdone at ffffffffc11ab0b1 [vxio]
#18 [ffff9467ff6039f8] volsiodone at ffffffffc104462c [vxio]
#19 [ffff9467ff603a88] vol_subdisksio_done at ffffffffc1048eef [vxio]
#20 [ffff9467ff603ac8] volkcontext_process at ffffffffc1003152 [vxio]
#21 [ffff9467ff603b10] voldiskiodone at ffffffffc0fd741d [vxio]
#22 [ffff9467ff603c40] voldiskiodone_intr at ffffffffc0fda92b [vxio]
#23 [ffff9467ff603c80] voldmp_iodone at ffffffffc0f801d0 [vxio]
#24 [ffff9467ff603c90] bio_endio at ffffffffb448cbec
#25 [ffff9467ff603cc0] gendmpiodone at ffffffffc0e4f5ca [vxdmp]
... ...
#50 [ffff9497e99efa60] do_page_fault at ffffffffb498d975
#51 [ffff9497e99efa90] page_fault at ffffffffb4989778
#52 [ffff9497e99efb40] conv_copyout at ffffffffc10005da [vxio]
#53 [ffff9497e99efbc8] conv_copyout at ffffffffc100044e [vxio]
#54 [ffff9497e99efc50] volioctl_copyout at ffffffffc1032db3 [vxio]
#55 [ffff9497e99efc80] vol_get_logger_data at ffffffffc105e4ce [vxio]
#56 [ffff9497e99efcf8] voliot_ioctl at ffffffffc105e66b [vxio]
#57 [ffff9497e99efd78] volsioctl_real at ffffffffc10aee82 [vxio]
#58 [ffff9497e99efe50] vols_ioctl at ffffffffc0646452 [vxspec]
#59 [ffff9497e99efe70] vols_unlocked_ioctl at ffffffffc06464c1 [vxspec]
#60 [ffff9497e99efe80] do_vfs_ioctl at ffffffffb4462870
#61 [ffff9497e99eff00] sys_ioctl at ffffffffb4462b21

DESCRIPTION:
Vxio kernel sends a signal to vxloggerd to flush the log as it is almost full. Vxloggerd calls into vxio kernel to copy the log buffer out. As vxio copy log date from kernel to user with holding a spinlock, if a page fault occurs during the copy out, hard lockup and panic occur.

RESOLUTION:
Code changes have been made the fix the problem.

* 4017194 (Tracking ID: 4012681)

SYMPTOM:
If vradmind process terminates due to some reason, it is not properly restarted by RVG agent of VCS.

DESCRIPTION:
The RVG(Replicated Volume Group) agent of VCS(Veritas Cluster Server) restarts the vradmind process if it gets killed or terminated
due to some reason, this was not working properly on systemd enabled platforms like RHEL-7.
In the systemd enabled platforms, after the vradmind process dies, the vras-vradmind service used to stay in active/running state, due to this, even
after the RVG agent issued a command to start the vras-vradmind service, the vradmind process was not getting started.

RESOLUTION:
The code is modified to fix the parameters for vras-vradmind service, so that the service status will change to failed/faulted if vradmind process gets killed.
The service can be manually started later or RVG agent of VCS can start the service, which will start the vradmind process as well.

* 4017502 (Tracking ID: 4020166)

SYMPTOM:
Build issue becuase of "struct request"

error: struct request has no member named next_rq
Linux has deprecated the member next_req

DESCRIPTION:
The issue was observed due to changes in OS structure

RESOLUTION:
code changes are done in required files

* 4019781 (Tracking ID: 4020260)

SYMPTOM:
While enabling dmp native support tunable dmp_native_support for Centos 8 below mentioned error was observed:

[root@dl360g9-4-vm2 ~]# vxdmpadm settune dmp_native_support=on
VxVM vxdmpadm ERROR V-5-1-15690 Operation failed for one or more volume groups

VxVM vxdmpadm ERROR V-5-1-15686 The following vgs could not be migrated as error in bootloader configuration file

cl
[root@dl360g9-4-vm2 ~]#

DESCRIPTION:
The issue was observed due to missing code check-ins for CentOS 8 in the required files.

RESOLUTION:
Changes are done in required files for dmp native support in CentOS 8

Patch ID: VRTSvxvm-7.4.1.2700

* 3984163 (Tracking ID: 3978216)

SYMPTOM:
'Device mismatch warning' seen on boot when DMP native support is enabled with LVM snapshot of root disk present

DESCRIPTION:
When we enable DMP (Dynamic Multipathing) Native Support featue on the system having a LVM snapshot of root disk present, "Device mismatch" warning messages are seen on every reboot in boot.log file. The messages are coming because LVM is trying to access the LV using the information present in the lvm.cache file which is stale. Because of accessing the stale file, the warning messages are seen on reboot.

RESOLUTION:
Fix is to remove the LVM cache file during system shutdown as part of VxVM shutdown.

* 4010517 (Tracking ID: 3998475)

SYMPTOM:
Data corruption is observed and service groups went into partial state.

DESCRIPTION:
In VxVM, fsck log replay initiated read of 64 blocks, that was getting split across 2 stripes of the stripe-mirror volume.
So, we had 2 read I/Os of 48 blocks (first split I/O) and 16 blocks (second split I/O).
Since the volume was in RWBK mode, this read I/O was stabilized. Upon completion of the read I/O at subvolume level, this I/O was unstabilized and the contents
of the stable I/O (stablekio) were copied to the original I/O (origkio). It was observed that the data was always correct till the subvolume level but at the
top level plex and volume level, it was incorrect (printed checksum in vxtrace output for this).

The reason for this was during unstabilization, we do volkio_to_kio_copy() which copies the contents from stable kio to orig kio (since it is a read).
As the orig kio was an unmapped PHYS I/O, in Solaris 11.4, the contents will be copied out using bp_copyout() from volkiomem_kunmap(). The volkiomem_seek() and
volkiomem_next_segment() allocates pagesize (8K) kernel buffer (zero'ed out) where the contents will be copied to.
When the first split I/O completes unstabilization before the second split I/O, this issue was not seen. However, if the second split
I/O completed before the first splt I/O then this issue was seen.

Here, in the last iteration of the volkio_to_kio_copy(), the data copied was less than the allocated region size. We allocate 8K region size whereas the data
copied from stablekio was less than 8K. Later, during kunmap(), we do a bp_copyout() of alloocated size i.e. 8K. This caused copyout of extra regions that were
zero'ed out. Hence the data corruption.

RESOLUTION:
Now we do a bp_copyout() of the right length i.e. of the copied size instead of the allocated region size.

* 4010996 (Tracking ID: 4010040)

SYMPTOM:
Configuring VRTSvxvm package creates a world writable file: "/etc/vx/.vxvvrstatd.lock".

DESCRIPTION:
VVR statistics daemon (vxvvrstad) creates this file on startup. The umask for this daemon was not set correctly resulting in creation of the world writable file.

RESOLUTION:
VVR daemon is updated to to set the umask properly.

* 4011027 (Tracking ID: 4009107)

SYMPTOM:
CA chain certificate verification fails in VVR when the number of intermediate certificates is greater than the depth. So, we get error in SSL initialization.

DESCRIPTION:
CA chain certificate verification fails in VVR when the number of intermediate certificates is greater than the depth. SSL_CTX_set_verify_depth() API decides the depth of certificates (in /etc/vx/vvr/cacert file) to be verified, which is limited to count 1 in code. Thus intermediate CA certificate present first in /etc/vx/vvr/cacert (depth 1 CA/issuer certificate for server certificate) could be obtained and verified during connection, but root CA certificate (depth 2 higher CA certificate) could not be verified while connecting and hence the error.

RESOLUTION:
Removed the call of SSL_CTX_set_verify_depth() API so as to handle the depth automatically.

* 4011097 (Tracking ID: 4010794)

SYMPTOM:
Veritas Dynamic Multi-Pathing (DMP) caused system panic in a cluster with below stack while there were storage activities going on.
dmp_start_cvm_local_failover+0x118()
dmp_start_failback+0x398()
dmp_restore_node+0x2e4()
dmp_revive_paths+0x74()
gen_update_status+0x55c()
dmp_update_status+0x14()
gendmpopen+0x4a0()

DESCRIPTION:
It could happen dmpnode's current primary path became invalid when disks were attached/detached in a cluster. DMP accessed the current primary path without doing sanity check. Hence system panic due to an invalid pointer.

RESOLUTION:
Code changes have been made to avoid accessing a invalid pointer.

* 4011105 (Tracking ID: 3972433)

SYMPTOM:
IO hang might be seen while issuing heavy IO load on volumes having cache objects.

DESCRIPTION:
While issuing heavy IO on volumes having cache objects, the IO on cache volumes may stall due to locking(region lock) involved
for overlapping IO requests on the same cache object. When appropriate locks are granted to IOs, all the IOs were getting processed
in serial fashion through single VxVM IO daemon thread. This serial processing was causing slowness,
resulting in a IO hang like situation and application timeouts.

RESOLUTION:
The code changes are done to properly perform multi-processing of the cache volume IOs.

Patch ID: VRTSvxvm-7.4.1.2200

* 3992902 (Tracking ID: 3975667)

SYMPTOM:
NMI watchdog: BUG: soft lockup

DESCRIPTION:
When flow control on ioshipping channel is set there is window in code where vol_ioship_sender thread can go in tight loop.
This causes softlockup

RESOLUTION:
Relinquish CPU to schedule other process. vol_ioship_sender() thread will restart after some delay.

* 3997906 (Tracking ID: 3987937)

SYMPTOM:
VxVM command hang happens when heavy IO load performed on VxVM volume with snapshot, IO memory pool full is also observed.

DESCRIPTION:
It's a deadlock situation occurring with heavy IOs on volume with snapshots. When a multistep SIO A acquired ilock and it's child MV write SIO is waiting for memory pool which is full, another multistep SIO B has acquired memory and waiting for the ilock held by multistep SIO A.

RESOLUTION:
Code changes have been made to fix the issue.

* 4000388 (Tracking ID: 4000387)

SYMPTOM:
Existing VxVM module fails to load on Rhel 8.2

DESCRIPTION:
RHEL 8.2 is a new release and had few KABI changes on which VxVM compilation breaks .

RESOLUTION:
Compiled VxVM code against 8.2 kernel and made changes to make it compatible.

* 4001399 (Tracking ID: 3995946)

SYMPTOM:
CVM Slave unable to join cluster with below error:
VxVM vxconfigd ERROR V-5-1-11092 cleanup_client: (Memory allocation failure) 12
VxVM vxconfigd ERRORV-5-1-11467 kernel_fail_join(): Reconfiguration interrupted: Reason is retry to add a node failed (13, 0)

DESCRIPTION:
vol_vvr_tcp_keepalive and vol_vvr_tcp_timeout are introduced in 7.4.1 U1 for Linux only. For other platforms like Solaris and AIX, it isn't supported. Due a bug in code, those two tunables were exposed,and cvm couldn't get those two tunables info from master node. Hence the issue.

RESOLUTION:
Code change has been made to hide vol_vvr_tcp_keepalive and vol_vvr_tcp_timeout for other platforms like Solaris and AIX.

* 4001736 (Tracking ID: 4000130)

SYMPTOM:
System panic when DMP co-exists with EMC PP on rhel8/sles12sp4 with below stacks:

#6 [] do_page_fault
#7 [] page_fault
[exception RIP: dmp_kernel_scsi_ioctl+888]
#8 [] dmp_kernel_scsi_ioctl at [vxdmp]
#9 [] dmp_dev_ioctl at [vxdmp]
#10 [] do_passthru_ioctl at [vxdmp]
#11 [] dmp_tur_temp_pgr at [vxdmp]
#12 [] dmp_pgr_set_temp_key at [vxdmp]
#13 [] dmpioctl at [vxdmp]
#14 [] dmp_ioctl at [vxdmp]
#15 [] blkdev_ioctl
#16 [] block_ioctl
#17 [] do_vfs_ioctl
#18 [] ksys_ioctl

#8 [ffff9c3404c9fb40] page_fault
#9 [ffff9c3404c9fbf0] dmp_kernel_scsi_ioctl at [vxdmp]
#10 [ffff9c3404c9fc30] dmp_scsi_ioctl at [vxdmp]
#11 [ffff9c3404c9fcb8] dmp_send_scsireq at [vxdmp]
#12 [ffff9c3404c9fcd0] dmp_do_scsi_gen at [vxdmp]
#13 [ffff9c3404c9fcf0] dmp_pr_send_cmd at [vxdmp]
#14 [ffff9c3404c9fd80] dmp_pr_do_read at [vxdmp]
#15 [ffff9c3404c9fdf0] dmp_pgr_read at [vxdmp]
#16 [ffff9c3404c9fe20] dmpioctl at [vxdmp]
#17 [ffff9c3404c9fe30] dmp_ioctl at [vxdmp]

DESCRIPTION:
Upwards 4.10.17, there is no such guarantee from the block layer or other drivers to ensure that the cmd pointer at least points to __cmd, when initialize a SCSI request. DMP directly accesses cmd pointer after got the SCSI request from underlayer without sanity check, hence the issue.

RESOLUTION:
Code changes have been made to do sanity check when initialize a SCSI request.

* 4001745 (Tracking ID: 3992053)

SYMPTOM:
Data corruption may happen with layered volumes due to some data not re-synced while attaching a plex. This is due to
inconsistent data across the plexes after attaching a plex in layered volumes.

DESCRIPTION:
When a plex is detached in a layered volume, the regions which are dirty/modified are tracked in DCO (Data change object) map.
When the plex is attached back, the data corresponding to these dirty regions is re-synced to the plex being attached.
There was a defect in the code due to which the some particular regions were NOT re-synced when a plex is attached.
This issue only happens only when the offset of the sub-volume is NOT aligned with the region size of DCO (Data change object) volume.

RESOLUTION:
The code defect is fixed to correctly copy the data for dirty regions when the sub-volume offset is NOT aligned with the DCO region size.

* 4001746 (Tracking ID: 3999520)

SYMPTOM:
VxVM commands may hang with below stack when user tries to start or stop the DMP IO statistics collection when
the DMP iostat tunable (dmp_iostats_state) was disabled earlier.

schedule()
rwsem_down_failed_common()
rwsem_down_write_failed()
call_rwsem_down_write_failed()
dmp_reconfig_write_lock()
dmp_update_reclaim_attr()
gendmpioctl()
dmpioctl()

DESCRIPTION:
When the DMP iostat tunable (dmp_iostats_state) is disabled and user tries to
start (vxdmpadm iostat start) or stop (vxdmpadm iostat stop) the DMP iostat collection, then
a thread which collects the IO statistics was exiting without releasing a lock. Due to this,
further VxVM commands were getting hung while waiting for the lock.

RESOLUTION:
The code is changed to correctly release the lock when the tunable 'dmp_iostats_state' is disabled.

* 4001748 (Tracking ID: 3991580)

SYMPTOM:
IO and VxVM command hang may happen if IO performed on both source and snapshot volumes.

DESCRIPTION:
It's a deadlock situation occurring with heavy IOs on both source volume and snapshot volume.
SIO (a), USER_WRITE, on snap volume, held ILOCK (a), waiting for memory(full).
SIO (b), PUSHED_WRITE, on snap volume, waiting for ILOCK (a).
SIO (c), parent of SIO (b), USER_WRITE, on the source volume, held ILOCK (c) and memory, waiting for SIO (b) done.

RESOLUTION:
User separate pool for IO writes on Snapshot volume to resolve the issue.

* 4001750 (Tracking ID: 3976392)

SYMPTOM:
Memory corruption might happen in VxVM (Veritas Volume Manager) while processing Plex detach request.

DESCRIPTION:
During processing of plex detach request, the VxVM volume is operated in serial manner. During serialization it might happen that current thread has queued the I/O and still accessing the same. In the meantime the same I/O is picked up by one of VxVM threads for processing. The processing of the I/O is completed and the same is deleted after that. The current thread is still accessing the same memory which was already deleted which might lead to memory corruption.

RESOLUTION:
Fix is to not use the same I/O in the current thread once the I/O is queued as part of serialization and the processing is done before queuing the I/O.

* 4001752 (Tracking ID: 3969487)

SYMPTOM:
Data corruption observed with layered volumes after resynchronisation when mirror of the volume is detached and attached back.

DESCRIPTION:
In case of layered volume, if the IO fails at the underlying subvolume layer before doing the mirror detach the top volume in layered volume has to be serialized (run IO's in serial fashion). When volume is serialized IO's on the volume are directly tracked into detach map of DCO (Data Change Object). During this time period if some of the new IO's occur on the volume then those IO's would not be tracked as part of the detach map inside DCO since detach map tracking is not yet enabled by failed IO's. The new IO's which are not being tracked in detach map would be missed when the plex resynchronisation happens later which leads to corruption.

RESOLUTION:
Fix is to delay the unserialization of the volume till the point failed IO's actually detach the plex and enable detach map tracking. This would make sure new IO's are tracked as part of detach map of DCO.

* 4001755 (Tracking ID: 3980684)

SYMPTOM:
Kernel panic in voldrl_hfind_an_instant while accessing agenode with stack
[exception RIP: voldrl_hfind_an_instant+49]
#11 voldrl_find_mark_agenodes
#12 voldrl_log_internal_30
#13 voldrl_log_30
#14 volmv_log_drlfmr
#15 vol_mv_write_start
#16 volkcontext_process
#17 volkiostart
#18 vol_linux_kio_start
#19 vxiostrategy
...

DESCRIPTION:
Agenode corruption is hit in case of use of per file sequential hint. Agenode's linked list is corrupted as pointer was not set to NULL
when reusing the agenode.

RESOLUTION:
Changes are done in VxVM code to avoid Agenode list corruption.

* 4001757 (Tracking ID: 3969387)

SYMPTOM:
In FSS(Flexible Storage Sharing) environment,system might panic with below stack:
vol_get_ioscb [vxio]
vol_ecplex_rhandle_resp [vxio]
vol_ioship_rrecv [vxio]
gab_lrrecv [gab]
vx_ioship_llt_rrecv [llt]
vx_ioship_process_frag_packets [llt]
vx_ioship_process_data [llt]
vx_ioship_recv_data [llt]

DESCRIPTION:
In certain scenario, it may happen that request got purged and response came after that. Then system might panic due to access the freed resource.

RESOLUTION:
Code changes have been made to fix the issue.

Patch ID: VRTSvxvm-7.4.1.1600

* 3984139 (Tracking ID: 3965962)

SYMPTOM:
No option to disable auto-recovery when a slave node joins the CVM cluster.

DESCRIPTION:
In a CVM environment, when the slave node joins the CVM cluster, it is possible that the plexes may not be in sync. In such a scenario auto-recovery is triggered for the plexes. If a node is stopped using the hastop -all command when the auto-recovery is in progress, the vxrecover operation may hang. An option to disable auto-recovery is not available.

RESOLUTION:
The VxVM module is updated to allow administrators to disable auto-recovery when a slave node joins a CVM cluster.
A new tunable, auto_recover, is introduced. By default, the tunable is set to 'on' to trigger the auto-recovery. Set its value to 'off' to disable auto-recovery. Use the vxtune command to set the tunable.

* 3984731 (Tracking ID: 3984730)

SYMPTOM:
VxVM logs warning messages when the VxDMP module is stopped or removed for the first time after the system is rebooted.

DESCRIPTION:
VxVM logs these warnings because the QUEUE_FLAG_REGISTERED and QUEUE_FLAG_INIT_DONE queue flags are not cleared while registering the dmpnode.
The following stack is reported after stopping/removing VxDMP for first time after every reboot:
kernel: WARNING: CPU: 28 PID: 33910 at block/blk-core.c:619 blk_cleanup_queue+0x1a3/0x1b0
kernel: CPU: 28 PID: 33910 Comm: modprobe Kdump: loaded Tainted: P OE ------------ 3.10.0-957.21.3.el7.x86_64 #1
kernel: Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 10/02/2018
kernel: Call Trace:
kernel: [<ffffffff9dd63107>] dump_stack+0x19/0x1b
kernel: [<ffffffff9d697768>] __warn+0xd8/0x100
kernel: [<ffffffff9d6978ad>] warn_slowpath_null+0x1d/0x20
kernel: [<ffffffff9d944b03>] blk_cleanup_queue+0x1a3/0x1b0
kernel: [<ffffffffc0cd1f3f>] dmp_unregister_disk+0x9f/0xd0 [vxdmp]
kernel: [<ffffffffc0cd7a08>] dmp_remove_mp_node+0x188/0x1e0 [vxdmp]
kernel: [<ffffffffc0cd7b45>] dmp_destroy_global_db+0xe5/0x2c0 [vxdmp]
kernel: [<ffffffffc0cde6cd>] dmp_unload+0x1d/0x30 [vxdmp]
kernel: [<ffffffffc0d0743a>] cleanup_module+0x5a/0xd0 [vxdmp]
kernel: [<ffffffff9d71692e>] SyS_delete_module+0x19e/0x310
kernel: [<ffffffff9dd75ddb>] system_call_fastpath+0x22/0x27
kernel: --[ end trace fd834bc7817252be ]--

RESOLUTION:
The queue flags are modified to handle this situation and not to log such warning messages.

* 3988238 (Tracking ID: 3988578)

SYMPTOM:
Encrypted volume creation fails on RHEL 8

DESCRIPTION:
On the RHEL 8 platform, python3 gets installed by default. However, the Python script that is used to create encrypted volumes and to communicate with the Key Management Service (KMS) is not compatible with python3. Additionally, an 'unsupported protocol' error is reported for the SSL protocol SSLv23 that is used in the PyKMIP library to communicate with the KMS.

RESOLUTION:
The python script is made compatible with python2 and python3. A new option ssl_version is made available in the /etc/vx/enc-kms-kmip.conf file to represent the SSL version to be used by the KMIP client. The 'unsupported protocol' error is addressed by using the protocol version PROTOCOL_TLSv1.
The following is an example of the sample configuration file:
[client]
host = kms-enterprise.example.com
port = 5696
keyfile = /etc/vx/client-key.pem
certfile = /etc/vx/client-crt.pem
cacerts = /etc/vx/cacert.pem
ssl_version = PROTOCOL_TLSv1

* 3988843 (Tracking ID: 3989796)

SYMPTOM:
Existing package failed to load on RHEL 8.1 setup.

DESCRIPTION:
RHEL 8.1 is a new release and hence VxVM module is compiled with this new kernel along with other few other changes .

RESOLUTION:
changes have been done to make VxVM compatible with RHEL 8.1

Patch ID: VRTSamf-7.4.1.3500

* 4085648 (Tracking ID: 4072335)

SYMPTOM:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 6(RHEL8.6).

DESCRIPTION:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux
versions later than RHEL8 Update 5.

RESOLUTION:
Veritas Infoscale Availability support for Red Hat Enterprise Linux 8 Update
6(RHEL8.6) is now introduced.

Patch ID: VRTSamf-7.4.1.3400

* 4054323 (Tracking ID: 4001565)

SYMPTOM:
On Solaris 11.4, IMF fails to provide notifications when Oracle processes stop.

DESCRIPTION:
On Solaris 11.4, when Oracle processes stop, IMF provides notification to Oracle agent, but the monitor is not scheduled. As as result, agent fails intelligent monitoring.

RESOLUTION:
Oracle agent now provides notifications when Oracle processes stop.

Patch ID: VRTSamf-7.4.1.3300

* 4045476 (Tracking ID: 4041596)

SYMPTOM:
A cluster node panics when the arguments passed to a process that is registered with AMF exceeds 8K characters.

DESCRIPTION:
This issue occurs due to improper parsing and handling of argument lists that are passed to processes registered with AMF.

RESOLUTION:
AMF is updated to correctly parse and handle argument lists for processes.

* 4053181 (Tracking ID: 4053171)

SYMPTOM:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 5(RHEL8.5).

DESCRIPTION:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux
versions later than RHEL8 Update 4.

RESOLUTION:
Veritas Infoscale Availability support for Red Hat Enterprise Linux 8 Update
5(RHEL8.5) is now introduced.

Patch ID: VRTSamf-7.4.1.3200

* 4044340 (Tracking ID: 4041703)

SYMPTOM:
The system panics when the Mount and the CFSMount agents fail to register with AMF.

DESCRIPTION:
This issue occurs after an operating system upgrade. The agents fail to register with AMF, which leads to a system panic.

RESOLUTION:
Added support for cursor in mount structures starting RHEL 8.4.

Patch ID: VRTSamf-7.4.1.2900

* 4037950 (Tracking ID: 4037048)

SYMPTOM:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 4(RHEL8.4).

DESCRIPTION:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux
versions later than RHEL8 Update 3.

RESOLUTION:
Veritas Infoscale Availability support for Red Hat Enterprise Linux 8 Update
4(RHEL8.4) is now introduced.

Patch ID: VRTSamf-7.4.1.2800

* 4019003 (Tracking ID: 4018791)

SYMPTOM:
A cluster node panics when the AMF module module attempts to access an executable binary or a script using its absolute path.

DESCRIPTION:
A cluster node panics and generates a core dump, which indicates that an issue with the AMF module. The AMF module function that locates an executable binary or a script using its absolute path fails to handle NULL values.

RESOLUTION:
The AMF module is updated to handle NULL values when locating an executable binary or a script using its absolute path.

* 4019679 (Tracking ID: 4019674)

SYMPTOM:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8 Update 3(RHEL8.3).

DESCRIPTION:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux versions later than RHEL8 Update 2.

RESOLUTION:
Veritas Infoscale Availability support for Red Hat Enterprise Linux 8 Update 3(RHEL8.3) is now introduced.

Patch ID: VRTSamf-7.4.1.2100

* 4002154 (Tracking ID: 4002150)

SYMPTOM:
Veritas Cluster Server does not support Red Hat Enterprise Linux 8 Update 2(RHEL8.2).

DESCRIPTION:
Veritas Cluster Server does not support Red Hat Enterprise Linux versions later than RHEL8.1 .

RESOLUTION:
Veritas Cluster Server support for Red Hat Enterprise Linux 8 Update 2(RHEL8.2) is now introduced.

Patch ID: VRTSamf-7.4.1.1600

* 3990020 (Tracking ID: 3990016)

SYMPTOM:
Veritas Cluster Server does not support Red Hat Enterprise Linux 8
Update 1(RHEL8.1).

DESCRIPTION:
Veritas Cluster Server does not support Red Hat Enterprise Linux
versions later than RHEL8.0 .

RESOLUTION:
Veritas Cluster Server support for Red Hat Enterprise Linux 8 Update
1(RHEL8.1) is now introduced.

Patch ID: VRTSvxfen-7.4.1.3400

* 4085614 (Tracking ID: 4072335)

SYMPTOM:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 6(RHEL8.6).

DESCRIPTION:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux
versions later than RHEL8 Update 5.

RESOLUTION:
Veritas Infoscale Availability support for Red Hat Enterprise Linux 8 Update
6(RHEL8.6) is now introduced.

Patch ID: VRTSvxfen-7.4.1.3300

* 4051532 (Tracking ID: 4057308)

SYMPTOM:
After an InfoScale upgrade, the updated values of vxfen tunables that are used when loading the corresponding module fail to persist.

DESCRIPTION:
When the value of a tunable in /etc/sysconfig/vxfen is changed before an RPM upgrade, the existing value gets reset to the default value.

RESOLUTION:
The vxfen module is updated so that its existing tunable values in /etc/sysconfig/vxfen can be retained even after an RPM upgrade.

Patch ID: VRTSvxfen-7.4.1.3200

* 4053182 (Tracking ID: 4053171)

SYMPTOM:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 5(RHEL8.5).

DESCRIPTION:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux
versions later than RHEL8 Update 4.

RESOLUTION:
Veritas Infoscale Availability support for Red Hat Enterprise Linux 8 Update
5(RHEL8.5) is now introduced.

Patch ID: VRTSvxfen-7.4.1.2900

* 4028780 (Tracking ID: 4029261)

SYMPTOM:
An entire InfoScale cluster may go down unexpectedly if one of its nodes receives a RECONFIG message during a shutdown or a restart operation.

DESCRIPTION:
If a cluster node receives a RECONFIG message while a shutdown or a restart operation is in progress, it may participate in the fencing race. The node may also win the race and then proceed to shut down. If this situation occurs, the fencing module panics the nodes that lost the race, which may cause the entire cluster to go down.

RESOLUTION:
This hotfix updates the fencing module so that it stops a cluster node from joining a race, if it receives a RECONFIG message while a shutdown or a restart operation is in progress.

* 4037951 (Tracking ID: 4037048)

SYMPTOM:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 4(RHEL8.4).

DESCRIPTION:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux
versions later than RHEL8 Update 3.

RESOLUTION:
Veritas Infoscale Availability support for Red Hat Enterprise Linux 8 Update
4(RHEL8.4) is now introduced.

Patch ID: VRTSvxfen-7.4.1.2800

* 4000746 (Tracking ID: 4000745)

SYMPTOM:
The VxFEN process fails to start due to late discovery of the VxFEN disk group.

DESCRIPTION:
When I/O fencing starts, the VxFEN startup script creates this /etc/vxfentab file on each node. During disk-based fencing, the VxVM module may take longer time to discover the VxFEN disk group. Because of this delay, the 'generate disk list' opreration times out. Therefore, the VxFEN process fails to start and reports the following error: 'ERROR: VxFEN cannot generate vxfentab because vxfendg does not exist'

RESOLUTION:
A new tunable, getdisks_timeout, is introduced to specify the timeout value for the VxFEN disk group discovery. The maximum and the default value for this tunable is 600 seconds. You can set the value of this tunable by adding an getdisks_timeout=<time_in_sec> entry in the /etc/vxfenmode file.

* 4019680 (Tracking ID: 4019674)

SYMPTOM:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8 Update 3(RHEL8.3).

DESCRIPTION:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux versions later than RHEL8 Update 2.

RESOLUTION:
Veritas Infoscale Availability support for Red Hat Enterprise Linux 8 Update 3(RHEL8.3) is now introduced.

Patch ID: VRTSgab-7.4.1.3400

* 4085645 (Tracking ID: 4072335)

SYMPTOM:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 6(RHEL8.6).

DESCRIPTION:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux
versions later than RHEL8 Update 5.

RESOLUTION:
Veritas Infoscale Availability support for Red Hat Enterprise Linux 8 Update
6(RHEL8.6) is now introduced.

Patch ID: VRTSgab-7.4.1.3300

* 4054264 (Tracking ID: 4046413)

SYMPTOM:
After a node is added to or removed from a cluster, the GAB node count or the fencing quorum is not updated.

DESCRIPTION:
The gabconfig -m <node_count> command returns an error even if the correct node count is provided.

RESOLUTION:
To address this issue, a parsing issue with the GAB module is fixed.

* 4054265 (Tracking ID: 4046418)

SYMPTOM:
The GAB module starts up even if LLT is not configured.

DESCRIPTION:
Since the GAB service depends on the LLT service, if LLT fails to start or if it is not configured, GAB should not start.

RESOLUTION:
The GAB module is updated to start only if LLT is configured.

* 4060792 (Tracking ID: 4057312)

SYMPTOM:
Load time vxfen tunables fail to persist the updated value after upgrade.

DESCRIPTION:
Typically, when any tunable value of GAB from /etc/sysconfig/gab is changed before rpm upgrade, it is observed that the old tunable values get updated with the default values.

RESOLUTION:
All the tunable values of GAB from /etc/sysconfig/gab will persist old values even after rpm upgrade.

Patch ID: VRTSgab-7.4.1.3200

* 4053180 (Tracking ID: 4053171)

SYMPTOM:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 5(RHEL8.5).

DESCRIPTION:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux
versions later than RHEL8 Update 4.

RESOLUTION:
Veritas Infoscale Availability support for Red Hat Enterprise Linux 8 Update
5(RHEL8.5) is now introduced.

Patch ID: VRTSgab-7.4.1.2900

* 4037949 (Tracking ID: 4037048)

SYMPTOM:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8
Update 4(RHEL8.4).

DESCRIPTION:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux
versions later than RHEL8 Update 3.

RESOLUTION:
Veritas Infoscale Availability support for Red Hat Enterprise Linux 8 Update
4(RHEL8.4) is now introduced.

Patch ID: VRTSgab-7.4.1.2800

* 4016486 (Tracking ID: 4011683)

SYMPTOM:
The GAB module failed to start and the system log messages indicate failures with the mknod command.

DESCRIPTION:
The mknod command fails to start the GAB module because its format is invalid. If the names of multiple drivers in an environment contain the value "gab" as a substring, all their major device numbers get passed on to the mknod command. Instead, the command must contain the major device number for the GAB driver only.

RESOLUTION:
This hotfix addresses the issue so that the GAB module starts successfully even when other driver names in the environment contain "gab" as a substring.

* 4016487 (Tracking ID: 4007726)

SYMPTOM:
When a GAB message that is longer than the value specified by GAB_MAX_MSGSIZE is transfered, an error message is added to the VCS logs. However the error message is not sufficiently descriptive.

DESCRIPTION:
The current error message does not mention the type of the GAB message that was transferred and the port that was used to transfer the message. Thus, the error message is not useful for troubleshooting.

RESOLUTION:
This hotfix addresses the issue by enhacing the error message that is logged. It now mentions whether the message type was DIRECTED or BROADCAST and also the port number that was used to transer the GAB message.

* 4019677 (Tracking ID: 4019674)

SYMPTOM:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux 8 Update 3(RHEL8.3).

DESCRIPTION:
Veritas Infoscale Availability does not support Red Hat Enterprise Linux versions later than RHEL8 Update 2.

RESOLUTION:
Veritas Infoscale Availability support for Red Hat Enterprise Linux 8 Update 3(RHEL8.3) is now introduced.

Patch ID: VRTSgab-7.4.1.2100

* 4002152 (Tracking ID: 4002150)

SYMPTOM:
Veritas Cluster Server does not support Red Hat Enterprise Linux 8 Update 2(RHEL8.2).

DESCRIPTION:
Veritas Cluster Server does not support Red Hat Enterprise Linux versions later than RHEL8.1 .

RESOLUTION:
Veritas Cluster Server support for Red Hat Enterprise Linux 8 Update 2(RHEL8.2) is now introduced.

Patch ID: VRTSgab-7.4.1.1600

* 3990018 (Tracking ID: 3990016)

SYMPTOM:
Veritas Cluster Server does not support Red Hat Enterprise Linux 8
Update 1(RHEL8.1).

DESCRIPTION:
Veritas Cluster Server does not support Red Hat Enterprise Linux
versions later than RHEL8.0 .

RESOLUTION:
Veritas Cluster Server support for Red Hat Enterprise Linux 8 Update
1(RHEL8.1) is now introduced.

INSTALLING THE PATCH
--------------------
Run the Installer script to automatically install the patch:
-----------------------------------------------------------
Please be noted that the installation of this P-Patch will cause downtime.

To install the patch perform the following steps on at least one node in the cluster:
1. Copy the patch infoscale-rhel8_x86_64-Patch-7.4.1.3200.tar.gz to /tmp
2. Untar infoscale-rhel8_x86_64-Patch-7.4.1.3200.tar.gz to /tmp/hf
# mkdir /tmp/hf
# cd /tmp/hf
# gunzip /tmp/infoscale-rhel8_x86_64-Patch-7.4.1.3200.tar.gz
# tar xf /tmp/infoscale-rhel8_x86_64-Patch-7.4.1.3200.tar
3. Install the hotfix(Please be noted that the installation of this P-Patch will cause downtime.)
# pwd /tmp/hf
# ./installVRTSinfoscale741P3200 [<host1> <host2>...]

You can also install this patch together with 7.4.1 base release using Install Bundles
1. Download this patch and extract it to a directory
2. Change to the Veritas InfoScale 7.4.1 directory and invoke the installer script
with -patch_path option where -patch_path should point to the patch directory
# ./installer -patch_path [<path to this patch>] [<host1> <host2>...]

Install the patch manually:
--------------------------
Manual installation is not recommended.

REMOVING THE PATCH
------------------
Manual uninstallation is not recommended.

SPECIAL INSTRUCTIONS
--------------------
NONE

OTHERS
------
NONE

1. This Platform patch needs to be installed on previous cumulative patch InfoScale 7.4.1 Patch 3100.
In case this is latest cumulative patch: 7.4.1 Update6 release for RHEL8.

2. This cumulative patch contains RHEL8 platform patches, and you can directly install the CP.

Note : Request to check the support.veritas.com downloads and follow the patch release dates.

Applies to the following product releases

InfoScale Enterprise 7.4.1

Release date: 2019-02-01

End of standard support: 2024-07-31

Sustaining support starts: 2026-07-31

End of support life: To be determined

InfoScale Foundation 7.4.1

Release date: 2019-02-01

End of standard support: 2024-07-31

Sustaining support starts: 2026-07-31

End of support life: To be determined

InfoScale Availability 7.4.1

Release date: 2019-02-01

End of standard support: 2024-07-31

Sustaining support starts: 2026-07-31

End of support life: To be determined

InfoScale Storage 7.4.1

Release date: 2019-02-01

End of standard support: 2024-07-31

Sustaining support starts: 2026-07-31

End of support life: To be determined

This update requires

7.4.1 Update6 release for RHEL8

Release date: 2022-01-14

7.4.1 Update6 release for RHEL8

Update files

	File name	Description	Version	Platform	Size

Choose an account to download the files you selected.