* * * READ ME * * *
                       * * * InfoScale 8.0 * * *
                         * * * Patch 1800 * * *
                         Patch Date: 2022-09-26


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 8.0 Patch 1800


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


PACKAGES AFFECTED BY THE PATCH
------------------------------
VRTSamf
VRTSaslapm
VRTScps
VRTSdbac
VRTSdbed
VRTSfsadv
VRTSgab
VRTSglm
VRTSgms
VRTSllt
VRTSodm
VRTSperl
VRTSpython
VRTSrest
VRTSspt
VRTSvcs
VRTSvcsag
VRTSvcsea
VRTSveki
VRTSvxfen
VRTSvxfs
VRTSvxvm


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


SUMMARY OF INCIDENTS FIXED BY THE PATCH
---------------------------------------
Patch ID: VRTScps-8.0.0.1800
* 4073050 (4018218) Secure communication between a CP Server and a CP Client cannot be established using TLSv1.2
Patch ID: VRTScps-8.0.0.1200
* 4066225 (4056666) The Error writing to database message may intermittently appear in syslogs on CP servers.
Patch ID: VRTSvcsea-8.0.0.1800
* 4030767 (4088595) hapdbmigrate utility fails to online the oracle service group
* 4079559 (4064917) As a part of Oracle 21c support, fixed the issue Oracle agent fails to generate ora_api using the build_oraapi.sh script
Patch ID: VRTSgab-8.0.0.1800
* 4089723 (4089722) VRTSgab , VRTSamf and VRTSdbed driver does not load on RHEL and SLES platform.
Patch ID: VRTSamf-8.0.0.1800
* 4089724 (4089722) VRTSgab , VRTSamf and VRTSdbed driver does not load on RHEL and SLES platform.
Patch ID: VRTSdbac-8.0.0.1800
* 4089728 (4089722) VRTSgab , VRTSamf and VRTSdbed driver does not load on RHEL and SLES platform.
Patch ID: VRTSvxvm-8.0.0.1800
* 4067609 (4058464) vradmin resizevol fails when FS is not mounted on master.
* 4067635 (4059982) vradmind need not check for rlink connect during migrate.
* 4070098 (4071345) Unplanned fallback synchronisation is unresponsive
* 4078531 (4075860) Tutil putil rebalance flag is not getting cleared during +4 or more node addition
* 4079345 (4069940) FS mount failed during Cluster configuration on 24-node physical HP BOM2 setup.
* 4080041 (4056953) 3PAR PE LUNs are reported in error state by 3PAR ASL.
* 4080105 (4045837) Sub disks are in relocate state after exceed fault slave node panic.
* 4080122 (4044068) After disc replacement, Replace Node operation failed at Configure Netbackup stage.
* 4080269 (4044898) Copy rlink tags from reprec to info rec, through vxdg upgrade path.
* 4080276 (4065145) multivolume and vset not able to overwrite encryption tags on secondary.
* 4080277 (3966157) SRL batching feature is broken
* 4080579 (4077876) System is crashed when EC log replay is in progress after node reboot.
* 4080845 (4058166) Increase DCM log size based on volume size without exceeding region size limit of 4mb.
* 4081790 (4080373) SFCFSHA configuration failed on RHEL 8.4.
* 4083337 (4081890) On RHEL8 NBFS/Access commands like python3, sort, sudo, ssh, etc are generating core dump during execution of the command mkfs.vxfs & mkfs.ext4.
* 4085619 (4086718) VxVM modules fail to load with latest minor kernel of SLES15SP2
* 4087233 (4086856) For Appliance FLEX product using VRTSdocker-plugin, need to add platform-specific dependencies service ( docker.service and podman.service ) change.
* 4087439 (4088934) Kernel Panic while running LM/CFS CONFORMANCE - variant (SLES15SP3)
* 4088076 (4054685) In case of CVR environment, RVG recovery gets hung in linux platforms.
* 4088483 (4088484) Failed to load DMP_APM NVME modules
* 4088762 (4087099) DG is not imported after upgrade to InfoScale 8.0u1 on RHEL8.6.
Patch ID: VRTSaslapm 8.0.0.1800
* 4080041 (4056953) 3PAR PE LUNs are reported in error state by 3PAR ASL.
* 4088762 (4087099) DG is not imported after upgrade to InfoScale 8.0u1 on RHEL8.6.
* 4066952 (3951527) Data loss on DR site seen while upgrading from Infoscale 7.3.1 or before to 7.4.x or later versions.
Patch ID: VRTSvxvm-8.0.0.1700
* 4083792 (4082799) A security vulnerability exists in the third-party component libcurl.
Patch ID: VRTSvxvm-8.0.0.1600
* 4057420 (4060462) Nidmap information is not cleared after a node leaves, resulting in add node failure subsequently.
* 4062799 (4064208) Node failed to join the existing cluster after bits are upgraded to a newer version.
* 4065841 (4065495) Add support for DELL EMC PowerStore.
* 4066213 (4052580) Supporting multipathing for NVMe devices under VxVM.
* 4068407 (4068404) ASL request for HPE 3PAR/Primera/Alletra 9000 ALUA support.
Patch ID: VRTSvxvm-8.0.0.1200
* 4057420 (4060462) Instant restore failed for a snapshot created on older version DG.
* 4062799 (4064208) Instant restore failed for a snapshot created on older version DG.
* 4065628 (4065627) VxVM Modules failed to load after OS upgrade .
* 4066259 (4062576) hastop -local never finishes on Rhel8.4 and RHEL8.5 servers with latest minor kernels due to hang in vxdg deport command.
* 4066735 (4057526) Adding check for init while accessing /var/lock/subsys/ path in vxnm-vxnetd.sh script.
* 4066834 (4046007) The private disk region gets corrupted if the cluster name is changed in FSS environment.
Patch ID: VRTSvxfs-8.0.0.1800
* 4068960 (4073203) Veritas file replication might generate a core while replicating the files to target.
* 4071108 (3988752) Use ldi_strategy() routine instead of bdev_strategy() for IO's in solaris.
* 4072228 (4037035) VxFS should have the ability to control the number of inactive processing threads.
* 4078335 (4076412) Addressing Executive Order (EO) 14028,  initial requirements intended to improve the Federal Governments investigative and remediation capabilities related to cybersecurity incidents.
* 4078520 (4058444) Loop mounts using files on VxFS fail on Linux systems.
* 4079142 (4077766) VxFS kernel module might leak memory during readahead of directory blocks.
* 4079173 (4070217) Command fsck might fail with 'cluster reservation failed for volume' message for a disabled cluster-mounted filesystem.
* 4082260 (4070814) Security Vulnerability observed in Zlib a third party component VxFS uses.
* 4082865 (4079622) Existing migration read/write iter operation handling is not fully functional as vxfs uses normal read/write file operation only.
* 4083335 (4076098) FS migration on Linux machines with falcon-sensor enabled, might fail.
* 4085623 (4085624) While running fsck, fsck might dump core.
* 4085839 (4085838) Command fsck may generate core due to processing of zero size attribute inode.
* 4086085 (4086084) VxFS mount operation causes system panic.
* 4088341 (4065575) Write operation might be unresponsive on a local mounted VxFS filesystem in a no-space condition
Patch ID: VRTSvxfs-8.0.0.1700
* 4081150 (4079869) Security Vulnerability in VxFS third party components
* 4083948 (4070814) Security Vulnerability in VxFS third party component Zlib
Patch ID: VRTSvxfs-8.0.0.1200
* 4055808 (4062971) Enable partition directory on WORM file system
* 4056684 (4056682) New features information on a filesystem with fsadm(file system administration utility) from a device is not displayed.
* 4062606 (4062605) Minimum retention time cannot be set if the maximum retention time is not set.
* 4065565 (4065669) Creating non-WORM checkpoints fails when the tunables - minimum retention time and maximum retention time are set.
* 4065651 (4065666) Enable partition directory on WORM file system having WORM enabled on files with retention period not expired.
Patch ID: VRTSvxfs-8.0.0.1100
* 4061114 (4052883) VxFS support for RHEL 8.5.
Patch ID: VRTSvxfen-8.0.0.1800
* 4087166 (4087134) The error message 'Touch /var/VRTSvcs/log/vxfen/vxfen.log failed' appears after starting vxfen service.
* 4088061 (4089052) On RHEL9, Coordination Point Replacement operation is causing node panic
Patch ID: VRTSveki-8.0.0.1800
* 4056647 (4055072) Upgrading VRTSveki package using yum reports error
Patch ID: VRTSveki-8.0.0.1200
* 4070027 (4066550) Increasing Veki systemd service start timeout to 300 seconds
Patch ID: VRTSvcsag-8.0.0.1800
* 4030767 (4088595) hapdbmigrate utility fails to online the oracle service group
* 4058802 (4073842) SFAE changes to support Oracle 21c
* 4079372 (4073842) SFAE changes to support Oracle 21c
* 4079559 (4064917) As a part of Oracle 21c support, fixed the issue Oracle agent fails to generate ora_api using the build_oraapi.sh script
* 4081774 (4083099) AzureIP resource fails to go offline when OverlayIP is configured.
Patch ID: VRTSvcs-8.0.0.1800
* 4084675 (4089059) gcoconfig.log file permission is changes to 0600.
Patch ID: VRTSvcs-8.0.0.1400
* 4065820 (4065819) Protocol version upgrade failed.
Patch ID: VRTSspt-8.0.0.1200
* 4046148 (4076850) Memory related stat collection is not done in linux.
* 4056649 (4056648) Metasave collection can be executed on a mounted filesystem.
* 4075110 (4018783) Metasave collection and restore takes significant amount of time.
* 4076729 (4076837) Need to collect vxtunefs output for all VxFS filesystems during FirstLook collection.
* 4079133 (4086188) FirstLook stat collection time interval improvement
* 4085652 (4086301) vxfsstat is collected for only one filesystem through FirstLook
* 4086194 (4086272) Addition of metasave and vxbench command files for RHEL9 to VRTSSPT
Patch ID: VRTSsfmh-vom-HF0800200
* 4086839 (4086838) at_migrate.pl script does not work with VIOM versions higher than 7.x
* 4086843 (4086841) Product Enhancement - US Federal Executive Order - Logging changes (EL1 Logging and auditing requirements)
* 4086847 (4086846) Product Enhancement - Detection of VIOM certificates expiry time and renew
* 4086852 (4086851) Security Vulnerabilities fixes in VIOM
* 4086855 (4086853) VIOM logs were growing beyond defined limit on Windows.
* 4086861 (4086860) Faults are not listing under faults tab in VIOM GUI.
* 4086867 (4086866) Mitigation for CVE-2020-9484 vulnerability.
* 4086873 (4086872) Enable 'Flexible Storage Sharing' check box is disabled in Create Disk Group operation on cluster in VIOM GUI.
* 4086990 (4086989) Product Enhancement - Faults to detect VVR Rlink detached and SRL disabled
Patch ID: VRTSsfmh-vom-HF0800120
* 4080541 (4080538) Spring framework upgrade to 5.3.21
* 4080542 (4080540) Tomcat upgraded to 9.0.64
* 4080546 (4080545) Upgraded google-gson jar to latest available version : 2.9.0
* 4080727 (4080726) Product Enhancement - Support for Forward Secrecy Ciphers for xprtld service
Patch ID: VRTSsfmh-vom-HF0800110
* 4076527 (4076526) Tomcat upgraded to 9.0.63
* 4076531 (4076530) JAVA upgrade to 8.332.08.1
* 4076534 (4076533) Spring framework upgrade to 5.3.19
* 4076791 (4076790) jackson-databind to 2.13.2.2
* 4076798 (4076797) PostgreSQL JDBC Driver upgraded to 42.3.4
* 4076801 (4076800) PostgreSQL Database Server upgraded to 10.21
Patch ID: VRTSsfmh-vom-HF0800100
* 4067024 (4067023) /dev/nul file is getting created on VIOM Linux management server
* 4067034 (4067033) Product Enhancement - InfoScale licensing reconciliation tool
* 4067041 (4067040) log4j2 vulnerabilities fixes
* 4067046 (4067045) Apache Tomcat vulnerability issue CVE-2022-23181 in versions below 9.0.58.
* 4067050 (4067049) 'Per Core License Information' report displays incorrect License information.
* 4067053 (4067052) VIOM Web APIs /vom/api/gencert and /vom/api/login issues.
* 4067056 (4067055) Product Enhancement - Support for InfoScale servers hosted in AWS cloud environments
* 4067058 (4067057) Product Enhancement - Discovers FULLFSCK flag on VxFS file system and generates fault on file system corruption.
* 4067130 (4067129) 'InfoScale version' shows N/A for some of the InfoScale servers.
* 4067133 (4067132) Security fix - A reflected cross-site scripting (XSS) vulnerability allows a malicious VIOM user to inject malicious script into another users browser (CWE-79).
* 4067136 (4067135) Security fix - An absolute path transversal vulnerability allows a user to gain unauthorized access to resources on the server (CWE-36).
* 4067147 (4067146) Product Enhancement - Global VVR Monitoring Thresholds
Patch ID: VRTSrest-2.0.0.1300
* 4088973 (4089451) When a read-only filesystem was created on a Volume, GET on mountpoint's details was throwing error .
* 4089033 (4089453) Some VCS REST APIs were crashing the Gunicorn worker.
* 4089041 (4089449) GET resources API on empty service group was throwing an error.
* 4089046 (4089448) Logging in REST API is not EO-compliant.
Patch ID: VRTSpython-3.9.2.22
* 4075150 (4075149) Security vulnerabilities detected in OpenSSL packaged with VRTSperl/VRTSpython released with Infoscale 8.0.
Patch ID: VRTSperl-5.34.0.3
* 4072234 (4069607) Security vulnerability detected on VRTSperl 5.34.0.0 released with Infoscale 8.0.
* 4075150 (4075149) Security vulnerabilities detected in OpenSSL packaged with VRTSperl/VRTSpython released with Infoscale 8.0.
Patch ID: VRTSodm-8.0.0.1800
* 4089136 (4089135) VRTSodm driver will not load with VRTSvxfs patch.
Patch ID: VRTSllt-8.0.0.1800
* 4061158 (4061156) IO error on /sys/kernel/slab folder
* 4079637 (4079636) LLT over IPsec is causing node crash
* 4079662 (3981917) Support LLT UDP multiport on 1500 MTU based networks.
* 4080630 (4046953) Delete / disable confusing messages.
Patch ID: VRTSgms-8.0.0.1800
* 4079190 (4071136) gms.config is not created when installing GMS rpm.
Patch ID: VRTSglm-8.0.0.1800
* 4089163 (4089162) The GLM module fails to load.
Patch ID: VRTSdbed-8.0.0.1800
* 4079372 (4073842) SFAE changes to support Oracle 21c


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

