Upgrading VM Recovery Manager HA

Edit online

If you are upgrading the VM Recovery Manager HA solution from the previous version to the latest version, you must install the packages that have updates to the existing software in your environment.

Prerequisites:

You must have root authority to perform the installation tasks.
When you install the new filesets, ensure that the existing version of the KSYS software is not running any active operations. The installation of the newer version of the KSYS software fails if the discovery, verification, or move operation is running in the existing version of the KSYS software.
All KSYS-related operations such as discover, verification, move, and cleanup must be complete before you attempt to upgrade the existing version of the VM Recovery Manager HA solution to the latest version. Run the ksysmgr query system status monitor=yes command to check the status of KSYS-related operations.
Before you install or upgrade VM monitor fileset, ensure that you set the virtual machine in the KSYS subsystem to unmanage, and run the discovery operation. Then, install or upgrade the VMM fileset at the VMM. You can set the unmanaged virtual machine to managed depending on your requirement. You must run the discovery operation after you have set the unmanaged virtual machine to managed.
It is recommended to stop the IBM.VMR daemon by running the stopsrc -s IBM.VMR command before starting the upgrade operation. You must restart the IBM.VMR daemon by running the startsrc -s IBM.VMR command after the upgrade operation completes.

The following table provides information about upgrade possibility from a lower version to the higher version of the VM Recovery Manager HA solution.

Table 1. VMRM HA upgrade table
Current version of KSYS subsystem	Upgrade version of KSYS subsystem
VM Recovery Manager HA 1.5.0.0	VM Recovery Manager HA 1.5.0.1 VM Recovery Manager HA 1.6.0.0 VM Recovery Manager HA 1.7.0.0 VM Recovery Manager HA 1.7.0.1
VM Recovery Manager HA 1.5.0.1	VM Recovery Manager HA 1.6.0.0 VM Recovery Manager HA 1.7.0.0 VM Recovery Manager HA 1.7.0.1
VM Recovery Manager HA 1.6.0.0	VM Recovery Manager HA 1.7.0.0 VM Recovery Manager HA 1.7.0.1 VM Recovery Manager HA 1.8.0.0
VM Recovery Manager HA 1.7.0.0	VM Recovery Manager HA 1.7.0.1 VM Recovery Manager HA 1.8.0.0
VM Recovery Manager HA 1.7.0.1	VM Recovery Manager HA 1.8.0.0
VM Recovery Manager HA 1.8.0.0	VM Recovery Manager HA 1.8.0.1

Complete the following procedures to upgrade the VM Recovery Manager HA solution.

Upgrading the KSYS software.
Upgrading VIOS to Version 4.1.0.00.
Upgrading VM agents in the virtual machines.

Note: You must have root authority to perform any uninstallation tasks.

Upgrading the KSYS software

Contact IBM sales team for information about download location of the VM Recovery Manager HA solution.
Copy the filesets to the location where the existing filesets are installed.
Decompress the filesets according to the guidelines that are provided with the package.

To install the filesets by using SMIT panel, complete the following steps:

To open the SMIT panel, enter the following command:
```
smit install
```

In the Install and Update Software screen, select Update Installed Software to Latest Level (Update All), and press Enter.

                            Install and Update Software
                                                                                
Move cursor to desired item and press Enter.
                                                                                
  Install Software
  Update Installed Software to Latest Level (Update All)
  Install Software Bundle
  Update Software by Fix (APAR)
  Install and Update from ALL Available Software

In the Update Installed Software to Latest Level (Update All) screen, change the values according to your situation. You must also accept new license agreements. Press Enter after you make all other changes.

Check the installation summary at the end of the installation output by scrolling to the end of the output. The output indicates whether the installation of your fileset was successful.
If trace spooling is enabled and the trace file size is large, you must wait for a few minutes before you run the ksysmgr command. If the installation was not successful, check the reason of failure in the output.
After upgrading of the KSYS software successfully, run the following script in the GUI server: /opt/IBM/ksys/ui/server/dist/server/bin/vmruiinst.ksh. Then, restart the GUI server by running the stopsrc -s vmruiserver and startsrc -s vmruiserver commands.

Upgrading VIOS to Version 4.1.1.0

Note: The following steps apply only to the migration process.

Ensure that the VIOS version 3.1.4.21 above and the Postgres version 13 are installed on your KSYS subsystem. To check the Postgres version, run the following command:
```
cat /var/vio/SSP/<cluster_name> /D_E_F_A_U_L_T_061310/VIOSCFG/DB/PG/PG_VERSION
```
To check the mount point of the Postgres database, run the following command:
```
mount
```
Ensure that the SSP cluster and database are in a healthy state. To verify the state of the cluster, run the following command in the padmin command-line interface:
```
cluster -status
```
The padmin command-line interface must display OK state for all the VIOS that are part of the SSP cluster.
Upgrade a VIOS, for example VIOS1, to version 4.1.1.0 then check the status of upgrade progress. To check the progress of the upgrade process, run the following command:
```
viosupgrade -q -l
```
An output that is similar to the following message must display: VIOS upgrade completed successfully.
Wait for two minutes to get the cluster in the stable state. To check the state of the cluster, run the following command:
```
cluster -status
```
The output must display OK state for the upgraded VIOS.
Please verify the VIOS release notes and apply if any mandatory efix required.
Restart the VIOS after you have applied the efix.
After the VIOS1 is up and running, you must wait for two minutes to get the cluster in the stable state. You can observe that the Postgres version of the VIOS is still version 13.
Run the discovery operation on the KSYS controller node. Ensure that the discovery operation completes successfully.
Similarly, upgrade all other VIOSes by repeating Step-4 to Step-7 for each VIOS. After all the VIOSes are upgraded, the Postgres version will be update to 15. To check the Postgres version, run the following command:
```
cat /var/vio/SSP/<cluster_name> /D_E_F_A_U_L_T_061310/VIOSCFG/DB/PG/PG_VERSION
```

