VM Recovery Manager HA requirements

Edit online

Before you plan the implementation of the VM Recovery Manager HA solution, you must understand the other entities and resources that the VM Recovery Manager HA solution requires for disaster recovery operations.

The following requirements must be met before you can install the VM Recovery Manager HA solution:

Software requirements

  • The KSYS logical partition must be running IBM® AIX® 7.2 with Technology Level 2, or later.
  • You must install the latest version of OpenSSL software for the AIX operating system. You can download the latest OpenSSL software from AIX Web Download Pack Programs.
    Note: The latest version of the OpenSSL software is included in the AIX base media.
  • Each LPAR in the host must have one of the following operating systems:
    • AIX Version 6.1, or later
    • PowerLinux
      • Red Hat Enterprise Linux (little endian) Version 7.4, or later (kernel version: 3.10.0-693)
      • SUSE Linux® Enterprise Server (little endian) Version 12.3, or later (kernel version - 4.4.126-94.22)
      • Ubuntu Linux distribution Version 16.04
    • IBM i Version 7.1, or later
  • You can install the VM agent to monitor the virtual machine and applications on the LPARs that run only the following operating systems:
    • AIX Version 6.1, or later
    • PowerLinux
      • Red Hat Enterprise Linux (little endian) Version 7.4, or later (kernel version: 3.10.0-693)
      • SUSE Linux Enterprise Server Version 12.3, or later (kernel version - 4.4.126-94.22)
  • The following table displays the details about the host monitor daemon versions and the minimum corresponding VIOS version required for the host monitor daemon:
    Table 1. Host monitor daemon versions and the corresponding VIOS versions.
    Host monitor daemon version VIOS version VM Recovery Manager HA version
    1.4.0.0

    3.1.1.0

    		 1.4
    1.4.0.1

    3.1.1.20

    		 1.4 SP1
    1.5.0.0

    3.1.2.0

    		 1.5
    1.5.0.1

    3.1.2.20

    		 1.5 SP1
    1.6.0.0 3.1.3.14 1.6
    start of change1.7.0.0end of change 3.1.4.11, or later 1.7
    start of change1.7.0.1end of change 3.1.4.21, or later 1.7 SP1
  • The following table describes the minimum version of dependent products that VM Recovery Manager HA supports for each feature. Refer to the respective dependent product software page for information about its supported versions.
    Feature/ Component VIOS Version KSYS Version Firmware level HMC Version
    Reduced path support VM 3.1.3.10 1.6.0.0 HMC Version 9 Release 9.1.0
    Multi-boot HA 3.1.0.11 1.5.0.0 POWER8 systems with firmware level FW8.6.0 HMC Version 9 Release 9.1.0
    Linux 2.2.5.10 1.1.0.1 HMC Version 9 Release 9.1.0
  • You must install the mandatory APAR fixes and VIOS fixes with VM Recovery Manager HA. For more information on efix download, see Installing VIOS and KSYS interim fixes.
  • start of changeFor a KSYS node that is running IBM AIX Version 73 TL1 SP1, IBM AIX Version 73 TL1 SP2, or IBM AIX Version 73 TL1 SP3, you must install the RSCT efix IJ47384. Contact IBM Support team for the RSCT efix.end of change

Firmware requirements

  • Minimum required levels of IBM Power Systems servers follow:
    • POWER7+™ Systems that have one of the following firmware levels:
      • FW770.90, or later
      • FW780.70, or later except MMB systems (9117-MMB models)
      • FW783.50, or later
    • POWER8 Systems that have one of the following firmware levels:
      • FW840.60, or later
      • FW860.30, or later
    • POWER9 Systems that have the following firmware levels:
      • FW910, or later
    • POWER10 Systems that have the following firmware levels:
      • FW1020, or later
      • FW1030, or later

Installation and configuration requirements

  • You must have root authority to perform any installation tasks.
  • The KSYS LPAR must have at least 1 core CPU and 8 GB memory. These requirements can be higher if you have a large environment of more than 100 LPARs in the data center.
  • As a best practice, you must deploy AIX rules in the VIOS. The VIOS must have enough free space in the /(root), /var, and /usr file system. Additional CPU and memory resources are needed in each VIOS for VM Recovery Manager HA management. You must add at least 1-core CPU and 4 GB memory to the /(root), /var, and /usr file system apart from the VIOS sizing that you are planning to deploy on your production environment, and have at least 1-core CPU and 10 GB memory in case of scalable environment.
  • Ensure that you have enough space in the LPAR so that KSYS filesets can be installed successfully. You must have 30 MB of disk space in the /opt directory and 200 MB of disk space in the /var directory.
  • You must check whether a KSYS installation is already in progress by using the ksysmgr q cl command. If the KSYS software is installed previously, you must uninstall the KSYS software.
  • For the installation of VM agent, ensure each virtual machine meets the following disk space requirements:
    • At least 100 MB disk space in the /usr directory to install the VM agent filesets.
    • At least 1 GB disk space in the /var directory for log files.
  • Your production environment must have two Virtual I/O Servers per host. You can have a maximum of 24 Virtual I/O Servers in a single host group. If more than two Virtual I/O Servers exist in a host, you can exclude it from the KSYS configuration settings. For more information about setting up dual VIOS in your environment, see Setting up a dual VIOS by using the HMC.
  • start of changeFor a multi-node KSYS cluster, the same version of operating system must be installed on all nodes. If the operating system that is running on a node is on an earlier version than the other node, you must specify the node that is running the earlier version of the operating system before the node that is running the later version of the operating system when you run a command.end of change