Patch ID: VRTScps-8.0.0.1800

* 4073050 (Tracking ID: 4018218)

SYMPTOM:
Secure communication between a CP Server and a CP Client cannot be established using TLSv1.2

DESCRIPTION:
Secure communication between a CP Server and a CP Client cannot be established using TLSv1.2.

RESOLUTION:
This hotfix updates the VRTScps module so that InfoScale CP Client can establish secure communication with a CP server using TLSv1.2. However, to enable TLSv1.2 communication between the CP client and CP server after installing this hotfix, you must perform the following steps:

To configure TLSv1.2 for CP server
1. Stop the process resource that has pathname="/opt/VRTScps/bin/vxcpserv"
   # hares -offline <vxcpserv> -sys <sysname> 
2. Check that the vxcpserv daemon is stopped using the following command:
   # ps -eaf | grep "/opt/VRTScps/bin/vxcpserv"
3. When the vxcpserv daemon is stopped, edit the "/etc/vxcps_ssl.properties" file and make the following changes:
   a. Remove or comment the entry: openSSL.server.requireTLSv1 = true 
   b. Add a new entry: openSSL.server.requireTLSv1.2 = true
4. Start the process resource that has pathname="/opt/VRTScps/bin/vxcpserv"
   # hares -offline <vxcpserv> -sys <sysname>

To configure TLSv1.2 for CP Client
Edit the "/etc/vxcps_ssl.properties" file and make the following changes:
   a. Remove or comment the entry: openSSL.server.requireTLSv1 = true 
   b. Add a new entry: openSSL.server.requireTLSv1.2 = true

Patch ID: VRTScps-8.0.0.1200

* 4066225 (Tracking ID: 4056666)

SYMPTOM:
The Error writing to database message may appear in syslogs intermittently on InfoScale CP servers.

DESCRIPTION:
Typically, when a coordination point server (CP server) is shared among multiple InfoScale clusters, the following messages may intermittently appear in syslogs:
CPS CRITICAL V-97-1400-501 Error writing to database! :database is locked.
These messages appear in the context of the CP server protocol handshake between the clients and the server.

RESOLUTION:
The CP server is updated so that, in addition to its other database write operations, all the ones for the CP server protocol handshake action are also synchronized.

Patch ID: VRTSvcsea-8.0.0.1800

* 4030767 (Tracking ID: 4088595)

SYMPTOM:
hapdbmigrate utility fails to online the oracle service group due to a timing issue.

DESCRIPTION:
hapdbmigrate utility fails to online the oracle service group due to a timing issue.
example:
./hapdbmigrate -pdbres pdb1_res -cdbres cdb2_res -XMLdirectory /oracle_xml
Cluster prechecks and validation                                 Done
Taking PDB resource [pdb1_res] offline                           Done
Modification of cluster configuration                            Done
VCS ERROR V-16-41-39 Group [CDB2_grp] is not ONLINE after 300 seconds on %vcs_node%

VCS ERROR V-16-41-41 Group [CDB2_grp] is not ONLINE on some nodes in the cluster

Bringing PDB resource [pdb1_res] online on CDB resource [cdb2_res]Done

For further details, see '/var/VRTSvcs/log/hapdbmigrate.log'

RESOLUTION:
hapdbmigrate utility modified to ensure enough time elapses between probe of PDB resource and online of CDB group.

* 4079559 (Tracking ID: 4064917)

SYMPTOM:
Oracle agent fails to generate ora_api (which is used for Intentional Offline functionality of Oracle agent) using build_oraapi.sh script for Oracle 21c.

DESCRIPTION:
The build_oraapi.sh script could not connect to library named libdbtools21.a, as on the new Oracle 21c environment generic library is present i.e. '$ORACLE_HOME/rdbms/lib/libdbtools.a'.

RESOLUTION:
This script on Oracle 21c database environment will pick generic library and on older database environments it will pick Database version specific library.

Patch ID: VRTSgab-8.0.0.1800

* 4089723 (Tracking ID: 4089722)

SYMPTOM:
VRTSgab , VRTSamf and VRTSdbed driver does not load on RHEL and SLES platform.

DESCRIPTION:
Need recompilation of VRTSgab , VRTSamf and VRTSdbed with latest changes.

RESOLUTION:
Recompiled the VRTSgab , VRTSamf and VRTSdbed.

Patch ID: VRTSamf-8.0.0.1800

* 4089724 (Tracking ID: 4089722)

SYMPTOM:
VRTSgab , VRTSamf and VRTSdbed driver does not load on RHEL and SLES platform.

DESCRIPTION:
Need recompilation of VRTSgab , VRTSamf and VRTSdbed with latest changes.

RESOLUTION:
Recompiled the VRTSgab , VRTSamf and VRTSdbed.

Patch ID: VRTSdbac-8.0.0.1800

* 4089728 (Tracking ID: 4089722)

SYMPTOM:
VRTSgab , VRTSamf and VRTSdbed driver does not load on RHEL and SLES platform.

DESCRIPTION:
Need recompilation of VRTSgab , VRTSamf and VRTSdbed with latest changes.

RESOLUTION:
Recompiled the VRTSgab , VRTSamf and VRTSdbed.

Patch ID: VRTSvxvm-8.0.0.1800

* 4067609 (Tracking ID: 4058464)

SYMPTOM:
vradmin resizevol fails  when FS is not mounted on master.

DESCRIPTION:
vradmin resizevol cmd resizes datavolume, FS on the primary site whereas on the secondary site it resizes only datavolume as FS is not mounted on the secondary site.

vradmin resizevol cmd ships the cmd to logowner at vradmind level and vradmind on logowner in turn tries to ship the lowlevel vxcommands to master at vradmind level and then finally cmd gets executed on master.

RESOLUTION:
Changes introduced to ship the cmd to the node on which FS is mounted. cvm nodename must be provided where FS gets mounted which is then used by vradmind to ship cmd to that respective mounted node.

* 4067635 (Tracking ID: 4059982)

SYMPTOM:
In container environment, vradmin migrate cmd fails multiple times due to rlink not in connected state.

