Upgrading from any Prior Release to VVR 4.1 Using the swinstall Command

If you are upgrading from a release prior to VVR 3.5 then you must perform the pre and post upgrade tasks using the method described in this section. If you are upgrading from release 3.5 and later you can use the upgrade scripts to perform the pre and post upgrade tasks as described in section Preserving the Original VVR Configuration Using Upgrade Scripts.

Preserving the Original VVR Configuration Without Using Upgrade Scripts

This section explains how to upgrade to VVR 4.1 using individual commands, instead of the VVR upgrade scripts.

If you are upgrading from a version of VVR prior to VVR 3.5, make sure you change the default port number to 4145, which is an IANA assigned number. For more information, refer to the VERITAS Volume Replicator Planning and Tuning Guide.

To upgrade VVR, perform the following tasks in the order presented below:

1. Preparing for the Upgrade
2. Upgrading the VERITAS Packages
3. Restoring the Original Configuration

Preparing for the Upgrade

• Make sure that the disk groups that contain RVGs are at disk group version 80 or 90, if you are upgrading from any earlier version.
• Make sure the size of the SRL volume is greater than 110 MB. For instructions on resizing the SRL, refer to the VERITAS Volume Replicator Administrator's Guide.

  On both the Primary and the Secondary

If you are upgrading from VVR 3.2 to VVR 4.1, do the following:

• If the following environment variables have been previously set in the file /sbin/init.d/vras-vradmind.sh, note down their values:

VRAS_DEBUG_LOG_TAGS

VRAS_LOG_MAXLEN

OR

• Copy the /sbin/init.d/vras-vradmind.sh file to a location that you can access after the system reboots.

  Perform the following steps on the Primary:

1. Stop all the applications involved in replication. For example, if a data volume contains a file system, unmount it.
2. Stop all the RVGs:
     # vxrvg -g diskgroup stop rvg_name
3. Verify that all the RLINKs are up-to-date.

   ---

    Caution    Do not continue until the RLINKs are up-to-date.

   ---

   
     # vxrlink -g diskgroup status rlink_name
4. To make sure that VVR does not replicate until the upgrade is complete, detach all the RLINKs from the RVGs:
     # vxrlink -g diskgroup det rlink_name
5. Copy the /etc/vx/vras/vras_env and /etc/vx/vvrports files at some location from where you can access them after the upgrade.
6. Dissociate the SRL volume from each RVG.

   ---

     Note    Any checkpoints that you have created will be lost after dissociating the SRL.

   ---

   
     # vxvol -g diskgroup dis srl_name
7. To resolve problems with DCMs in earlier releases, remove all DCMs from stripe-mirror volumes.

   For each RLINK, if srlprot is set to dcm, change it to override:

   
     # vxedit -g diskgroup set srlprot=override rlink_name

   For each stripe-mirror volume, remove the DCM:

   
     # vxassist -g diskgroup remove log volume nlog=0

  Perform the following steps on all Secondary nodes:

1. Stop all the RVGs:
     # vxrvg -g diskgroup stop rvg_name
2. To make sure that VVR does not replicate until the upgrade is complete, detach all the RLINKs from the RVGs:
     # vxrlink -g diskgroup det rlink_name
3. Dissociate the SRL volume from each RVG.

   ---

     Note    Any checkpoints that you have created will be lost after dissociating the SRL.

   ---

   
     # vxvol -g diskgroup dis srl_name
4. To resolve problems with DCMs in earlier releases, remove all DCMs from stripe-mirror volumes.

   For each RLINK, if srlprot is set to dcm, change it to override:

   
     # vxedit -g diskgroup set srlprot=override rlink_name

   For each stripe-mirror volume, remove the DCM:

   
     # vxassist -g diskgroup remove log volume nlog=0
5. Copy the /etc/vx/vras/vras_env and /etc/vx/vvrports files at some location from where you can access them after the upgrade.

  Uninstalling the optional packages

Remove the existing optional packages as described in Removing the VVR Packages.

Upgrading the VERITAS Packages

  On both the Primary and the Secondary:

1. You must upgrade to with VVR 4.1.

   ---

     Note    After OS upgrade, the VxVM version 3.5 is available. Install VxVM from the product disc to overwrite the 3.5 version with version 4.1. For more information, see VERITAS Storage Foundation Installation Guide.

   ---

   If you are upgrading from a version of VVR prior to VVR 3.5, make sure you change the default port number to 4145, which is an IANA assigned number. To retain the existing port numbers, issue the command:

   vrport heartbeat <port_number>

2. After upgrading to VxVM 4.1 on all the required hosts, reboot the system if it has not already rebooted, using the following command:
      # /usr/sbin/shutdown -y 

   ---

     Note    During the reboot process, ignore the following error messages that appear on the Primary console:
   VxVM VVR vxrlink ERROR V-5-1-3371 Can not recover rlink_name. rvg_name is in PASSTHRU mode
   VxVM VVR vxrlink ERROR V-5-1-3473 Log header I/O error
   
   Also ignore the following error message that appears on the Secondary console:
   WARNING: VxVM VVR vxio V-5-0-0 Rlink rlink_name is stale and not replicating

   ---