Upgrading VM agents

Upgrade the VM agent RPM packages based on the following Linux® distributions in the virtual machine:

In Red Hat Enterprise Linux (RHEL) (little endian) virtual machines, run the following commands:
```
rpm -Uvh vmagent-1.8.0.1-1.0.el7.ppc64le.rpm
```
In SUSE Linux Enterprise Server (SLES) (little endian) virtual machines, run the following command:
```
rpm -Uvh vmagent-1.8.0.1-1.0.suse123.ppc64le.rpm 
```

These commands upgrade the VM agent software without modifying the current configuration of the virtual machines.

Upgrading KSYS filesets for KSYS high availability supported with PowerHA SystemMirror

To upgrade the KSYS software in a KSYS LPAR on which PowerHA SystemMirror is configured, complete the following steps:

Stop PowerHA cluster service on all KSYS nodes by using the smit clstop command.
Upgrade the KSYS fileset on all KSYS nodes.
Start the PowerHA cluster services by using the smit clstart command.

Upgrading KSYS filesets for KSYS high availability supported with PowerHA SystemMirror

To upgrade the KSYS software in a KSYS LPAR on which PowerHA SystemMirror is configured, complete the following steps:

Stop PowerHA SystemMirror cluster service on all KSYS nodes by using the smit clstop command.
Upgrade the KSYS fileset on all KSYS nodes.
Start the PowerHA SystemMirror cluster services by using the smit clstart command.

Upgrading KSYS filesets for KSYS high availability without support of PowerHA SystemMirror

You can upgrade your KSYS fileset from Version 1.6 to Version 1.7, or later, on KSYS nodes in which PowerHA SystemMirror is configured. From Version 1.7, or later, VM Recovery Manager HA provides high availability feature for KSYS nodes without PowerHA SystemMirror as well. For VM Recovery Manager HA Version 1.7, or later, it is recommended to use inbuilt high availability feature for the KSYS nodes. The inbuilt feature handles all resource failure events of the KSYS subsystem. To upgrade KSYS fileset to Version 1.7 or later, complete the following steps:

To check the group leader node (GL node) through the KSYS subsystem, run the following command:
```
lssrc -ls IBM.VMR | grep Group
```
To check the group leader node (GL node) through the ConfigRM RSCT tool, run the following command:
```
lssrc -ls IBM.ConfigRM | grep Group
```
Run the following PowerHA SystemMirror operations on the group leader node (GL node).
Stop all PowerHA SystemMirror services on both nodes by using the smit clstop or clmgr command with the RG offline option.
The PowerHA SystemMirror cluster state is INIT on both nodes. Sometimes a conflict occurs in the cluster state of the group leader node that is displayed in the KSYS subsystem and the group leader node that is displayed in RSCT. Ignore this conflict.
1. Run the following command in the KSYS subsystem to view the group leader node:
```
lssrc -ls IBM.VMR | grep Group
```
2. Run the following command in RSCT to view the group leader node:
```
lssrc -ls IBM.ConfigRM | grep Group
```
  The output of the these commands might show different group leaders. That is expected.
To start the IBM.VMR daemon on the first node (for example, Node1), run the following command:
```
startsrc -s IBM.VMR
```
Upgrade the VM Recovery Manager HA solution on the first node (for example, Node1) from Version 1.6 to Version 1.7, or later.
To verify the version of VM Recovery Manager HA on the first node, run the following command:
```
lslpp -l | grep ksys
```
You cannot use the run ksysmgr query version command on the group leader node (GL node).
Upgrade the VM Recovery Manager HA solution on the other node (for example, Node2) from Version 1.6 to Version 1.7, or later. The IBM.VMR daemon becomes stable on both nodes after the upgrade operation completes. The group leader node in the KSYS subsystem changes and the Node1 becomes the group leader. Because the daemon was stopped and then restated during upgrade operations, the restart operation of the daemon triggers the failover operation.
Check the group leader node (GL node) from RSCT, also check the group leader node (GL node) from the KSYS subsystem. The KSYS subsystem and RSCT both point the same group leader node (GL node). The PowerHA services remain in the INIT state. The high availability feature is active and it monitors the resources.

Note: During the upgrade process, the PowerHA SystemMirror cluster is intact and the services are in the INIT state. To use the high availability features of the VM Recovery Manager HA Version 1.7, or later, do not start the PowerHA SystemMirror services. You can view resources of both nodes (For example, Node1 and Node2) of the cluster by using the lsrsrc IBM.VMR_SITE_CLD command. If resources of only one node is displayed, then restart the IBM.VMR daemon on both nodes. To stop the VMR daemon, run the stopsrc -s IBM.VMR -c ; sleep 10 command. To start the VMR.IBM daemon, run the startsrc -s IBM.VMR command.