DESCRIPTION:
In VVR, rlinks are disconnected and connected back during the process of replication lifecycle. And, in this mean time when vradmin migrate cmd gets executed it experience errors. It internally causes vradmind to make configuration changes multiple times which impact further vradmin commands getting executed.

RESOLUTION:
vradmin migrate cmd requires rlink data to be up-to-date on both primary and secondary. It internally executes low-level cmds like vxrvg makesecondary and vxrvg makeprimary to change the role of primary and secondary. These cmds doesn't depend on rlink to be in connected state.  Changes are done to remove the rlink connection handling.

* 4070098 (Tracking ID: 4071345)

SYMPTOM:
Replication is unresponsive after failed site is up.

DESCRIPTION:
Autosync and unplanned fallback synchronisation had issues in a mix of cloud and non-cloud Volumes in RVG.
After a cloud volume is found rest of the volumes were getting ignored for synchronisation

RESOLUTION:
Fixed condition to make it iterate over all Volumes.

* 4078531 (Tracking ID: 4075860)

SYMPTOM:
On RHEL8 NBFS/Access commands like python3, sort, sudo, ssh, etc are generating core dump during execution of the command mkfs.vxfs & mkfs.ext4 in parallel

DESCRIPTION:
On RHEL8 NBFS/Access commands like python3, sort, sudo, ssh, etc are generating core dump during execution of the command mkfs.vxfs & mkfs.ext4 in parallel. This was happening due to missing fpu armor protection for FPU instruction set.

RESOLUTION:
Fix is added to use FPU protection while using FPU instruction set

* 4079345 (Tracking ID: 4069940)

SYMPTOM:
FS mount failed during Cluster configuration on 24-node physical BOM setup.

DESCRIPTION:
FS mount failed during Cluster configuration on 24-node physical BOM setup due to vxvm transactions were taking time more that vcs timeouts.

RESOLUTION:
Fix is added to reduce unnecessary transaction time on large node setup.

* 4080041 (Tracking ID: 4056953)

SYMPTOM:
3PAR PE LUNs are reported in error state by 3PAR ASL

DESCRIPTION:
3PAR storage presents some special STORAGE LUNs(3PAR PE) and these need to be SKIPPED by VxVM and not claimed.
This causes an issue for VxDMP to handle as multiple PE LUNs from different 3PAR enclosures.

RESOLUTION:
Fix added to SKIP the 3PAR PE luns by 3PAR ASL to avoid disks being reported in error state.

* 4080105 (Tracking ID: 4045837)

SYMPTOM:
DCL volume subdisks doesnot relocate after node fault timeout and remains in RELOCATE state

DESCRIPTION:
If DCO has failed plexs and dco is on different disks than data, dco relocation need to be triggered explicitly as try_fss_reloc will only perform dco relocation in context of data which may not succeed if sufficient data disks not available (additional host/disks may be available where dco can relocate)

RESOLUTION:
Fix is added to relocate DCL subdisks to available spare disks

* 4080122 (Tracking ID: 4044068)

SYMPTOM:
Replace Node is failing at Configuring NetBackup stage due to vxdisk init failed with error "Could not obtain requested lock".

DESCRIPTION:
Replace Node is failing at Configuring NetBackup stage due to vxdisk init failed with error "Could not obtain requested lock".

RESOLUTION:
Fix is added to retry transaction few times if it fails with this error

* 4080269 (Tracking ID: 4044898)

SYMPTOM:
we were unable to see rlink tags from info records with the vxrlink listtag command.

DESCRIPTION:
Making rlinks FIPS compliant has 2nd phase in which we are dealing with disk group upgrade path, where rlink enc tags needs to be copied to info record and needs to be FIPS compliant one.



here vxdg upgrade will internally call vxrlink and vxencrypt to upgrade the rlink and rekey the rlink keys respectively.

RESOLUTION:
copied all the encryption tags for rlink to info record and when we are upgrading DG we will internally upgrade the rlink,
this upgradation process will copy rlink tags to info records.

* 4080276 (Tracking ID: 4065145)

SYMPTOM:
During addsec we were unable to processencrypted volume tags for multiple volumes and vsets.
Error we saw:

$ vradmin -g dg2 -encrypted addsec dg2_rvg1 10.210.182.74 10.210.182.75

Error: Duplicate tag name vxvm.attr.enckeytype provided in input.

DESCRIPTION:
The number of tags was not defined and we were processing all the tags at a time instead of processing max number of tags for a volume.

RESOLUTION:
Introduced a number of tags variable depend on the cipher method (CBC/GCM), as well fixed minor code issues.

* 4080277 (Tracking ID: 3966157)

SYMPTOM:
the feature of SRL batching was broken and we were not able to enable it as it might caused problems.

DESCRIPTION:
Batching of updates needs to be done as to get benefit of batching multiple updates and getting performance increased

RESOLUTION:
we have decided to simplify the working as we are now aligning each of the small update within a total batch to 4K size so that,

by default we will get the whole batch aligned one, and then there is no need of book keeping for last update and hence reducing the overhead of

different calculations.

we are padding individual updates to reduce overhead of book keeping things around last update in a batch,
by padding each updates to 4k, we will be having a batch of updates which is 4k aligned itself.

* 4080579 (Tracking ID: 4077876)

SYMPTOM:
When one cluster node is rebooted, EC log replay is triggered for shared EC volume.
It is seen that system is crashed during this EC log replay.

DESCRIPTION:
It is seen that two flags are assigned same value. So, system panicked during flag check.

RESOLUTION:
Changed the code flow to avoid checking values of flags having same value.

* 4080845 (Tracking ID: 4058166)

SYMPTOM:
While setting up VVR/CVR on large size data volumes (size > 3TB) with filesystems mounted on them, initial autosync operation takes a lot of time to complete.

DESCRIPTION:
While performing autosync on VVR/CVR setup for a volume with filesystem mounted, if smartmove feature is enabled, the operation does smartsync by syncing only the regions dirtied by filesystem, instead of syncing entire volume, which completes faster than normal case. However, for large size volumes (size > 3TB),

smartmove feature does not get enabled, even with filesystem mounted on them and hence autosync operation syncs entire volume.

This behaviour is due to smaller size DCM plexes allocated for such large size volumes, autosync ends up performing complete volume sync,taking lot more time to complete.

RESOLUTION:
Increase the limit of DCM plex size (loglen) beyond 2MB so that smart move feature can be utilised properly.

* 4080846 (Tracking ID: 4058437)

SYMPTOM:
Replication between 8.0 and 7.4.x fails with an error due to sector size field.

DESCRIPTION:
7.4.x branch has sectorsize set to zero which internally is indicated as 512 byte. It caused the startrep, resumerep to fail with the below error message.

Message from Primary:

VxVM VVR vxrlink ERROR V-5-1-20387  sector size mismatch, Primary is having sector size 512, Secondary is having sector size 0

RESOLUTION:
A check added to support replication between 8.0 and 7.4.x

* 4081790 (Tracking ID: 4080373)

SYMPTOM:
SFCFSHA configuration failed on RHEL 8.4 due to 'chmod -R' error.

DESCRIPTION:
Failure messages are getting logged as all log permissions are changed to 600 during the upgrade and all log files moved to '/var/log/vx'.

RESOLUTION:
Added -f option to chmod command to suppress warning and redirect errors from mv command to /dev/null.

* 4083337 (Tracking ID: 4081890)

SYMPTOM:
On RHEL8 NBFS/Access commands like python3, sort, sudo, ssh, etc are generating core dump during execution of the command mkfs.vxfs & mkfs.ext4 in parallel.

DESCRIPTION:
On RHEL8 NBFS/Access commands like python3, sort, sudo, ssh, etc are generating core dump during execution of the command mkfs.vxfs & mkfs.ext4 in parallel. This was happening due to missing fpu armor protection for FPU instruction set.

RESOLUTION:
Fix is added to use FPU protection while using FPU instruction set

* 4085619 (Tracking ID: 4086718)

SYMPTOM:
VxVM fails to install because vxdmp module fails to load on latest minor kernel of SLES15SP2.

DESCRIPTION:
VxVM modules fail to load on latest minor kernel of SLES15SP2. Following messages can be seen logged in system logs:
vxvm-boot[32069]: ERROR: No appropriate modules found.
vxvm-boot[32069]: Error in loading module "vxdmp". See documentation.
vxvm-boot[32069]: Modules not Loaded

RESOLUTION:
Code changes have been done to fix this issue.

* 4087233 (Tracking ID: 4086856)

SYMPTOM:
For Appliance FLEX product using VRTSdocker-plugin, docker.service needs to be replaced as it is not supported on RHEL8.

DESCRIPTION:
Appliance FLEX product using VRTSdocker-plugin is switching to RHEL8 on which docker.service does not exist. vxinfoscale-docker.service must stop after all container services are stopped. podman.service shuts down after all container services are stopped, so docker.service can be replaced with podman.service.

RESOLUTION:
Added platform-specific dependencies for VRTSdocker-plugin. For RHEL8 podman.service introduced.

* 4087439 (Tracking ID: 4088934)

SYMPTOM:
"dd" command on a simple volume results in kernel panic.

DESCRIPTION:
Kernel panic is observed with following stack trace:
 #0 [ffffb741c062b978] machine_kexec at ffffffffa806fe01
 #1 [ffffb741c062b9d0] __crash_kexec at ffffffffa815959d
 #2 [ffffb741c062ba98] crash_kexec at ffffffffa815a45d
 #3 [ffffb741c062bab0] oops_end at ffffffffa8036d3f
 #4 [ffffb741c062bad0] general_protection at ffffffffa8a012c2
    [exception RIP: __blk_rq_map_sg+813]
    RIP: ffffffffa84419dd  RSP: ffffb741c062bb88  RFLAGS: 00010202
    RAX: 0c2822c2621b1294  RBX: 0000000000010000  RCX: 0000000000000000
    RDX: ffffb741c062bc40  RSI: 0000000000000000  RDI: ffff8998fc947300
    RBP: fffff92f0cbe6f80   R8: ffff8998fcbb1200   R9: fffff92f0cbe0000
    R10: ffff8999bf4c9818  R11: 000000000011e000  R12: 000000000011e000
    R13: fffff92f0cbe0000  R14: 00000000000a0000  R15: 0000000000042000
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 #5 [ffffb741c062bc38] scsi_init_io at ffffffffc03107a2 [scsi_mod]
 #6 [ffffb741c062bc78] sd_init_command at ffffffffc056c425 [sd_mod]
 #7 [ffffb741c062bcd8] scsi_queue_rq at ffffffffc0311f6e [scsi_mod]
 #8 [ffffb741c062bd20] blk_mq_dispatch_rq_list at ffffffffa8447cfe
 #9 [ffffb741c062bdc0] __blk_mq_do_dispatch_sched at ffffffffa844cae0
