Storage Foundation 7.4.2 Configuration and Upgrade Guide - AIX

Last Published:
Product(s): InfoScale & Storage Foundation (7.4.2)
Platform: AIX
  1. Section I. Introduction and configuration of Storage Foundation
    1. Introducing Storage Foundation
      1. About Storage Foundation
          About Veritas Replicator Option
        About Veritas InfoScale Operations Manager
        About Veritas Services and Operations Readiness Tools (SORT)
    2. Configuring Storage Foundation
        Configuring Storage Foundation using the installer
      2. Configuring SF manually
          Configuring Veritas File System
        Configuring DMP support for booting over a SAN
        Configuring SFDB
  2. Section II. Upgrade of Storage Foundation
    1. Planning to upgrade Storage Foundation
        About the upgrade
        Supported upgrade paths
      3. Preparing to upgrade SF
          Getting ready for the upgrade
          Preparing for an upgrade of Storage Foundation
          Creating backups
        4. Pre-upgrade planning when VVR is configured
            Considerations for upgrading SF to 7.4 or later on systems with an ongoing or a paused replication
          2. Planning an upgrade from the previous VVR version
              Planning and upgrading VVR to use IPv6 as connection protocol
          Verifying that the file systems are clean
          Upgrading the array support
        Using Install Bundles to simultaneously install or upgrade full releases (base, maintenance, rolling patch), and individual patches
    2. Upgrading Storage Foundation
        Upgrading Storage Foundation with the product installer
      2. Upgrade Storage Foundation and AIX on a DMP-enabled rootvg
          Upgrading from prior version of SF on AIX 7.1 to SF 7.4.2 on a DMP-enabled rootvg
          Upgrading the operating system from AIX 7.1 to AIX 7.2 in Veritas InfoScale 7.4.2
        Upgrading SF on a Virtual I/O server (VIOS) from 6.2.1 or later to 7.4.2
        Upgrading the AIX operating system
      5. Upgrading Volume Replicator
        1. Upgrading VVR without disrupting replication
            Upgrading VVR on the Secondary
            Upgrading VVR on the Primary
        Upgrading SFDB
    3. Performing an automated SF upgrade using response files
        Upgrading SF using response files
        Response file variables to upgrade SF
        Sample response file for SF upgrade
    4. Performing post-upgrade tasks
        Optional configuration steps
        Recovering VVR if automatic upgrade fails
        Resetting DAS disk names to include host name in FSS environments
        Upgrading disk layout versions
        Upgrading VxVM disk group versions
        Updating variables
        Setting the default disk group
        Verifying the Storage Foundation upgrade
  3. Section III. Post configuration tasks
    1. Performing configuration tasks
        Switching on Quotas
        Enabling DMP support for native devices
      3. About configuring authentication for SFDB tools
          Configuring vxdbd for SFDB tools authentication
  4. Section IV. Configuration and Upgrade reference
    1. Appendix A. Support for AIX Live Update
        Support for AIX Live Update (Technology preview)
    2. Appendix B. Installation scripts
        Installation script options
        About using the postcheck option
    3. Appendix C. Configuring the secure shell or the remote shell for communications
        About configuring secure shell or remote shell communication modes before installing products
        Manually configuring passwordless ssh
        Setting up ssh and rsh connection using the installer -comsetup command
        Setting up ssh and rsh connection using the utility
        Restarting the ssh session
        Enabling rsh for AIX
    4. Appendix D. Changing NFS server major numbers for VxVM volumes
        Changing NFS server major numbers for VxVM volumes

Support for AIX Live Update (Technology preview)

Veritas InfoScale supports the AIX Live Update feature. Starting with AIX Version 7.2, the AIX operating system provides the AIX Live Update feature that aims to eliminate the workload downtime that is associated with the AIX kernel update operation.

The AIX Live Update feature provides an efficient way to apply the AIX updates, ifixes, service packs, and technology levels without restarting the system. You can trigger the AIX 7.2 Live Kernel Update using the geninstall -k command that updates the OS automatically without any manual intervention or downtime. Though the I/O operations are paused for a few seconds, the critical enterprise workloads remain almost during the Live Update operation. The LKU framework recognizes if InfoScale is installed on the server and takes appropriate action while performing live updates.


If Live update operation fails due to any AIX specific error, Veritas does not guarantee sanity of machine after LKU operation is completed.