Host group requirements

  • Host group can have a logical name with a maximum of 64 characters.
  • A single KSYS LPAR can manage up to four host groups. A host group can consist of maximum 24 VIOSes as currently SSP supports maximum of 24 VIOSes per SSP cluster.
  • Network and storage must be configured on all hosts in the host group such that any VM from any host can be migrated to any other host within the host group.
  • For each host group, the KSYS subsystem requires two disks for health cluster management. A disk of at least 10 GB is required for health monitoring of the hosts, called as repository disk, and another disk of at least 10 GB is required for health data tracking, called as HA disk, for each host group. All these disks must be accessible to all the Virtual I/O Servers on each of the hosts in the host group. The hostname of the Virtual I/O Servers must be in the Fully Qualified Domain Name (FQDN) format.

HMC requirements

  • The VM Recovery Manager HA solution requires HMC Version 9 Release 9.1.0, or later. It is recommended to have each host managed by two HMCs. The HMC must have enough free space.
  • Ensure that you can perform Live Partition Mobility (LPM) operation on the VMs among the hosts that you want to be a part of VM Recovery Manager HA management. You can use HMC-based LPM validation to ensure that the virtual machines can move from a host to any other host in the host group.
  • In a scalable environment, if two or more host groups are configured to manage large number of virtual machines, you must have two HMCs to manage each host group for optimal performance.
  • For POWER7+™ Systems, or later in which the Simplified Remote Restart attribute is not set for a VM in the HMC, when the VM is relocated from a source host to a destination host, the time-of-day change might not be updated correctly. To retain the correct time-of-day clock for a VM across the hosts, you must set the VIOS partitions profile of both the source host and the destination host as the time reference partition by enabling the Time Reference Partition option in the HMC. For more information about how to set the Time Reference Partition, see Synchronizing the hypervisor and Service Processor time-of-day clocks to Time Reference Partition.
  • To migrate an IBM i virtual machine from the source host to the destination host, verify that the Restricted I/O Partition check box for the IBM i logical partition is selected in the HMC. For more information about how to verify the restricted I/O mode, see Verifying that the IBM i mobile partition is in the restricted I/O mode.
  • Ensure that the automatic reboot attribute is not set for any VM in the HMC. The KSYS subsystem validates this attribute and notifies you to disable this attribute. If you set this attribute, it can lead to unpredictable results such as the VM might restart on two hosts simultaneously. To check the attribute for an LPAR (lpar_name) that is present in the host (host_name), run the following command in the HMC: 
    lssyscfg -r lpar -m <host_name> -F name,auto_start | grep <lpar_name>
    For example: 
    lssyscfg -r lpar -m host1 -F name,auto_start | grep lpar1
    An output that is similar to the following example is displayed:
    lpar1,1
    To unset the auto_start attribute, run the following commands in the HMC terminal:
    1. chsyscfg -r prof -m <host_name> -i lpar_name=<lpar_name>,name=default,auto_start=0
    2. chsysstate -r lpar -m <host_name> -o shutdown -n <lpar_name> --immed
    3. chsysstate -r lpar -m <host_name> -o on -n <lpar_name> -f default
    4. lssyscfg -r lpar -m <host_name> -F name,auto_start | grep <lpar_name>
  • When you add a host or manage a new VM that is co-managed by HMC and PowerVM NovaLink, set the HMC to be in the master mode. Otherwise, the discovery operation fails and the virtual machines in the host are not monitored for the high-availability function.
  • When Live Partition Mobility (LPM) is triggered through the graphical user interface or the ksysmgr command for a virtual machine, the progress of the movement, in percentage, is displayed. This feature requires HMC version 9 Release 9.3.0, or later.

