Description
This article contains information about the latest Alerts, release notifications, patches as well as known issues for InfoScale 7.4.1 (AIX, Linux, Solaris).For more information on the following topic, click on one of the following links:
Alerts
Veritas Technologies LLC issues alerts for issues involving potential data loss, security vulnerabilities or other critical issues often requiring immediate action.
See the InfoScale support page for alert information
Back to Top
Major and Minor Releases
InfoScale 7.4.1 (AIX, Linux, Solaris) is now available. Release Date: February 1, 2019
See the Related Article, Veritas Entitlement Management System Guide, for more information on licenses and downloads.
Back to Top
Patches
Patches for InfoScale 7.4.1 (AIX, Linux, Solaris) will be posted on the SORT site. Veritas highly recommends that you check for any patches needed for this release. The SORT site includes a subscription notification for patches.
sort.veritas.com/patch/finder
New patch to support RHEL 8.1
Release Date: December 30, 2019
Support for Red Hat Enterprise Linux 8.1 is provided through a new patch, which is available for download on SORT at:
https://sort.veritas.com/patch/detail/15537
Note: Upgrades between major operating system versions are not supported. If your InfoScale setup exists on a version earlier than RHEL 8.0 and if you want to upgrade to this patch, perform the following tasks sequentially:
- Back up your InfoScale configuration.
- Uninstall the InfoScale product.
- Upgrade the operating system as per the supported upgrade path.
- Install the InfoScale product or patch.
- Restore your InfoScale configuration.
New release to support RHEL 8.0
Release Date: November 22, 2019
The installation files for this release are available for download at the same location as the one for the InfoScale 7.4.1 GA release. The file names begin with Veritas_InfoScale_7.4.1_RHEL8.
Note: The new product installers can be launched on RHEL 8.0 systems only.
New release to support SLES 15
Release Date: September 16, 2019
The installation files for this release are available for download at the same location as the one for the InfoScale 7.4.1 GA release. The file names begin with Veritas_InfoScale_7.4.1_SLES15.
Note: The new product installers can be launched on SLES 15 systems only.
New patch to support RHEL 7.7
Release Date: August 06, 2019
Zero Day Support (ZDS) for Red Hat Enterprise Linux 7.7 is provided through a new patch, which is available for download on SORT at:
https://sort.veritas.com/patch/detail/15132
Patch 1200 to support Nutanix HCI environments and other updates
Release Date: July 09, 2019
Patch 1200 is available for download on SORT at:
For RHEL 6: https://sort.veritas.com/patch/detail/15048For RHEL 7: https://sort.veritas.com/patch/detail/15049
Known Issues
For known issues, consult our Knowledge Base:
https://www.veritas.com/support/en_US.html
Issues on RHEL 8.0 and RHEL 8.1
You may encounter the following issues on a RHEL 8.0 or a RHEL 8.1 system.
Online migration from the native file system to VxFS is not supported. (3986388)
---
A system may panic when a resize operation is performed on a disk that is initialized as a simple disk. (3990473)
When a system disk, which is initialized as a simple disk, is resized using the following command, the system may panic:# vxdisk resize <disk_name> [length=<new_size>]
Workaround: None
---
The DMP metadevices support the OS native LVM fails. (3990925)
Changes have been made to the bootloader configuration (grub2) in RHEL 8.0 and RHEL 8.1, due to which the creation of LVM volumes and volume groups on DMP metadevices fails.
Workaround: None
---
The filesystem log replay may get stuck if the fsck command results in a crash or a core dump during cluster reconfiguration. (3989317)
During a cluster reconfiguration, the vxfsckd daemon internally runs the fsck command. If the execution of this command results in a crash or a core dump, the file system log replay may get stuck and the file system may become inaccessible.
Workaround: Manually terminate the process that runs the fsck command to proceed with the cluster reconfiguration and to make file system accessible again.
---
The product installer appears to imply that SCSI-3 compliance is required for the InfoScale configuration to be completed in and SFRAC environment. However, such compliance is not required. (3990492)
When you run the product installer in an SFRAC environment, the following prompt does not appear:
Does your storage environment support SCSI3 PR?
The appearance of this prompt seems to imply that your environment may require SCSI-3 compliance for the InfoScale configuration to be completed successfully. However, InfoScale has not such requirement.
Note: This issue appears on all supported platforms.
Workaround: None; you can ignore the absence of this prompt from the product installer in an SFRAC environment.
---
VVR replication stops working after InfoScale Storage or InfoScale Enterprise is upgraded or reinstalled. (3988672)
The vradmin startrep command fails, and the following error is logged:
VxVM VVR vxrlink ERROR V-5-1-5321 vxnetd threads are not running on secondary host <hostname>
Alternatively, the vradmin repstatus command fails and the following error is logged:
Paused due to network disconnection
The replication stops working because the vxnetd process is not properly stopped during the uninstall subtask that is part of the upgrade or reinstall operation. Thus, vxnetd cannot start properly after the new InfoScale packages are installed.
Workaround: Restart the primary or secondary VVR hosts or logowners one after the other.
---
I/O hang may occur due to inefficitent I/O throttling.
This is a RHEL issue in which I/O throttling is not properly handled at the operating system layer. When the volume of I/O on a cluster node is high, the operating system is unable to perform throttling for the additional I/Os from the application that are routed through VxVM. This issue occurs intermittently when the queue depth of some underlying devices is set to a value that is lower than the corresponding blk_mq registered queue depth.
Bugzilla ID with Red Hat: https://access.redhat.com/support/cases/#/case/02528087
Workaround: None
---
The "no blkg associated for bio on block-device" kernel-level warning may appear in the system logs during direct I/O to an underlying device. (3990118)
This a one-time warning that you may encounter in a rare case. This issue occurs due to a limitation in the way InfoScale interacts with the kernel. You can safely ignore this warning.
Workaround: None
---
Issues on RHEL 8.0
You may encounter the following issues on a RHEL 8.0 system.
The installer takes longer than expected to start the installation (3987228)
Installer attempts to contact the Veritas SORT site for the release matrix or the installer patch download, and if IPv6 is not configured properly, it waits for a long until the process times out.
Workaround: Disable IPv6 on the system, and then run the installer again.
You may use the following commands disable IPv6:# sysctl -w net.ipv6.conf.default.disable_ipv6=1
# sysctl -w net.ipv6.conf.all.disable_ipv6=1
---
A system becomes unresponsive after restart, and "out of memory" errors are logged; also, VxFS fails to mount after a hard restart (3987148)
These issues occur because:
(a) the installer starts vxconfigd in the user slice and the vxvm-boot service is inactive after installer completes its configuration, and
(b) the CVMVxconfigd agent does not bring vxconfigd online if the vxvm-boot service is inactive.
Workaround: Perform the following precautionary tasks manually after the installer completes its tasks.
1. Check whether vxvm-boot is in the inactive (dead) state on the cluster nodes by using the following commands sequentially:
# systemctl status vxvm-boot
? vxvm-boot.service - VERITAS Volume Manager Boot service
Loaded: loaded (/usr/lib/systemd/system/vxvm-boot.service; enabled; vendor preset: disabled)
Active: inactive (dead)
# ps -ef | grep vxconfigd
root 21712 1 0 Oct15 ? 00:02:28 /sbin/vxconfigd -k -m disable -x syslog
2. Start the vxvm-boot service on the nodes where it is inactive by using the following command:
# systemctl start vxvm-boot
3. Check whether vxvm-boot is in the active state by using the following commands sequentially:
# systemctl status vxvm-boot
? vxvm-boot.service - VERITAS Volume Manager Boot service
Loaded: loaded (/usr/lib/systemd/system/vxvm-boot.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2019-10-24 12:03:07 UTC; 3s ago
Process: 29694 ExecStart=/etc/vx/vxvm-boot start (code=exited, status=0/SUCCESS)
# ps -ef | grep vxconfigd
root 30001 1 11 12:02 ? 00:00:05 vxconfigd -k -x cleartempdir -x syslog
Note: This workaround is not effective after the issue occurs. If you encounter the issue, you can only perform a hard restart to recover from it.
---
Other issues or limitations
The following miscellaneous issues or limitations exist with InfoScale.
InfoScale deployment is not supported when secure boot is enabled. (3958975)
---
Limitation related to LLT on RHEL (3983163)
RHEL 8.0 onwards, the platform mandates that the NetworkManager service is used to control the networking interfaces. If you configure LLT manually, ensure that you set the NM_CONTROLLED parameter to yes in the interface file.
---
Data corruption may occur if you perform a rolling upgrade of InfoScale Storage or InfoScale Enterprise from 7.3.1 or earlier to 7.4 or later during replication (3951527)
A rolling upgrade to InfoScale 7.4 or later is not supported in a Volume Replicator (VVR) environment. With InfoScale 7.3.1 or earlier, you could pause replication, perform a rolling upgrade, and then safely resume replication. However, to upgrade to 7.4 or later, you must first stop any ongoing replication, perform a full upgrade of the product and the disk groups on both the sites, and then start replication.
To upgrade to InfoScale 7.4 or later in a VVR environment
1. Stop replication.
2. Perform a full upgrade on the primary and the secondary sites to the same InfoScale version.
3. Upgrade the disk groups on both the sites.
4. Start replication.
---
In an Azure environment, vxconfigd panics during startup on systems where the multiqueue scheduler is enabled by default (3986476)
In an Azure environment, when you configure an InfoScale product on a RHEL 7.6, RHEL 7.7, CentOS 7.7, or a SUSE 12 system where the multiqueue (mq-deadline) scheduler is enabled, the system panics during vxconfigd startup. This issue occurs because InfoScale does not yet support multiqueue schedulers.
Workaround:
To work around this issue, disable the multiqueue scheduler if it is enabled on a RHEL/ CentOS/ SUSE system, and then install or start the InfoScale product.
To disable the multiqueue scheduler on RHEL and CentOS
- Set the following value in the
/etc/sysconfig/grubfile:
scsi_mod.use_blk_mq=n - Rebuild the grub:
# grub2-mkconfig -o /boot/grub2/grub.cfg - Restart the system to apply the changes.
To disable the multiqueue scheduler on SUSE
- Set the following value in the
/etc/default/grubfile:
scsi_mod.use_blk_mq=n - Rebuild the grub:
# grub2-mkconfig -o /boot/grub2/grub.cfg - Restart the system to apply the changes.
---
InfoScale provides limited support for VMware vSphere 7.0 and vSAN 6.7 U3 or 7.0 datastore with SCSI-3 enabled VMDK disks on the Linux platform. For details, refer to the article at:
https://www.veritas.com/support/en_US/article.100048628
---
Documentation
For more information on the release documentation:
InfoScale 7.4.1 Documentation for AIX
InfoScale 7.4.1 Documentation for Linux
InfoScale 7.4.1 Documentation for Solaris
SORT documentation site
Software Compatibility Lists (SCL) and Hardware Compatibility Lists (HCL):
https://sort.veritas.com/documents/doc_details/vie/7.4.1/AIX/CompatibilityLists/
https://sort.veritas.com/documents/doc_details/vie/7.4.1/Linux/CompatibilityLists/
https://sort.veritas.com/documents/doc_details/vie/7.4.1/Solaris/CompatibilityLists/
For a listing of the End of Support Dates, refer to this matrix on SORT:
https://sort.veritas.com/eosl
As RHEL8 support was introduced after the release of InfoScale 7.4.1, the list of Required platform packages for RHEL8 is available through the 'Installation and Upgrade Checklist' tool on SORT:
https://sort.veritas.com/checklist/install
Errata
The Cluster Server 7.4.1 Bundled Agents Reference Guide - Linux mentions that the Mii attribute is used to monitor the NIC agent. However, this attribute has been deprecated since the InfoScale 7.4.1 release, because the mii tool itself is deprecated on Linux. The documentation has not been updated to reflect this change.
Back to Top
Related Knowledge Base Articles
Was this content helpful?
Translated Content
Please note that this document is a translation from English, and may have been machine-translated. It is possible that updates have been made to the original version after this document was translated and published. Veritas does not guarantee the accuracy regarding the completeness of the translation. You may also refer to the English Version of this knowledge base article for up-to-date information.