Prerequisites to use the LKU feature with InfoScale
  • The systems with InfoScale running on it must be LKU compatible

  • InfoScale is running on a platform where IBM supports LKU with InfoScale

  • The Technology Level to which you want to upgrade must be supported by InfoScale

  • LKU should not be executed with the array having 2Mb gatekeeper disk

How does Live Update work?
  • The Live kernel update operation gets initiated using the geninstall -k command from the original partition where the workload is currently running.

  • The LKU framework provisions another LPAR on-the-fly with updated kernel extensions. This partition is referred to as a surrogate partition.

  • The surrogate partition is patched with the updated kernel versions while the workload is still running on the original partition.

  • Once the surrogate partition is up and running, the workload is moved from the original partition to the surrogate partition using the checkpoint and restart mechanism.

  • The workload resumes on the surrogate partition in a "chrooted" environment.

When you perform an LKU operation, the geninstall command uses the configuration file that is available in the /var/adm/ras/liveupdate directory. This configuration file contains the data that is required for the LKU operation. You can use the lvupdate.template file from the /var/adm/ras/liveupdate directory to create the file. The template file contains the descriptions of all possible fields required for the LKU operation. The following example shows a sample file:

       kext_check = yes
       aix_mpio = no
      nhdisk  = <hdisk1>
      mhdisk  = <hdisk2>
      lpar_id  = <lparid>
      management_console = <management console ip>
      user = <user>

When you create this configuration file, ensure that:

  • You set the value of aix_mpio field to no to disable the native Multi-Path I/O (MPIO).

  • Provide hdisk# as values for the nhdisk and mhdisk fields.

    • nhdisk: The names of disks to be used to make a copy of the original rootvg which will be used to boot the Surrogate.

    • mhdisk: The names of disks to be used to temporarily mirror rootvg on the Original LPAR.

  • The size of the specified disks must match the total size of the original rootvg.

  • These disks should be free. Application or Administrator should not use these disks for any other operation during the Live update operation.

  • These disks should not be a part of any active or disabled Logical Volume Manager (LVM) volume groups.

  • These disks should not be a part of any VxVM disk group and should not have any VxVM tag.

Limitations of LKU with InfoScale

Consider the following restrictions for the AIX Live Update operation with InfoScale:

  • LKU supports only the storage components of InfoScale

  • LKU is not supported in a CVM environment

  • LKU is not supported for setups with combined configuration of DMP and third-party driver. For example, native MPIO.

  • LKU does not support the following InfoScale features:

    • Clustering for HA or DR

    • Support for 3rd party multipathing solution

    • VVR and VFR Replication

    • Snapshot

    • FSS

    • SmartIO

    • Deduplication

    • Compression

    • In-memory statistics handling

    • Power VC

    • User initiated VxVM operations during LKU

    • Read-Write clones (checkpoints)

    • Cluster Filesystem

    • Partition Directories

  • InfoScale product upgrades are not supported through the LKU operation

  • LKU operation is not supported in high availability configurations for InfoScale

  • LKU operation is not supported in presence of VxVM swap devices

  • LKU operation is not supported if any of the administrative tasks like fsadm, fsck is running

  • LKU operation fails if any changes like volume creation, deletion and so on are made to the VxVM configuration within the LKU start and MCR phase

  • LKU operation is not supported in presence of vSCSI disk

  • The integration of InfoScale products and LKU framework is supported only for the Local Mount filesystem

Known issues

LKU operation fails with the "kernel extensions are not known to be safe for Live Update: vxglm.ext(vxglm.ext64)" error.

A Live Update operation fails if a loaded kernel extension is not marked as safe in the safe list.

If the Group Lock Manager (GLM) is installed on a system, but the VRTSglm package is not marked with the SYS_LUSAFE flag, the LKU operation fails with the "kernel extensions are not known to be safe for Live Update: vxglm.ext(vxglm.ext64)" error.


Mark the VRTSglm package SYS_LUSAFE before initiating the LKU operation.

To add the VRTSglm package to the safe list for the Live Update operation, use the following command:

# lvupdateSafeKE -a /usr/lib/drivers/vxglm.ext\(vxglm.ext64\)

LKU operation fails if the ODM file system is mounted

In the technology preview mode, LKU operation is not supported with VRTSodm.


  1. Unmount the ODM file system using the umount /dev/odm command.

  2. Initiate the LKU operation using the geninstall -k command.