* * * READ ME * * *
                * * * Veritas Volume Manager 8.0.2 * * *
                        * * * Hot Fix 2607 * * *
                         Patch Date: 2025-09-08


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
----------
Veritas Volume Manager 8.0.2 Hot Fix 2607


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


PACKAGES AFFECTED BY THE PATCH
------------------------------
VRTSvxvm


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


SUMMARY OF INCIDENTS FIXED BY THE PATCH
---------------------------------------
Patch ID: 8.0.2.2607
* 4191415 (4188385) vxiod processes are consuming high CPU, causing the server to intermittently enter a hung state.
Patch ID: 8.0.2.2606
* 4191095 (4191131) Collecting VRTSexplorer can lead to disable/enable of DMP subpaths
Patch ID: 8.0.2.2605
* 4191083 (4191085) vxattach script unable to parse devices with same disk(dm) names
Patch ID: 8.0.2.2604
* 4190826 (4190559) Disk resize operation doesn't re-read the partition table for the non-optimized path.
* 4190828 (4187857) Disk resize operation corrupted the private region, leading to DG disablement.
Patch ID: 8.0.2.2603
* 4190361 (4190360) all dmpdaemon threads hang in do_read_cache_page
Patch ID: 8.0.2.2602
* 4190316 (4190294) system went into a permanent hung while VVR was doing data volumes recovery after rebooting one of the non-logowner node.
Patch ID: 8.0.2.2601
* 4189965 (4189966) vxconfigd hangs in SLES15


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

Patch ID: 8.0.2.2607

* 4191415 (Tracking ID: 4188385)

SYMPTOM:
vxiod processes are consuming high CPU, causing the server to intermittently enter a hung state.

DESCRIPTION:
Due to spinlock contention, vxiod processes with a similar stack are consuming high CPU when 96 VVR connections are configured. This leads to CPU starvation, causing the server to intermittently enter a hung state.
 #3 [] end_repeat_nmi at 
    [exception RIP: native_queued_spin_lock_slowpath+290]
 #4 [] native_queued_spin_lock_slowpath at 
 #5 [] queued_spin_lock_slowpath at 
 #6 [] _raw_spin_lock_irqsave at 
 #7 [] volrp_sendsio_start at

RESOLUTION:
The code change has been modified to reduce the spinlock contention.

Patch ID: 8.0.2.2606

* 4191095 (Tracking ID: 4191131)

SYMPTOM:
Collecting VRTSexplorer can lead to disable/enable of DMP paths with system having RHEL 9.3 and above Operating system.

DESCRIPTION:
As part of VRTSexplorer collect "vxdisk -o listreserve list <disk_name>" gets executed. As part of this command SCSI sets DISCONNECT in msg_byte 
of SCSI request. This value is not handled in DMP code and DMP wrongly treats it as transportation failure and further disables the DMP subpaths.

RESOLUTION:
Appropriate code changes are done to handle the DISCONNECT error.

Patch ID: 8.0.2.2605

* 4191083 (Tracking ID: 4191085)

SYMPTOM:
VxVM commands are slow after system boot
Continuous reconfigurations messages can be seen in dmpevents logs
Many scandisks commands seen in vxattach logs

DESCRIPTION:
Issue occurs if disk names of one device matches with device name of some other device
# vxdisk list
DEVICE          TYPE            DISK         GROUP        STATUS
ibm_shark0_0 auto:cdsdisk    ibm_shark0_9  testdg1      online shared  
ibm_shark0_1 auto:cdsdisk    ibm_shark0_0  testdg2      online shared  << disk name same as device ibm_shark0_0

# less /etc/vx/log/dmpevents.log
Tue Aug 12 02:49:35.000: Reconfiguration is in progress
Tue Aug 12 02:49:35.000: Reconfiguration has finished
Tue Aug 12 02:49:47.000: Reconfiguration is in progress
Tue Aug 12 02:49:47.000: Reconfiguration has finished

# less /etc/vx/log/vxattachd_debug.log
12/08/25 02:46:33 Processing dmpnode ibm_shark0_0
12/08/25 02:46:33 Attempting to online dmpnode ibm_shark0_0
12/08/25 02:46:34 Attempting to online dmpnode ibm_shark0_0
12/08/25 02:46:35 Attempting to online dmpnode ibm_shark0_0
12/08/25 02:46:36 Attempting to online dmpnode ibm_shark0_0

RESOLUTION:
vxattachd script was unable to correctly parse the status of the device(online/offline etc) when the disk names of one device matches with device name of other. Code fix has been done to parse the status correctly.

Patch ID: 8.0.2.2604

* 4190826 (Tracking ID: 4190559)

SYMPTOM:
Following a disk resize operation beyond 1TB, I/O errors are observed: "access beyond end of device".

DESCRIPTION:
To expand a disk beyond 1TB, Veritas Volume Manager (VxVM) must convert the disk's partition table from VTOC to GPT. During this process, VxVM writes both the primary and backup GPT headers to the disk. Issues the BLKRRPART ioctl to prompt the kernel to re-read the updated partition table. However, in configurations with ALUA storage arrays, VxVM currently issues BLKRRPART only on the optimized path. As a result, non-optimized paths still use the outdated VTOC partition table. When I/O is subsequently issued on these non-optimized paths (which are unaware of the expanded GPT layout), the kernel reports "access beyond end of device" errors.

RESOLUTION:
The code change has been made to fix the issue.

* 4190828 (Tracking ID: 4187857)

SYMPTOM:
After resizing a disk to over 1TB and rebooting the master node, the disk group (DG) was disabled due to corruption in the log copy within the private region.