Network requirements

  • All virtual machines (VMs) that are managed by the VM Recovery Manager HA solution must use virtual I/O resources through VIOS. The VMs must not be connected to a physical network adapter or any dedicated devices.
  • Storage area network (SAN) connectivity and zoning must be configured so that VIOS can access the disks that are relevant to the hosts.
  • Ensure independent redundant SAN and network connections are established across the VIOS in each hosts in the host group.
  • Ensure that the KSYS LPAR has HTTP Secure (HTTPS) connectivity to all the HMCs that can manage the hosts in the host group.
  • The same virtual LAN (VLAN) must be configured across the site.
  • If VM monitoring is enabled, VMRHA requires exclusive use of VLAN ids 101 and 102.
  • Ensure redundant connections are established from the KSYS LPAR to HMC and from HMC to VIOS logical partitions. Any connectivity issues between KSYS, HMC, and VIOS logical partitions can lead to disruption in the regular data collection activity and disaster recovery operations.
  • Ensure proper RMC connection between the VMs and HMC. If RMC connection between VM and HMC has issues, the Partition Load Manager (PLM) cannot work and hence the VMs cannot be recovered.

GUI requirements

  • The logical partition (LPAR), in which you want to install the GUI filesets, must be running IBM AIX 7.2 with Technology Level 2 Service Pack 1 (7200-02-01), or later. You can choose to install the GUI server fileset on one of the KSYS nodes.
  • The LPAR in which you are installing the GUI server must run in Enhanced Korn shell that uses the /usr/bin/ksh93 shell script.
  • The LPAR in which you are installing the GUI server fileset must have at least 1-core CPU and 8 GB memory. If you are installing the GUI server fileset on the KSYS node, ensure that the required resources are available on the KSYS node to accommodate the GUI.
  • Google Chrome and Mozilla Firefox web browsers are supported to access the GUI for the VM Recovery Manager HA solution.

Coexistence with other products

The VM Recovery Manager HA solution and other products can co-exist in the same environment with the following considerations:

IBM Power® Virtualization Center (PowerVC)
  • If you use the PowerVC solution to perform the live partition mobility (LPM) operation of virtual machines, ensure that VM remains within the host group that is defined in the KSYS configuration settings. Otherwise, the virtual machine might be disconnected from the VM Recovery Manager HA configuration and cannot be monitored for failures.
  • Do not use the HA management function in the PowerVC solution. If both the PowerVC and VM Recovery Manager HA solutions are used to handle unplanned events, the recovery operations might fail.
IBM PowerHA® SystemMirror® software
Even if you are using the PowerHA SystemMirror solution for application high-availability, you can use the VM Recovery Manager HA solution for hardware failures and automated VM restart operations. This type of deployment can bring the entire cluster back online by restarting the failed PowerHA node or VMs on other hosts.

If you have deployed both the PowerHA SystemMirror and VM Recovery Manager HA solutions, consider the following guidelines:

  • If the primary node of the PowerHA configuration fails, the PowerHA solution starts the workload on secondary node of the PowerHA configuration. The VM Recovery Manager HA solution restarts the failed VM, which is the old primary LPAR of PowerHA, on another host. The restarted VM can rejoin the cluster and continue to provide higher level of high-availability.
  • If you deploy both the PowerHA solution and the VM Recovery Manager HA solution, you must not configure the VM agent in the PowerHA VMs because PowerHA application management is sufficient for application high-availability.
  • Ensure that you define the anti-collocation policies for nodes or LPARs of the PowerHA cluster.
  • For information about the procedure to configure PowerHA SystemMirror with VM Recovery Manager HA solution to achieve high availability of the KSYS subsystem, see Achieving KSYS high availability through IBM PowerHA.
The VM Recovery Manager HA solution can co-exist with other cluster technologies also, such as Oracle RAC and Veritas Cluster Server.
PowerVM® NovaLink
Currently, the VM Recovery Manager HA solution works with the PowerVM environment that is configured with the HMC. When NovaLink and HMCs are deployed together, the VM Recovery Manager HA solution can work only if HMCs are set to be in the master mode. The VM Recovery Manager HA solution communicates with the HMC for continuous monitoring and relocation operations.

Licensing considerations

  • With the VM Recovery Manager HA solution, the virtual machines (VMs) that must be replicated or managed by the solution are hosted by processor cores. These managed VMs do not determine the licensing count, but the count of processor cores that are hosting the managed VMs determines the licensing cost. This means that the count of whole number of processor cores that are hosting the VMs that are being replicated or managed by the VM Recovery Manager HA solution determines the license count.
  • The VM Recovery Manager HA licenses are installed on an AIX partition that is designated to be the partition that is hosting the KSYS orchestrator. The VM Recovery Manager HA license enables the KSYS orchestrator.
  • The AIX partition that is hosting the VM Recovery Manager HA solution can be located anywhere in proximity to the HMCs and storage servers that the VM Recovery Manager HA solution is managing. For instance, if you are implementing the VM Recovery Manager HA solution, you can install the KSYS subsystem on an AIX partition of a system that is located outside of the managed host group.
  • The VM Recovery Manager HA solution conforms to the active/inactive technology, which includes Live Partition Mobility (LPM) in your high availability configuration. Therefore, the entire VM is restarted on an alternate logical partition. You do not need to install the production licenses in the target system because the VM is restarted along with the corresponding workload.