#10 [ffffb741c062be28] __blk_mq_sched_dispatch_requests at ffffffffa844d152
#11 [ffffb741c062be68] blk_mq_sched_dispatch_requests at ffffffffa844d290
#12 [ffffb741c062be78] __blk_mq_run_hw_queue at ffffffffa84466a3
#13 [ffffb741c062be98] process_one_work at ffffffffa80bcd74
#14 [ffffb741c062bed8] worker_thread at ffffffffa80bcf8d
#15 [ffffb741c062bf10] kthread at ffffffffa80c30ad
#16 [ffffb741c062bf50] ret_from_fork at ffffffffa8a001ff

RESOLUTION:
Code changes have been done to fix this issue.

* 4087791 (Tracking ID: 4087770)

SYMPTOM:
0

DESCRIPTION:
DCO (data change object) tracks delta changes for faulted mirrors. During complete storage loss of DCO volume mirrors in, DCO object will be marked as BADLOG and becomes unusable for bitmap tracking.
Post storage reconnect (such as node rejoin in FSS environments) DCO will be re-paired for subsequent tracking. During this if VxVM finds any of the mirrors detached for data volumes, those are expected to be marked for full-resync as bitmap in DCO has no valid information. Bug in repair DCO operation logic prevented marking mirror for full-resync in cases where repair DCO operation is triggered before data volume is started. This resulted into mirror getting attached without any data being copied from good mirrors and hence reads serviced from such mirrors have stale data, resulting into file-system corruption and data loss.

RESOLUTION:
Code has been added to ensure repair DCO operation is performed only if volume object is enabled so as to ensure detached mirrors are marked for full-resync appropriately.

* 4088076 (Tracking ID: 4054685)

SYMPTOM:
RVG recovery gets hung in case of reconfiguration scenarios in CVR environments leading to vx commands hung on master node.

DESCRIPTION:
As a part of rvg recovery we perform DCM, datavolume recovery. But datavolume recovery takes long time due to wrong IOD handling done in linux platforms.

RESOLUTION:
Fix the IOD handling mechanism to resolve the rvg recovery handling.

* 4088483 (Tracking ID: 4088484)

SYMPTOM:
DMP_APM module is not getting loaded and throwing following message in the dmesg logs:
Mod load failed for dmpnvme module: dependency conflict
VxVM vxdmp V-5-0-1015 DMP_APM: DEPENDENCY CONFLICT

DESCRIPTION:
NVMe module loading failed as dmpaa module dependency added in APM and system doesn't have any A/A type disk which inturn nvme module load failed.

RESOLUTION:
Removed A/A dependency from NVMe APM.

* 4088762 (Tracking ID: 4087099)

SYMPTOM:
DG is not imported after upgrade to InfoScale 8.0u1 on RHEL8.6 and NVME disks are in an error state.

DESCRIPTION:
NVME disks minor number was getting changed when scandisks was performed.
This was leading to incorrect major / minor information being present in vold of the core database.

RESOLUTION:
Fixed device open by passing O_RDONLY. With write permissions it was changing minor number.

Patch ID: VRTSaslapm 8.0.0.1800

* 4080041 (Tracking ID: 4056953)

SYMPTOM:
3PAR PE LUNs are reported in error state by 3PAR ASL

DESCRIPTION:
3PAR storage presents some special STORAGE LUNs(3PAR PE) and these need to be SKIPPED by VxVM and not claimed.
This causes an issue for VxDMP to handle as multiple PE LUNs from different 3PAR enclosures.

RESOLUTION:
Fix added to SKIP the 3PAR PE luns by 3PAR ASL to avoid disks being reported in error state.

* 4088762 (Tracking ID: 4087099)

SYMPTOM:
DG is not imported after upgrade to InfoScale 8.0u1 on RHEL8.6 and NVME disks are in an error state.

DESCRIPTION:
NVME disks minor number was getting changed when scandisks was performed.
This was leading to incorrect major / minor information being present in vold of the core database.

RESOLUTION:
Fixed device open by passing O_RDONLY. With write permissions it was changing minor number.

* 4066952 (Tracking ID: 3951527)

SYMPTOM:
Data loss issue is seen because of incorrect version check handling done as a part of SRL 4k update alignment changes in 7.4 release.

DESCRIPTION:
On primary, rv_target_rlink field always is set to NULL which internally skips checking the 4k version  in VOL_RU_INIT_UPDATE macro. It causes SRL writes to be
written in a 4k aligned manner even though remote rvg version is less than or equal to 7.3.1. This resulted in data loss.

RESOLUTION:
Changes are done to use rv_replicas rather than rv_target_rlink to check the version appropriately for all sites and not write SRL IO's in 4k aligned manner.
Also, RVG version is not upgraded as part of diskgroup upgrades if rlinks are in attached state. RVG version can be upgraded using “vxrvg upgrade” command after
detaching the rlinks and also when all sites are upgraded.

Patch ID: VRTSvxvm-8.0.0.1700

* 4083792 (Tracking ID: 4082799)

SYMPTOM:
A security vulnerability exists in the third-party component libcurl.

DESCRIPTION:
VxVM uses a third-party component named libcurl in which a security vulnerability exists.

RESOLUTION:
VxVM is updated to use a newer version of libcurl in which the security vulnerability has been addressed.

Patch ID: VRTSvxvm-8.0.0.1600

* 4057420 (Tracking ID: 4060462)

SYMPTOM:
System is unresponsive while adding new nodes.

DESCRIPTION:
After a node is removed, and adding node with  different node name is attempted; system turns
unresponsive. When a node leaves a cluster, in-memory information related to the node is not cleared due to the race condition.

RESOLUTION:
Fixed race condition to clear in-memory information of the node that leaves the cluster.

* 4062799 (Tracking ID: 4064208)

SYMPTOM:
Node is unresponsive while it gets added to the cluster.

DESCRIPTION:
While a node joins the cluster, if bits on the node are upgraded; size
of the object is interpreted incorrectly. Issue is observed when number of objects is higher and on
InfoScale 7.3.1 and above.

RESOLUTION:
Correct sizes are calculated for the data received from the master node.

* 4065841 (Tracking ID: 4065495)

SYMPTOM:
This is new array and we need to add support for EMC PowerStore.

DESCRIPTION:
EMC PowerStore 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 EMC PowerStore have been done.

* 4066213 (Tracking ID: 4052580)

SYMPTOM:
Multipathing not supported for NVMe devices under VxVM.

DESCRIPTION:
NVMe devices being non-SCSI devices, are not considered for multipathing.

RESOLUTION:
Changes introduced to support multipathing for NVMe devices.

* 4068407 (Tracking ID: 4068404)

SYMPTOM:
We need to add support to claim ALUA Disks on HPE 3PAR/Primera/Alletra 9000 arrays.

DESCRIPTION:
Current ASL doesn't support HPE 3PAR/Primera/Alletra 9000 ALUA array type. This ALUA array support has been now added in the current ASL.

RESOLUTION:
Code changes to support HPE 3PAR/Primera/Alletra 9000 ALUA array have been done.

Patch ID: VRTSvxvm-8.0.0.1200

* 4057420 (Tracking ID: 4060462)

SYMPTOM:
Node join hang

DESCRIPTION:
After a node is removed if add node is performed with  different nodename 
than earlier removed node name, hang  is seen while joining node. When node leaves cluster
in-memory information related to node is not cleared in one of the place due to race condition

RESOLUTION:
Fixed race condition to clear in-memory information when node leaves cluster.

* 4062799 (Tracking ID: 4064208)

SYMPTOM:
Node join hang

DESCRIPTION:
After bits on node are upgraded when it tried to join cluster, it interprets size
of object incorrectly. Issue is seen in case of higher number of objects. It is applicable from
IS 7.3.1 and onwards

RESOLUTION:
Correct sizes are calculated for the data received from master node

* 4065628 (Tracking ID: 4065627)

SYMPTOM:
VxVM modules are not loaded after OS upgrade followed by a reboot .

DESCRIPTION:
Once the stack installation is completed with configuration , after OS upgrade vxvm directory is not formed under /lib/modules/<upgraded_kernel>veritas/ .

RESOLUTION:
VxVM code is updated with the required changes .