3. Install the new packages, as described in the section Installing VVR Packages Using the swinstall Command.

   For a list of packages, refer to List of Required and Optional Packages for VVR.

Restoring the Original Configuration

  Perform the following steps on all Secondary nodes:

1. Associate the SRL back to the RVG:
     # vxvol -g diskgroup aslog rvg_name srl_name
2. Before attaching the RLINKs, make sure that the data volumes on the Primary are the same length as the corresponding ones on the Secondary. To shrink volumes that are longer on the Secondary than the Primary, use the following command on each volume on the Secondary:
     # vxassist -g diskgroup shrinkto volume_length

   where length is the length of the volume on the Primary.

3. If you are upgrading from a version prior to VVR 3.5, use the vxprint command to display the local_host attribute of an RLINK; otherwise go to the step 7.
     # vxprint -l rlink_name
4. Copy the tunables from the files that you had saved when performing the steps provided in Preparing for the Upgrade to the current configuration files.
5. Start the VVR daemons:
     # /usr/sbin/vxstart_vvr
6. For releases prior to VVR 3.5, set the new IANA assigned port number for each RLINK by resetting the local_host attribute to the local_host value displayed in step 3:
     # vxedit -g diskgroup set local_host=host_name rlink_name
7. Attach the RLINKs to the RVG:
     # vxrlink -g diskgroup -f att rlink_name

  Perform the following steps on the Primary:

1. Associate the SRL back to the RVG:
     # vxvol -g diskgroup aslog rvg_name srl_name
2. Recover the RLINKs:
     # vxrlink -g diskgroup recover rlink_name

   Ignore the following error message if it occurs:

   
     RLINK rlinkname is already recovered.
3. If you are upgrading from a release prior to VVR 3.5, use the vxprint command to display the local_host attribute of an RLINK.
     # vxprint -l rlink_name
4. Copy the tunables from the files that you had saved when performing the steps provided in Preparing for the Upgrade to the current configuration files.
5. Start the VVR daemons:
     # /usr/sbin/vxstart_vvr
6. For releases prior to VVR 3.5, set the new IANA assigned port number for each RLINK by resetting the local_host attribute to the local_host value displayed in step 3.
     # vxedit -g diskgroup set local_host=host_name rlink_name
7. Attach the RLINKs to the RVG:

   ---

    Caution    Do this only for RLINKs for which you performed all the steps in Preparing for the Upgrade.

   ---

   
     # vxrlink -g diskgroup -f att rlink_name

  Perform the following steps on the Primary and all Secondary nodes

1. If you are upgrading from VVR 3.2 to VVR 4.1, set the previously noted down values of the environment variables VRAS_DEBUG_LOG_TAGS and VRAS_LOG_MAXLEN in the /etc/vx/vras/vras_env file.

   If you change the values in the /etc/vx/vras/vras_env file, restart the VVR servers as follows:

   To stop the VVR servers:

   
               #     /sbin/init.d/vras-vradmind.sh stop
           # /sbin/init.d/vxrsyncd.sh stop

   To restart the VVR servers:

   
           # /sbin/init.d/vras-vradmind.sh start
               # /sbin/init.d/vxrsyncd.sh start
2. After the upgrade, add DCMs back to each volume from which you removed them:
     # vxassist -g diskgroup addlog volume logtype=dcm

   When all DCMs have been added, if srlprot was previously set to dcm for an RLINK, set srlprot back to dcm:

   
     # vxedit -g diskgroup set srlprot=dcm rlink_name 
3. Start the RVG:
     # vxrvg -g diskgroup start rvg_name

   ---

     Note    Importing a disk group created on a previous version of VxVM does not automatically upgrade the disk group to the current version. To use the new features, upgrade all disk groups using the following command:
        # vxdg upgrade diskgroup

   ---

4. Starting with VVR 4.1, a new tunable, vol_rvio_maxpool_sz, serves the same purpose as the voliomem_maxpool_sz tunable.

   If you set the voliomem_maxpool_sz tunable in a prior release, you must set the vol_rvio_maxpool_sz tunable for this release.

   1. Type sam to start the SAM interface.
   2. Use the Tab key to move the control to the SAM areas display.
   3. Select the Kernel Configuration area to display a list of options from which you must select Kernel configuration <character Mode>. From the Kernel Configuration display, select Tunables.
   4. Scroll to the required parameter and select it. Use the Modify Configurable Parameter from the Actions option to modify the parameter as follows:
   
       vol_rvio_maxpool_sz=value;

   where the value is the same as the existing value for voliomem_maxpool_sz. If you are upgrading from any earlier release, the value for voliomem_maxpool_sz is found in SAM database. The change takes effect only after the next system reboot.

   5. To use this value in the current session before reboot, run the following command on the Primary:
   
       # vxtune vol_rvio_maxpool_sz value

   where the value is the same as the existing value for voliomem_maxpool_sz.

   ---

     Note    Do not remove the voliomem_maxpool_sz tunable from the SAM database file if VxVM is using this tunable to set the MAXPOOL size.

   ---