DESCRIPTION:
Resizing a disk beyond 1TB requires converting the disk format from VTOC to GPT and updating the private region offset accordingly. However, on the slave node, the private region offset was not updated correctly. Consequently, when the slave node took over as master, it flushed the kernel log to an incorrect offset, corrupting the log copy area in the private region and causing the DG to be disabled.

RESOLUTION:
The issue has been addressed by a code fix that ensures the private region offset is properly updated during disk resize operations.

Patch ID: 8.0.2.2603

* 4190361 (Tracking ID: 4190360)

SYMPTOM:
vxconfigd not coming online. All dmpdaemon threads waiting in the function do_read_cache_page

DESCRIPTION:
# ps -ef| grep dmpdaemon
root       59168       2  0 Jul04 ?        00:00:00 [dmpdaemon]
root       59169       2  0 Jul04 ?        00:00:00 [dmpdaemon]
root       59170       2  0 Jul04 ?        00:00:00 [dmpdaemon]
root       59171       2  0 Jul04 ?        00:00:00 [dmpdaemon]
root       59172       2  0 Jul04 ?        00:00:00 [dmpdaemon]
root       59173       2  0 Jul04 ?        00:00:00 [dmpdaemon]
root       59174       2  0 Jul04 ?        00:00:00 [dmpdaemon]
root       59175       2  0 Jul04 ?        00:00:00 [dmpdaemon]
root       59176       2  0 Jul04 ?        00:00:00 [dmpdaemon]
root       59177       2  0 Jul04 ?        00:00:00 [dmpdaemon]

# cat /proc/59168/stack
[<0>] do_read_cache_page+0x51d/0x780
[<0>] read_part_sector+0x3a/0xfb
[<0>] read_lba+0x112/0x240
[<0>] efi_partition+0x1de/0x6a5
[<0>] blk_add_partitions+0x147/0x3e0
[<0>] bdev_disk_changed+0x6c/0xe0
[<0>] __blkdev_get+0x22d/0x340
[<0>] blkdev_get+0x1a5/0x2d0
[<0>] __device_add_disk+0x372/0x520
[<0>] dmp_register_disk+0x14c/0x2d0 [vxdmp]
[<0>] dmp_register_blk_device+0x12/0x30 [vxdmp]
[<0>] dmp_daemons_loop+0x1a4/0x220 [vxdmp]
[<0>] kthread+0x134/0x150
[<0>] ret_from_fork+0x1f/0x40

RESOLUTION:
When dmpnode is being registered and gives an error, a deadlock was being hit in the code. The dmpdaemon threads are stuck in the function do_read_cache_page because of this. Code changes has been done to resolve the issue.

Patch ID: 8.0.2.2602

* 4190316 (Tracking ID: 4190294)

SYMPTOM:
system went into a permanent hung while VVR was doing data volumes recovery after rebooting one of the non-logowner node.

DESCRIPTION:
When write_ack is in SYNC mode, VVR acknowledges the write only after data volume write is complete. In case the updates generation number is changed, VVR will postpone releasing ilock. What happened is a cluster reconfiguration had been triggered during the same time when these SIOs were in logend queue. Due to a bug, those SIOs got freed without releasing the ilock.

RESOLUTION:
Code changes have been made to release the ilock when VVR aborts the SIOs in logend queue.

Patch ID: 8.0.2.2601

* 4189965 (Tracking ID: 4189966)

SYMPTOM:
vxconfigd hangs and multiple udev-worker thread seen in UN state on the system

DESCRIPTION:
crash> ps | grep ' UN '
     2793    2471   6  ff422950c0690000  UN   0.0    55884     8400  (udev-worker)
     2795    2471  13  ff42295a915ac000  UN   0.0    55628     8272  (udev-worker)
     2797    2471   7  ff422958e40a8000  UN   0.0    55884     8400  (udev-worker)
     2802    2471   5  ff422950c06f8000  UN   0.0    55884     8400  (udev-worker)
     2805    2471  13  ff422958eb660000  UN   0.0    55884     8400  (udev-worker)
     2806    2471   2  ff4229526b7e0000  UN   0.0    55884     8400  (udev-worker)
     2812    2471  12  ff42296108bb8000  UN   0.0    55884     8400  (udev-worker)
     2819    2471   5  ff42295f64ab0000  UN   0.0    55628     8272  (udev-worker)

RESOLUTION:
Currently the code re-reads partition table unconditionally which cases a high amount of reads on the device via udev threads. Code changes has been done so that the partition is re read only when there is a device change. Code changes has been done to fix the issue.



INSTALLING THE PATCH
--------------------
1.Before-the-upgrade :-  
  (a) Stop I/Os to all the VxVM volumes.
  (b) Umount any filesystems with VxVM volumes.
  (c) Stop applications using any VxVM volumes.
2.Check whether root support or DMP native support is enabled or not:
        # vxdmpadm gettune dmp_native_support
  If the current value is "on", DMP native support is enabled on  this machine.
  If disabled: goto step 4.
  If enabled: goto step 3.
3.If DMP native support is enabled:
  a.It is essential to disable DMP native support.
    Run the following command to disable DMP native support
        # vxdmpadm settune dmp_native_support=off
  b.Reboot the system
4.Select the appropriate RPMs for your system, and upgrade to the new patch.
        # rpm -Uhv  VRTSvxvm-8.0.2.2607-RHEL9.x86_64.rpm
5.Run vxinstall to get VxVM configured
        # vxinstall
6.If DMP Native Support was enabled before patch upgrade, enable it back.
  a. Run the following command to enable DMP native support
        # vxdmpadm settune dmp_native_support=on
  b.  Reboot the system
        # reboot


REMOVING THE PATCH
------------------
# rpm -e VRTSvxvm --nodeps


SPECIAL INSTRUCTIONS
--------------------
None


OTHERS
------
NONE