* 4066259 (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.

* 4066735 (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

* 4066834 (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.

Patch ID: VRTSvxfs-8.0.0.1800

* 4068960 (Tracking ID: 4073203)

SYMPTOM:
Veritas file replication might generate a core while replicating the files to target when rename and unlink operation is performed on a file with FCL( file change log) mode on.

DESCRIPTION:
vxfsreplicate process of Veritas file replicator  might get a segmentation fault with File change mode on when rename and unlink operation are performed on a file.

RESOLUTION:
Addressed the issue to replicate the files, in scenarios involving rename and unlink operation with FCL mode on.

* 4071108 (Tracking ID: 3988752)

SYMPTOM:
Use ldi_strategy() routine instead of bdev_strategy() for IO's in solaris.

DESCRIPTION:
bdev_strategy() is deprecated from solaris code and was causing performance issues when used for IO's. Solaris has recommended to use LDI framework for all IO's.

RESOLUTION:
Code is modified to use ldi framework for all IO's in solaris.

* 4072228 (Tracking ID: 4037035)

SYMPTOM:
VxFS should have the ability to control the number of inactive processing threads.

DESCRIPTION:
VxFS may spawn a large number of worker threads that become inactive over time. As a result, heavy lock contention occurs during the removal of inactive threads on high-end servers.

RESOLUTION:
To avoid the contention, a new tunable, vx_ninact_proc_threads, is added. You can use vx_ninact_proc_threads to adjust the number of inactive processing threads based on your server configuration and workload.

* 4078335 (Tracking ID: 4076412)

SYMPTOM:
Addressing Executive Order (EO) 14028,  initial requirements intended to improve the Federal Governments investigative and remediation capabilities related to cybersecurity incidents. Executive Order helps in improving the nation's cybersecurity and also enhances any organization's cybersecurity and software supply chain integrity.

DESCRIPTION:
Executive Order helps in improving the nation's cybersecurity and also enhances any organization's cybersecurity and software supply chain integrity, some of the  initial requirements will enable the logging which is compliant to Executive Order. This comprises command logging,  logging unauthorised access in filesystem and logging WORM events on filesystem. Also include changes to display IP address for Veritas File replication at control plane based on tunable.

RESOLUTION:
The initial requirements of EO are addressed in this release.


As per Executive order(EO) for some of the requirements it should be Tunable based.
For example IP logging where ever applicable (for VFR it should be at control plane(not for every data transfer), and this is also tunable based.
Also for logging some kernel logs, like worm events(plan is to log those to syslog) etc are tunable based.

Introduced new tunable, eo_logging_enable. There is a protocol change because of the introduction of the tunable. 
Though the changes are planned for TOT first and then will go to Update patch on 80all maint for EO release, there is impact of this protocol change for update patch.
We might need to update protocol change with middle protocol version between existing protocol version and new protocol version(introduced because of eo)

For VFR, IP addresses of source and destination are needed to be logged as part of EO.
IP addresses will be included in the log while logging Starting/Resuming a job in VFR.
Log Location: /var/VRTSvxfs/replication/log/mount_point-job_name.log

There are 2 ways to fetch the IP address of the source and target. One is to get the IP addresses stored in the link structure of a session. These IPs are obtained by resolving the source and target hostname. It may contain both IPv4 and IPv6 for a node, and we cannot speculate on which IP actual connection has happened. The second way is to get the socket descriptor from an active connection of the session. This socket descriptor can be used to fetch the source and target IP associated with it. The second method is seems  to get the actual IP addresses used for the connection between source and target. The change contains to  fetch IP addresses from socket descriptor after establishing connections.

More details on EO Logging with respective handling for initial release for VxFS
https://confluence.community.veritas.com/pages/viewpage.action?spaceKey=VES&title=EO+VxFS+Scrum+Page

* 4078520 (Tracking ID: 4058444)

SYMPTOM:
Loop mounts using files on VxFS fail on Linux systems running kernel version 4.1 or higher.

DESCRIPTION:
Starting with the 4.1 version of the Linux kernel, the driver loop.ko uses a new API for read and write requests to the file which was not previously implemented in VxFS. This causes the virtual disk reads during mount to fail while using the -o loop option , causing the mount to fail as well. The same functionality worked in older kernels (such as the version found in RHEL7).

RESOLUTION:
Implemented a new API for all regular files on VxFS, allowing usage of the loop device driver against files on VxFS as well as any other kernel drivers using the same functionality.

* 4079142 (Tracking ID: 4077766)

SYMPTOM:
VxFS kernel module might leak memory during readahead of directory blocks.

DESCRIPTION:
VxFS kernel module might leak memory during readahead of directory blocks due to missing free operation of readahead-related structures.

RESOLUTION:
Code in readahead of directory blocks is modified to free up readahead-related structures.

* 4079173 (Tracking ID: 4070217)

SYMPTOM:
Command fsck might fail with 'cluster reservation failed for volume' message for a disabled cluster-mounted filesystem.

DESCRIPTION:
On a disabled cluster-mounted filesystem, release of cluster reservation might fail during unmount operation resulting in a  failure of command fsck with 'cluster reservation failed for volume' message.

RESOLUTION:
Code is modified to release cluster reservation in unmount operation properly even for cluster-mounted filesystem.

* 4082260 (Tracking ID: 4070814)

SYMPTOM:
Security Vulnerability observed in Zlib a third party component VxFS uses.

DESCRIPTION:
In an internal security scans vulnerabilities in Zlib were found.

RESOLUTION:
Upgrading the third party component Zlib to address these vulnerabilities.

* 4082865 (Tracking ID: 4079622)

SYMPTOM:
Migration uses normal read/write file operation instead of read/write iter functions. vxfs requires read/write iter functions from Linux kernel
5.14.

DESCRIPTION:
Starting with 5.14 version of the Linux kernel, vxfs uses a read/write iter file operation for migration.

RESOLUTION:
Developed a common function for read/write which get called for normal and iter read/write file operation.

* 4083335 (Tracking ID: 4076098)

SYMPTOM:
FS migration from ext4 to vxfs on Linux machines with falcon-sensor enabled, might fail.

DESCRIPTION:
Falcon-sensor driver installed on test machines is tapping system calls such as close and is doing some 
additional vfs calls such as read. Due to this vxfs driver received read file - operation call from fsmigbgcp 
process context. Read operation is allowed only on special files from fsmigbgcp process context. As
the file in picture was not a special file, the vxfs debug code asserted.

RESOLUTION:
Read on non-special files from fsmigbgcp process context is allowed.


]

* 4085623 (Tracking ID: 4085624)

SYMPTOM:
While running fsck with -o and full -y on corrupted FS, fsck may dump core.

DESCRIPTION:
Fsck builds various in-core maps based on on-disk structural files, one such map is dotdotmap (which stores 
info about parent directory). For regular fset (like 999), the dotdotmap is initialized only for primary ilist
(inode list for regular inodes). It is skipped for attribute ilist (inode list for attribute inodes). This is because
attribute inodes do not have parent directories as is the case for regular inodes.

While attempting to resolve inconsistencies in FS metadata, fsck tries to clean up dotdotmap for attribute ilist. 
In the absence of a check, dotdotmap is re-initialized for attribute ilist causing segmentation fault.

RESOLUTION:
In the codepath where fsck attempts to reinitialize the dotdotmap, a check added to skip reinitialization of dotdotmap
for attribute ilist.

* 4085839 (Tracking ID: 4085838)

SYMPTOM:
Command fsck may generate core due to processing of zero size attribute inode.

DESCRIPTION:
Command fsck is modified to skip processing of zero size attribute inode.

RESOLUTION:
Command fsck fails due to allocation of memory and dereferencing it for zero size attribute inode.

* 4086085 (Tracking ID: 4086084)

SYMPTOM:
VxFS mount operation causes system panic when -o context is used.

DESCRIPTION:
VxFS mount operation supports context option to override existing extended attributes, or to specify a different, default context for file systems that do not support extended attributes. System panic observed when -o context is used.

RESOLUTION:
Required code changes are added to avoid panic.

* 4088341 (Tracking ID: 4065575)

SYMPTOM:
Write operation might be unresponsive on a local mounted VxFS filesystem in a no-space condition

DESCRIPTION:
Write operation might be unresponsive on a local mounted VxFS filesystem in a no-space condition due to a race between two writer threads to take read-write lock the file to do a delayed allocation operation on it.

RESOLUTION:
Code is modified to allow thread which is already holding read-write lock to complete delayed allocation operation, other thread will skip over that file.

Patch ID: VRTSvxfs-8.0.0.1700

* 4081150 (Tracking ID: 4079869)

SYMPTOM:
Security Vulnerability found in VxFS while running security scans.

DESCRIPTION:
In our internal security scans we found some Vulnerabilities in VxFS third party components. The Attackers can exploit these security vulnerability 
to attack on system.

RESOLUTION:
Upgrading the third party components to resolve these vulnerabilities.

* 4083948 (Tracking ID: 4070814)

SYMPTOM:
Security Vulnerability found in VxFS while running security scans.

DESCRIPTION:
In our internal security scans we found some Vulnerabilities in VxFS third party component Zlib.

RESOLUTION:
Upgrading the third party component Zlib to resolve these vulnerabilities.

Patch ID: VRTSvxfs-8.0.0.1200

* 4055808 (Tracking ID: 4062971)

SYMPTOM:
All the operations like ls, create are blocked on file system

DESCRIPTION:
In WORM file system we do not allow directory rename. When partition directory is enabled, new directories are created and files are moved under this leaf directory based on hash. Due to WORM FS this rename operation was blocked and splitting could not complete. Blocking all the operations on file system.

RESOLUTION:
Allow directory renaming in the context of partition directory split and merge.

* 4056684 (Tracking ID: 4056682)

SYMPTOM:
New features information on a filesystem with fsadm(file system administration utility) from a device is not displayed.

DESCRIPTION:
Information about new features like WORM (Write once read many), auditlog is correctly updated with a file system mounted through the fsadm utility, but on the underlying device the new feature information is not displayed.

RESOLUTION:
Updated fsadm utility to display the new feature information correctly.

* 4062606 (Tracking ID: 4062605)

SYMPTOM:
Minimum retention time cannot be set if the maximum retention time is not set.

DESCRIPTION:
The tunable - minimum retention time cannot be set if the tunable - maximum retention time is not set. This was implemented to ensure 
that the minimum time is lower than the maximum time.

RESOLUTION:
Setting of minimum and maximum retention time is independent of each other. Minimum retention time can be set without the maximum retention time being set.

* 4065565 (Tracking ID: 4065669)

SYMPTOM:
Creating non-WORM checkpoints fails when the tunables - minimum retention time and maximum retention time are set.

DESCRIPTION:
Creation of non-WORM checkpoints fails as all WORM-related validations are extended to non-WORM checkpoints also.

RESOLUTION:
WORM-related validations restricted to WORM fsets only, allowing non-WORM checkpoints to be created.

* 4065651 (Tracking ID: 4065666)

SYMPTOM:
All the operations like ls, create are blocked on file system directory where there are WORM enabled files and retention period not expired

DESCRIPTION:
For WORM file system, files whose retention period is not expired can not be renamed. When partition directory is enabled, new directories are created and files are moved under this leaf directory based on hash. Due to WORM FS this rename operation was blocked and splitting could not complete. Blocking all the operations on file system.

RESOLUTION:
Allow directory renaming of files even if retention period is not expired in the context of partition directory split and merge.

Patch ID: VRTSvxfs-8.0.0.1100

* 4061114 (Tracking ID: 4052883)

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

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

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

Patch ID: VRTSvxfen-8.0.0.1800

* 4087166 (Tracking ID: 4087134)

SYMPTOM:
The error message 'Touch /var/VRTSvcs/log/vxfen/vxfen.log failed' appears after starting vxfen service, if parent directory path of vxfen.log is not present.

DESCRIPTION:
Typically,  if parent directory path of vxfen.log is not present, the following error message appears after starting vxfen service:
'Touch /var/VRTSvcs/log/vxfen/vxfen.log failed'.

RESOLUTION:
Create the parent directory path for the vxfen.log file globally if the path is not present.

* 4088061 (Tracking ID: 4089052)

SYMPTOM:
On RHEL9, Node panics while running vxfenswap as a part of Online Coordination Point Replacement operation.

DESCRIPTION:
RHEL9 has introduced fortifying panic which gets triggered if kernel's static check finds out any buffer overflow. This check was wrongly identifying buffer overflow where strings are copied by using unions.

RESOLUTION:
Moved to bcopy internally for such a scenario and kernel side check skipped.

Patch ID: VRTSveki-8.0.0.1800

* 4056647 (Tracking ID: 4055072)

SYMPTOM:
Upgrading VRTSveki package using yum reports following error as "Starting veki /etc/vx/veki: line 51: [: too many arguments"

DESCRIPTION:
While upgrading VRTSveki package, presence of multiple module directories might result in upgrade script printing error message.

RESOLUTION:
Code is modified to check for specific module directory related to current kernel version in VRTSveki upgrade script.

Patch ID: VRTSveki-8.0.0.1200

* 4070027 (Tracking ID: 4066550)

SYMPTOM:
After reboot LLT, GAB service fail to start as Veki service start times out.

DESCRIPTION:
After reboot, when systemd tries to bring multiple services in parallel at the same time of Veki, Veki startup times out. The default Veki startup timeout was 90 seconds, which is getting increased to 300 seconds with this patch

RESOLUTION:
Increasing Veki start timeout

Patch ID: VRTSvcsag-8.0.0.1800

* 4030767 (Tracking ID: 4088595)

SYMPTOM:
hapdbmigrate utility fails to online the oracle service group due to a timing issue.

DESCRIPTION:
hapdbmigrate utility fails to online the oracle service group due to a timing issue.
example:
./hapdbmigrate -pdbres pdb1_res -cdbres cdb2_res -XMLdirectory /oracle_xml
Cluster prechecks and validation                                 Done
Taking PDB resource [pdb1_res] offline                           Done
Modification of cluster configuration                            Done
VCS ERROR V-16-41-39 Group [CDB2_grp] is not ONLINE after 300 seconds on %vcs_node%

VCS ERROR V-16-41-41 Group [CDB2_grp] is not ONLINE on some nodes in the cluster

Bringing PDB resource [pdb1_res] online on CDB resource [cdb2_res]Done

For further details, see '/var/VRTSvcs/log/hapdbmigrate.log'

RESOLUTION:
hapdbmigrate utility modified to ensure enough time elapses between probe of PDB resource and online of CDB group.

* 4058802 (Tracking ID: 4073842)

SYMPTOM:
Oracle 21c is not supported on earlier product versions.

DESCRIPTION:
Implemented Oracle 21c support with Storage Foundation for Databases.

RESOLUTION:
Changes are done to support Oracle 21c with Storage Foundation for Databases.

* 4079372 (Tracking ID: 4073842)

SYMPTOM:
Oracle 21c is not supported on earlier product versions.

DESCRIPTION:
Implemented Oracle 21c support with Storage Foundation for Databases.

RESOLUTION:
Changes are done to support Oracle 21c with Storage Foundation for Databases.

* 4079559 (Tracking ID: 4064917)

SYMPTOM:
Oracle agent fails to generate ora_api (which is used for Intentional Offline functionality of Oracle agent) using build_oraapi.sh script for Oracle 21c.

DESCRIPTION:
The build_oraapi.sh script could not connect to library named libdbtools21.a, as on the new Oracle 21c environment generic library is present i.e. '$ORACLE_HOME/rdbms/lib/libdbtools.a'.

RESOLUTION:
This script on Oracle 21c database environment will pick generic library and on older database environments it will pick Database version specific library.

* 4081774 (Tracking ID: 4083099)

SYMPTOM:
When OverlayIP is configured AzureIP resource offline operation fails.

DESCRIPTION:
AzureIP resource fails to go offline when OverlayIP is configured because Azure API routes.delete part of azure-mgmt-network module has been deprecated.

RESOLUTION:
A new API routes.begin_delete is introduced as suggested by Azure in the Azure agent.

Patch ID: VRTSvcs-8.0.0.1800

* 4084675 (Tracking ID: 4089059)

SYMPTOM:
File permission for gcoconfig.log is not 0600.

DESCRIPTION:
As default file permission was 0644 so it was allowing read access to groups and others so file permission needs to be updated.

RESOLUTION:
Added solution which creates file with permission 0600 so that it should be readable and writable by user.

Patch ID: VRTSvcs-8.0.0.1400

* 4065820 (Tracking ID: 4065819)

SYMPTOM:
Protocol version upgrade from Access Appliance 7.4.3.200 to 8.0 failed.

DESCRIPTION:
During rolling upgrade, IPM message 'MSG_CLUSTER_VERSION_UPDATE' is generated and as a part of it we do  some validations for bumping up protocol. If validation succeeds then a broadcast message to bump up the cluster protocol is sent and immediately we send success message to haclus. Thus, the success message is sent before processing the actual updating Protocol version broadcast message. This process occurs for very short period. Also, after successful processing of the broadcast message, the Protocol version is properly updated in config files as well as command shows correct value.

RESOLUTION:
Instead of immediately returning success message, haclus CLI waits till upgrade is implemented on broadcast channel and then success message is sent.

Patch ID: VRTSspt-8.0.0.1200

* 4046148 (Tracking ID: 4076850)

SYMPTOM:
Memory related stat collection is not done in linux.

DESCRIPTION:
Specific stat collections like top, ps, free, df, pmap, smap are required on Linux for initial triaging of some of the issues.

RESOLUTION:
Introduced a script named "Collect_memstats_linux.sh" inside VRTSspt package for memory related stat collection.

* 4056649 (Tracking ID: 4056648)

SYMPTOM:
Metasave collection can be executed on a mounted filesystem.

DESCRIPTION:
If metasave image is collected from a mounted filesystem then it might be an inconsistent state of the filesystem as there could be ongoing changes happening on the filesystem.

RESOLUTION:
Code changes have been done to fail default metasave collection for a mounted filesystem. If metasave needs to be collected from mounted filesystem then this can still be achieved with option "-o inconsistent".

* 4075110 (Tracking ID: 4018783)

SYMPTOM:
Metasave collection and restore takes significant amount of time.

DESCRIPTION:
Metasave collection and restore takes significant amount of time.

RESOLUTION:
Code changes have been done in metasave code base to improve metasave collection and metasave restore in the range of 30-40%.

* 4076729 (Tracking ID: 4076837)

SYMPTOM:
Need to collect vxtunefs output for all VxFS filesystems during FirstLook collection.

DESCRIPTION:
During Firstlook log collection, vxtunefs output does not get captured. If any vxfs tunable value has been changed before running FirstLook log collection then it requires to be collected separately that is an overhead.

RESOLUTION:
Code changes have been done to collect vxtunefs output of all VxFS filesystems during FirstLook log collection itself.

* 4079133 (Tracking ID: 4086188)

SYMPTOM:
FirstLook stat collection time interval improvement

DESCRIPTION:
Some stats like vxfsstat, vxstat etc run for 5 seconds every minute during FirstLook stat collection. Analysis of the logs collected in this pattern needs more 
effort and can not be very effective in graphical representation.

RESOLUTION:
Code changes have been done to group all the commands that need to be executed for the complete duration of FirstLook execution as Phase 0 commands. Phase 0 
commands are executed at the start of the FirstLook.

* 4085652 (Tracking ID: 4086301)

SYMPTOM:
vxfsstat is collected for only one filesystem through FirstLook

DESCRIPTION:
With current design of FirstLook, vxfsstat is collected for the first vxfs mounted filesystem in the mount command list. There is a method to specify a specific 
filesystem name using "-m" option in start_look but there is no way to provide a subset of filesystem names to "-m" option if the requirement is to collect 
vxfsstat output for multiple filesystems.

RESOLUTION:
Code changes have been done where "-m" now accepts a list of comma separated filesystems.

* 4086194 (Tracking ID: 4086272)

SYMPTOM:
Addition of metasave and vxbench command files for RHEL9 to VRTSSPT

DESCRIPTION:
Command files for metasave and vxbench for RHEL9 need to be added to VRTSSPT package.

RESOLUTION:
Command files for metasave and vxbench for RHEL9 are added to VRTSSPT package.

Patch ID: VRTSsfmh-vom-HF0800200

* 4086839 (Tracking ID: 4086838)

SYMPTOM:
at_migration.pl script may throw error if there are VIOM Agents running version 8.0 or higher.

DESCRIPTION:
Migration of old 1024 certificates to 2048 using at_migration.pl may not work if some of the VIOM Agents have version 8.0 or higher.
Note that at_migration.pl is only required to run when your VIOM Management Server is using 1024 bit certificates and you wish to move to 2048 bit certificates.
Please do not run the script if your VIOM environment is already using 2048 bit certificates.

RESOLUTION:
Added support for VIOM 8.x.

* 4086843 (Tracking ID: 4086841)

SYMPTOM:
N/A

DESCRIPTION:
Following features are implemented as part of 'US Federal Executive Order EL1 Logging requirements': 

1. Timestamp format has been changed as per EO in every log statement.
2. Added FQDN (Linux)/ hostname(Windows) in every log statement as unique identifier.
3. In web server logs, added minimum logging fields such as Session ID, Source and Destination IPs (IPv4), Status Code, Response Time, Additional http headers etc. in every log statement.
4. Logging of the CLIs executed.
5. Logfile permission is changed to 600.

Post patch installation some manual changes are also needed for Web Server logging in case if your organization is looking for Logging changes as per US Federal Executive Order. Please refer below technote for more details.
https://www.veritas.com/support/en_US/doc/viom_technote_8.0.0.200

RESOLUTION:
N/A

* 4086847 (Tracking ID: 4086846)

SYMPTOM:
N/A

DESCRIPTION:
VIOM Management Servers and VIOM Agents do secure TLS1.2 communication. They use 2048 bit certificates to make the communication secure. These certificates may expire over a period of time and once they are expired, VIOM will stop working.
This new enhancement in VIOM will detect the certificates expiry days and will raise a fault when 120 days are remaining for certificates expiry. Admin can then perform the certificate renew operation from GUI (Settings -> Hosts -> Renew Certificates) to renew the certificates. 

Refer technote for more details.
https://www.veritas.com/support/en_US/doc/viom_technote_8.0.0.200

RESOLUTION:
N/A

* 4086852 (Tracking ID: 4086851)

SYMPTOM:
Third party components vulnerability reported.

DESCRIPTION:
Following third party components have been upgraded-

Components	                Previous Version      Upgraded Version        Vulnerability IDs fixed
                                (VIOM 8.0.0.120)      (VIOM 8.0.0.200)

PostgreSQL Database Server	10.21	              14.1                    CVE-2021-3393, BDSA-2019-4036, BDSA-2020-2096, BDSA-2020-2095, 
                                                                              CVE-2019-9193 (BDSA-2019-0895)

OpenJDK	                        jdk8u332-b08	      11.0.16.8.1             BDSA-2022-0129, BDSA-2022-0133, BDSA-2022-0134, BDSA-2022-1997, BDSA-2022-1995, 
                                                                              BDSA-2022-1993

Apache Xerces2  	        2.9.1	              2.12.1                  BDSA-2009-0005 (CVE-2009-2625), BDSA-2016-1289 (CVE-2013-4002), 
                                                                              CVE-2012-0881 (BDSA-2012-0077)

Apache Thrift	                0.7.0	              0.14.1                  CVE-2015-3254, BDSA-2021-0373, CVE-2019-0205 (BDSA-2019-3340), 
                                                                              CVE-2018-1320 (BDSA-2018-4637), CVE-2016-5397 (BDSA-2017-3861)

Apache Tika	                0.7	              2.4.1                   CVE-2022-33879 (BDSA-2022-1772), CVE-2018-11796 (BDSA-2018-3491), CVE-2018-1338, 
                                                                              CVE-2021-28657 (BDSA-2021-0824), CVE-2022-25169 (BDSA-2022-1352), BDSA-2020-0906,
                                                                              CVE-2022-30126 (BDSA-2022-1353), CVE-2018-11761 (BDSA-2018-3316), CVE-2016-4434,
                                                                              CVE-2018-11796 (BDSA-2018-3491), CVE-2018-1339, BDSA-2022-1517, CVE-2015-3271, 
                                                                              CVE-2018-1335, CVE-2016-6809

Spring Security	                5.5.0	              5.7.1                   CVE-2022-22976 (BDSA-2022-1370), CVE-2021-22119 (BDSA-2021-2310), 
                                                                              CVE-2022-22978 (BDSA-2022-1369)

Apache santurio java 	        2.2.2	              3.0.0                   CVE-2021-40690 (BDSA-2021-2815)

RESOLUTION:
Fixed the affected endpoint.

* 4086855 (Tracking ID: 4086853)

SYMPTOM:
VIOM logs were growing beyond defined limit.

DESCRIPTION:
Management server and Management hosts logs inside VRTSsfmcs and VRTSsfmh folders are growing beyond defined limit.

RESOLUTION:
Fixed log file resource locking issue to rotate logs if size increases beyond defined limit.

* 4086861 (Tracking ID: 4086860)

SYMPTOM:
Faults are not listing under faults tab in VIOM GUI.

DESCRIPTION:
Fault page is not listing any fault under faults tab in VIOM GUI.

RESOLUTION:
Fixed an exception that blocking list of faults under faults tab.

* 4086867 (Tracking ID: 4086866)

SYMPTOM:
Mitigation for CVE-2020-9484 vulnerability.

DESCRIPTION:
CVE-2020-9484 vulnerability is present in Apache Tomcat versions 10.0.0-M1 to 10.0.0-M4, 9.0.0.M1 to 9.0.34, 8.5.0 to 8.5.54 and 7.0.0 to 7.0.103.

RESOLUTION:
Tomcat upgraded to 9.0.64 version which does not have CVE-2020-9484 vulnerability.

* 4086873 (Tracking ID: 4086872)

SYMPTOM:
Enable Flexible Storage Sharing check box is disabled in Create Disk Group operation on cluster.

DESCRIPTION:
FSS option is disabled by default on first page of DG creation and it is listing as enabled on summary( last page) of DG create operation on cluster.

RESOLUTION:
Fixed the data inconsistency in create DG operation. FSS option will be enabled by default in DG create operation on cluster if it is a CVM cluster and disks are exported.

* 4086990 (Tracking ID: 4086989)

SYMPTOM:
N/A

DESCRIPTION:
Two new VVR RVG faults detection support has been added in VIOM. The faults topic ids are
event.alert.vom.vvr.replication.srl.disabled
event.alert.vom.vvr.replication.rlink.detached

VIOM will raise SRL disabled fault when SRL volume in the RVG will be detected as 'DISABLED'. If the Rlink state for the RVG is 'DETACHED' then Rlink detached fault will get generated.

Refer technote for more details.
https://www.veritas.com/support/en_US/doc/viom_technote_8.0.0.200

RESOLUTION:
N/A

Patch ID: VRTSsfmh-vom-HF0800120

* 4080541 (Tracking ID: 4080538)

SYMPTOM:
Spring framework vulnerabilities reported.

DESCRIPTION:
Spring framework upgrade to 5.3.21

RESOLUTION:
Upgraded Spring framework to latest version.

* 4080542 (Tracking ID: 4080540)

SYMPTOM:
Tomcat vulnerabilities reported.

DESCRIPTION:
Tomcat upgraded to 9.0.64

RESOLUTION:
Upgraded tomcat to latest version.

* 4080546 (Tracking ID: 4080545)

SYMPTOM:
google-gson vulnerabilities reported.

DESCRIPTION:
Upgraded google-gson jar to latest available version : 2.9.0

RESOLUTION:
Upgraded google-gson to latest version.

* 4080727 (Tracking ID: 4080726)

SYMPTOM:
N/A

DESCRIPTION:
Enabling Forward Secrecy Ciphers for "xprtld" service running on port 5634 on VIOM Management Servers and Agents.
Now, below TLSv1.2 Ciphers Suits is available for secure communication between VIOM CMS and Agents.
TLSv1.2 ciphers
       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong
       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
       TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
       TLS_RSA_WITH_AES_256_GCM_SHA384 - strong

RESOLUTION:
N/A

Patch ID: VRTSsfmh-vom-HF0800110

* 4076527 (Tracking ID: 4076526)

SYMPTOM:
Tomcat vulnerabilities reported.

DESCRIPTION:
Tomcat upgraded to 9.0.63

RESOLUTION:
Upgraded tomcat to latest version.

* 4076531 (Tracking ID: 4076530)

SYMPTOM:
JAVA vulnerabilities reported.

DESCRIPTION:
JAVA upgrade to 8.332.08.1

RESOLUTION:
Upgraded JAVA to latest version.

* 4076534 (Tracking ID: 4076533)

SYMPTOM:
Spring framework vulnerabilities reported.

DESCRIPTION:
Spring framework upgrade to 5.3.19

RESOLUTION:
Upgraded Spring framework to latest version.

* 4076791 (Tracking ID: 4076790)

SYMPTOM:
jackson-databind vulnerabilities reported.

DESCRIPTION:
jackson-databind to 2.13.2.2

RESOLUTION:
Upgraded jackson-databind to latest version.

* 4076798 (Tracking ID: 4076797)

SYMPTOM:
PostgreSQL JDBC Driver vulnerabilities reported.

DESCRIPTION:
Upgrade PostgreSQL JDBC Driver (pgjdbc) 42.2.19 to latest available version (42.3.4)

RESOLUTION:
Upgraded PostgreSQL JDBC Driver to latest version.

* 4076801 (Tracking ID: 4076800)

SYMPTOM:
PostgreSQL Database Server vulnerabilities reported.

DESCRIPTION:
PostgreSQL Database Server upgraded from version 10.17 to latest available version (10.21)

RESOLUTION:
Upgraded PostgreSQL Database Server to latest version.

Patch ID: VRTSsfmh-vom-HF0800100

* 4067024 (Tracking ID: 4067023)

SYMPTOM:
You may see tha /dev/nul file is getting created on VIOM Linux management server post 7.4.2.500 patch upgrade.

DESCRIPTION:
After applying VIOM patch 7.4.2.500 on Linux VIOM management server, /dev/nul file can be created on the system.

RESOLUTION:
Changed /dev/nul to /dev/null.

* 4067034 (Tracking ID: 4067033)

SYMPTOM:
N/A

DESCRIPTION:
The License Reconciliation is a feature that provides an effortless solution to compare InfoScale license usage data against each entitlement and includes a facility to view the effective license position summary of an organization. Refer below technotes for more details https://www.veritas.com/support/en_US/doc/viom_technote_7.4.2.600 - VIOM version 7.4.2
https://www.veritas.com/support/en_US/doc/viom_technote_8.0.0.100 - VIOM version 8.0

RESOLUTION:
N/A

* 4067041 (Tracking ID: 4067040)

SYMPTOM:
log4j2 vulnerabilities fixes

DESCRIPTION:
This patch upgrade log4j2 version to 2.17.1 on VIOM Management Servers to fix below mentioned vulnerabilities.
CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, CVE-2021-4104, CVE-2021-44832, CVE-2019-17571

This hotfix is mandatory for VIOM Management Servers and Managed Hosts/Agents to fix the log4j2 vulnerabilities. This hotfix upgrades log4j component to version 2.17.1 on VIOM Management Servers and removes log4j jars from Windows Managed Hosts. Removal of log4j jars from Managed Hosts/Agents does not impact any VIOM functionality.

RESOLUTION:
Upgraded log4j2 to 2.17.1

* 4067046 (Tracking ID: 4067045)

SYMPTOM:
Apache Tomcat vulnerability issue CVE-2022-23181 in versions below 9.0.58.

DESCRIPTION:
This patch upgrade Apache Tomcat to version 9.0.58 to fix vulnerability CVE-2022-23181.

RESOLUTION:
Upgraded tomcat to version 9.0.58 in VIOM patch.

* 4067050 (Tracking ID: 4067049)

SYMPTOM:
'Per Core License Information' report does not show correct 'Core to License' value.

DESCRIPTION:
VIOM GUI -> Licensing perspective -> Report -> 'Per Core License Information' displays incorrect number of 'Core to License' w.r.t. InfoScale version.

RESOLUTION:
Fixed DB schema to get correct numbers of Core to License.

* 4067053 (Tracking ID: 4067052)

SYMPTOM:
Unable to get login using the Web API service in VIOM in 8.0

DESCRIPTION:
You may not be able to run '/vom/api/gencert' VIOM web API to generate certificate. This patch fixes the certificate generating issue.
While running /vom/api/gencert using curl command, you need to provide '-G' parameter in command to generate certificate.

e.g.
curl -G -g -k -d user=user -d password=password -d domain=ManagementServer_hostname https://ManagementServer_hostname:14161/vom/api/gencert > /root/cert.txt

RESOLUTION:
Fixed the /vom/api/gencert API and also updated VIOM 8.0 user guide to use '-G' option in /vom/api/gencert curl command.

* 4067056 (Tracking ID: 4067055)

SYMPTOM:
N/A

DESCRIPTION:
Veritas InfoScale Operations Manager supports the discovery of InfoScale hosts in an AWS cloud environment only if the hosts are running on Linux or Windows.
 
VIOM discovers AWS cloud parameters/properties for InfoScale Server hosted in AWS under Server and Availability perspectives along with other host parameters/properties. For more information, refer technote https://www.veritas.com/support/en_US/doc/viom_technote_8.0.0.100.

RESOLUTION:
N/A

* 4067058 (Tracking ID: 4067057)

SYMPTOM:
N/A

DESCRIPTION:
Veritas InfoScale Operations Manager discovers FULLFSCK flag on a VxFS file system every 24 hours. If the file system is corrupted, a fault 'SF_FILESYSTEM_CORRUPTED' is raised. For more information, refer technotes below.
https://www.veritas.com/support/en_US/doc/viom_technote_7.4.2.600 - VIOM version 7.4.2
https://www.veritas.com/support/en_US/doc/viom_technote_8.0.0.100 - VIOM version 8.0

RESOLUTION:
N/A

* 4067130 (Tracking ID: 4067129)

SYMPTOM:
InfoScale deployment details or some reports under Licensing perspective show InfoScale versions as N/A.

DESCRIPTION:
While checking InfoScale version under some of the Licensing reports or 'Deployment details' tab, you may see that InfoScale versions are getting displayed as N/A. You may see this issue on the InfoScale servers where only InfoScale Availability is installed.

RESOLUTION:
Added a fix to get the InfoScale version when only InfoScale Availability is installed.

* 4067133 (Tracking ID: 4067132)

SYMPTOM:
An authenticated remote attacker (administrative/root role) can inject arbitrary web script or HTML into HTTP/GET parameter which reflect the user input without sanitization.

DESCRIPTION:
Cross-site scripting Reflected (XSS) vulnerability affects the Veritas Operations Manager application, which allows authenticated remote attackers to inject arbitrary web script or HTML into HTTP/GET parameter which reflect the user input without sanitization.
It is required to have access to the web application as a user with administrative/root role.
Severity : Medium

Refer technote for more details.
https://www.veritas.com/support/en_US/doc/viom_technote_7.4.2.600 - VIOM version 7.4.2
https://www.veritas.com/support/en_US/doc/viom_technote_8.0.0.100 - VIOM version 8.0

RESOLUTION:
Fixed the affected endpoint.

* 4067136 (Tracking ID: 4067135)

SYMPTOM:
An authenticated remote attacker (administrative/root role) can manipulate the resource name in the GET requests referring to files with absolute paths, it is possible to access arbitrary files stored on the filesystem.

DESCRIPTION:
The web server fails to sanitize the input data allowing a remote authenticated attacker to read files on the filesystem arbitrarily.
By manipulating the resource name in the GET requests referring to files with absolute paths, it is possible to access arbitrary files stored on the filesystem.
It is required to have access to the web application as a user with administrative/root role.
Severity : Low

Refer technote for more details.
https://www.veritas.com/support/en_US/doc/viom_technote_7.4.2.600 - VIOM version 7.4.2
https://www.veritas.com/support/en_US/doc/viom_technote_8.0.0.100 - VIOM version 8.0

RESOLUTION:
Fixed the affected endpoint.

* 4067147 (Tracking ID: 4067146)

SYMPTOM:
N/A

DESCRIPTION:
VIOM Server administrator now can use Global VVR monitoring threshold wizard to set replication threshold values for all VVR in their environment.

Refer technote for more details.
https://www.veritas.com/support/en_US/doc/viom_technote_8.0.0.100

RESOLUTION:
N/A

Patch ID: VRTSrest-2.0.0.1300

* 4088973 (Tracking ID: 4089451)

SYMPTOM:
When a read-only filesystem was created on a Volume, GET on mountpoint's details was throwing error.

DESCRIPTION:
When a read-only filesystem was created on a Volume, GET on mountpoint's details was throwing error as the command which was being used was not working for read-only filesystem.

RESOLUTION:
Used the appropriate command to get details of mountpoint.

* 4089033 (Tracking ID: 4089453)

SYMPTOM:
Some VCS REST APIs were crashing the Gunicorn worker.

DESCRIPTION:
Calling some VCS-related APIs were crashing the gunicorn worker handling the request. A new worker was automatically being spawned.

RESOLUTION:
Fixed the related foreign function call interface in the source code.

* 4089041 (Tracking ID: 4089449)

SYMPTOM:
GET resources API on empty service group was throwing an error.

DESCRIPTION:
When GET resources API was called on an empty service group it was giving an error, and the scenario is not handled.

RESOLUTION:
Scenario added to the code to resolve the issue.

* 4089046 (Tracking ID: 4089448)

SYMPTOM:
Logging in REST API was not in EO-compliant format.

DESCRIPTION:
Timestamp format is not EO-compliant and some attributes were missing for EO compliance.

RESOLUTION:
Changed timestamp, added new attributes like nodename, response time, source and destination IP addresses, username to REST server logs.

Patch ID: VRTSpython-3.9.2.22

* 4075150 (Tracking ID: 4075149)

SYMPTOM:
Security vulnerabilities detected in OpenSSL packaged VRTSperl/VRTSpython released with Infoscale 8.0.

DESCRIPTION:
Security vulnerabilities detected in the OpenSSL.

RESOLUTION:
Upgraded OpenSSL version and re-created VRTSperl/VRTSpython version to fix the vulnerability .

Patch ID: VRTSperl-5.34.0.3

* 4072234 (Tracking ID: 4069607)

SYMPTOM:
Security vulnerability detected on VRTSperl 5.34.0.0 released with Infoscale 8.0.

DESCRIPTION:
Security vulnerability detected in the Net::Netmask module.

RESOLUTION:
Upgraded Net::Netmask module and re-created VRTSperl 5.34.0.1 version to fix the vulnerability .

* 4075150 (Tracking ID: 4075149)

SYMPTOM:
Security vulnerabilities detected in OpenSSL packaged VRTSperl/VRTSpython released with Infoscale 8.0.

DESCRIPTION:
Security vulnerabilities detected in the OpenSSL.

RESOLUTION:
Upgraded OpenSSL version and re-created VRTSperl/VRTSpython version to fix the vulnerability .

Patch ID: VRTSodm-8.0.0.1800

* 4089136 (Tracking ID: 4089135)

SYMPTOM:
VRTSodm driver will not load with VRTSvxfs patch.

DESCRIPTION:
Need recompilation of VRTSodm with latest VRTSvxfs.

RESOLUTION:
Recompiled the VRTSodm with new VRTSvxfs .

Patch ID: VRTSllt-8.0.0.1800

* 4061158 (Tracking ID: 4061156)

SYMPTOM:
IO error on /sys/kernel/slab folder

DESCRIPTION:
After loading LLT module, LS command throws IO error on /sys/kernel/slab folder

RESOLUTION:
IO error on /sys/kernel/slab folder is now fixed after loading LLT module

* 4079637 (Tracking ID: 4079636)

SYMPTOM:
Kernel is getting panicked with null pointer dereference in llt_dump_mblk when LLT is configured over IPsec

DESCRIPTION:
LLT uses skb's sp pointer to chain socekt buffers internally. When LLT is configured over IPsec, llt will receive skb's with sp pointer from ip layer. These skbs were wrongly identified by llt as chained skbs. Now we are resetting the sp pointer field before re-using for interanl chaining.

RESOLUTION:
No panic observed after applying this patch.

* 4079662 (Tracking ID: 3981917)

SYMPTOM:
LLT UDP multiport was previously supported only on 9000 MTU networks.

DESCRIPTION:
Previously LLT UDP multiport configuration required network links to have 9000 MTU. We have enhanced UDP multiport code, so that now this LLT feature can be configured/run on 1500 MTU links as well.

RESOLUTION:
LLT UDP multiport can be configured on 1500 MTU based networks

* 4080630 (Tracking ID: 4046953)

SYMPTOM:
During LLT configuration, messages related to 9000 MTU are getting printed as error.

DESCRIPTION:
On Azure error messages related to 9000 MTU are getting logged. 
These message indicates that to have optimal performance , use 9000 MTU based networks . These are not actual errors but suggestion.

RESOLUTION:
Since customer is going to use it on Azure where 9000 MTU is not supported, hence removed these messages to avoid confusion.

Patch ID: VRTSgms-8.0.0.1800

* 4079190 (Tracking ID: 4071136)

SYMPTOM:
/etc/vx/gms.config file is not created during GMS rpm installation.

DESCRIPTION:
/etc/vx/gms.config file is not created when installing the GMS rpm. It has to be manually created by the user to control GMS start/stop through GMS_START macro.

RESOLUTION:
Changed GMS rpm spec to create gms.config during installation of GMS rpm.

Patch ID: VRTSglm-8.0.0.1800

* 4089163 (Tracking ID: 4089162)

SYMPTOM:
The GLM module fails to load on SLES and RHEL.

DESCRIPTION:
The GLM module fails to load on SLES and RHEL.

RESOLUTION:
GLM module is updated to load as expected on SLES and RHEL.

Patch ID: VRTSdbed-8.0.0.1800

* 4079372 (Tracking ID: 4073842)

SYMPTOM:
Oracle 21c is not supported on earlier product versions.

DESCRIPTION:
Implemented Oracle 21c support with Storage Foundation for Databases.

RESOLUTION:
Changes are done to support Oracle 21c with Storage Foundation for Databases.



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-rhel7_x86_64-Patch-8.0.0.1800.tar.gz to /tmp
2. Untar infoscale-rhel7_x86_64-Patch-8.0.0.1800.tar.gz to /tmp/hf
    # mkdir /tmp/hf
    # cd /tmp/hf
    # gunzip /tmp/infoscale-rhel7_x86_64-Patch-8.0.0.1800.tar.gz
    # tar xf /tmp/infoscale-rhel7_x86_64-Patch-8.0.0.1800.tar
3. Install the hotfix(Please be noted that the installation of this P-Patch will cause downtime.)
    # pwd /tmp/hf
    # ./installVRTSinfoscale800P1800 [<host1> <host2>...]

You can also install this patch together with 8.0 base release using Install Bundles
1. Download this patch and extract it to a directory
2. Change to the Veritas InfoScale 8.0 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