Frequently asked questions

Edit online

If you have questions about the VM Recovery Manager HA solution, review the following list of answers to some frequently asked questions.

What is VM Recovery Manager HA?

The VM Recovery Manager HA solution implements high availability of virtual machines based on the VM restart technology. Read more about the solution in the VM Recovery Manager HA overview topic.

What is KSYS?

The KSYS subsystem (also known as the controlling system) is a controlling software for the HA operation. The KSYS software is installed an AIX® Version 7.2.2, or later. If the KSYS subsystem detects failure of hosts, VMs, or critical applications, the KSYS subsystem restarts the virtual machines in another host.

What is a host group?

Hosts are grouped in the VM Recovery Manager HA configuration settings to act as a backup for each other. When failures are detected in any host, VMs in the failed host are relocated and restarted on other healthy hosts within the group. This group of hosts is called a host group. For more information, see Host group requirements.

Which POWER® servers can be included for high availability by using the VM Recovery Manager HA solution?

POWER7+™ processor-based server, or later. For more information, see Firmware requirements.

Which operation systems are supported for virtual machines in hosts?

AIX Version 6.1, or later
PowerLinux (Red Hat, SUSE, and Ubuntu Linux® distributions)
IBM i Version 7.2, or later

For more information, see Software requirements.

What is the minimum version of HMC and VIOS that must be used for this solution?

See Firmware requirements and HMC requirements.

What are the CPU and memory requirements for the VM Recovery Manager HA solution?

You must have 30 MB of disk space in the /opt directory and 200 MB of disk space in the /var directory to install the KSYS filesets. For typical cloud environments with approximately 100 LPARs, the KSYS LPAR must have at least one core of CPU and 8 GB of memory. You must also ensure that VIOS contains enough resources for HA management. For typical environments, VIOS resources must be increased by at least one core CPU and at least 2 GB memory beyond the sizing based on the workload requirements. The VM Recovery Manager HA solution also requires two free disks of at least 10 GB that are connected and available across all the Virtual I/O Servers that are included for HA management in the host group. For more information, see Installation and configuration requirements.

How do I install VM Recovery Manager HA solution?

The VM Recovery Manager HA solution consists of few filesets that can be installed by using the AIX installation format on the KSYS LPAR. You can install the GUI server on a separate AIX LPAR or on the KSYS LPAR. Optionally, you can install the VM agents in the guest LPARs for VM and application HA management. For more information, see Installing the KSYS software.

How can I run the operations for configuration and HA management?

You can use both the command-line interface and the GUI to run the HA operations. You can use the ksysmgr command for all possible operations in the KSYS subsystem. To install the GUI, see Installing VM Recovery Manager HA.

Does the GUI depend on open source components?

Yes. The VM Recovery Manager HA solution provides scripts to download the required images and to install them easily. For more information about the GUI installation, see Installing GUI filesets.

How do I configure my environment by using the VM Recovery Manager HA solution?

After installing the VM Recovery Manager HA software on the AIX LPAR (KSYS LPAR), the KSYS subsystem can be initialized and managed by using the VM Recovery Manager HA GUI or the ksysmgr command. Use the GUI or the CLI to initialize the KSYS subsystem, to register the HMC and hosts, and to create the host groups. When the discovery operation is triggered through the GUI or ksysmgr command, the KSYS subsystem discovers all resources by working with the HMC and the VIOS. After the discovery operation is complete, you can run the verification operation to ensure that the entire environment is error-free and the virtual machines are ready to move to any hosts in the host group. For configuration steps, see Setting up the KSYS subsystem.

What are the setup requirements for the host group?

A host group indicates a group of hosts that are logically chosen and named by the administrator. You can group a set of hosts based on your business requirements. You must be able to relocate any VM on any of the hosts within the host group. Therefore, network and storage requirements of the VM must be met on each of the hosts. In addition, Live Partition Mobility (LPM) validation of a VM must be successful for each of the hosts in the host group. For more information, see Host group requirements.

If a host fails, will VM Recovery Manager HA automatically restart the virtual machines?

Yes. By default, the KSYS subsystem automatically restarts the virtual machines on another host within the host group and notifies you about the relocation operation. You can customize this setting and set the advisory mode so that the KSYS subsystem only notifies you about the various failures. For more information, see Restart policy.

Will KSYS alert me only for host failures or for VM failures and application failures as well?

By default, the KSYS subsystem provides high-availability feature at host level. You can optionally install the VM agent filesets in the guest virtual machines for high-availability feature at VM and application level. For more information, see Installing VM agents and Setting up the VM agent.

How do I manage applications for high-availability?

You must install the VM agent in the guest VMs. Currently, the VM agent is supported for AIX and Linux operating systems. After you install the VM agent, you can initialize the VM agent and register the application HA management through a single command that is available in the VM agent component. For more information, see ksysvmmgr command.

Can I register my own custom monitoring methods with VM Recovery Manager HA?

Yes. Use the ksysvmmgr command in the VM to register application start, stop, and monitoring methods.

Can I control the start sequences of applications within a VM?

Yes. Use the ksysvmmgr command to define the start sequences of applications within the VM. For example, you might want to start the database application first and then start the other applications that use the database application.

Can I start the application after the VM has been relocated automatically?

Yes. You can use the ksysvmmgr command to start the application automatically after the VM is restarted. You can also change this setting to start the applications manually.

After the initial configuration, can I modify the environment?

Yes. You can add or delete VMs or hosts and such modifications are discovered automatically by the KSYS subsystem during its scheduled periodic scans. You can also run the discovery operation manually to register the changes in the environment immediately. For more information, see Modifying the KSYS configuration.

Can VM Recovery Manager HA work with LPM?

Yes. You can perform the LPM operation on any of the VMs within a host group that is managed by the VM Recovery Manager HA solution. You can also use the ksysmgr command or the GUI to perform the LPM operations. For more information, see Planned migration of virtual machines.

Do I need to perform LPM only through VM Recovery Manager HA or can I do it through the HMC, PowerVC, or LPM tool?

You can use the VM Recovery Manager HA solution to perform planned HA activities by using the LPM operation. However, you can use any other tool to do LPM that works best for you. If you are using another tool, ensure that the VM moves to another host that is within the host group.

Can VM Recovery Manager HA co-exist with other solutions such as PowerVC and PowerHA® SystemMirror?

Yes. For more information, see Coexistence with other products.

Does VM Recovery Manager HA support NovaLink?

Not directly. However, in PowerVM NovaLink-based environments that also have HMCs, you can register scripts that can be plugged into VM Recovery Manager HA. The sample scripts can be customized based on your environment. These scripts change the HMC settings to be in master mode for brief periods so that the KSYS subsystem can work with the HMC to monitor the environment for high availability.

Which storage systems does VM Recovery Manager HA support?

The VM Recovery Manager HA solution can support any storage systems that are certified with the VIOS, except internet Small Computer Systems Interface (iSCSI) storage devices. Storage disks that are related to VMs must be accessible across all the hosts within the host group so that VMs can move from a host to any other host within the host group.

Can I use VM Recovery Manager HA with SVC HyperSwap®?

SAN Volume Controller (SVC) and Storwize® HyperSwap technology perform hidden synchronous mirroring across short distances. The VM Recovery Manager HA solution can be used across that distance if the storage system fulfills all the requirements of shared storage and is certified with the VIOS.

Which types of network do VM Recovery Manager HA support?

The VM Recovery Manager HA solution can support any network that is certified with the VIOS that supports the Live Partition Mobility operation.

Which types of VIOS storage configuration do VM Recovery Manager HA support?

The VM Recovery Manager HA solution supports virtual SCSI (vSCSI), N_Port ID virtualization (NPIV), Shared Storage Pool (SSP), and any storage configuration that is supported for the LPM operation.

What all can I manage from the VM Recovery Manager HA GUI?

The VM Recovery Manager HA GUI offers deployment, health monitoring, and administrative experiences.

Does VM Recovery Manager HA relocate a VM if I shut down or stop the VM manually?

No. The VM Recovery Manager HA solution checks the HMC and firmware resources to verify whether the lack of heartbeats from a VM is caused because of an administrator-initiated operation. In those cases, VM will not be relocated.

How is fencing performed during failures?

The VM Recovery Manager HA solution stops the failed VM through the HMC before starting the VM on another host. If the KSYS subsystem cannot connect to the HMC or if the HMC cannot stop the VM successfully, the KSYS subsystem cancels the automated restart operation and instead sends a critical event to the administrator about the VM failure.

Can I configure the alerts in KSYS to be sent as text messages instead of emails?

Yes. Contact your phone company to obtain the phone number that can be represented as an email address, and register the updated email address with the KSYS subsystem. For more information, see Setting contacts for event notification.

Can I register our own method or script to be invoked when specific events occur?

Yes. Use the ksysmgr command to register scripts to be called by the KSYS subsystem when specific events occur. For more information, see Event notification script management.

How do I save the KSYS configuration?

Use the ksysmgr command to save the KSYS configuration as a snapshot that can be restored later. For more information, see Backing up the configuration data.

How do I update the KSYS LPAR or the KSYS software?

You can update the KSYS software with newer releases of VM Recovery Manager HA and update the KSYS LPAR with newer releases of AIX. During the update process, the production workloads in the VMs are not disrupted. During the KSYS update process, the HA monitoring will be suspended and will resume after the update operation is complete.

Can we predict the impact on the environment because of a VM or host failure?

Use the ksysmgr report system relocation_plan [vm=vm_list|host=host_list] command to review the relocation plan for the VMs. When you run this command, the KSYS subsystem reviews the available spare resources and policies to predict where the VMs will be restarted.

How do I know whether the environment is protected from an HA perspective?

You can run the ksysmgr verify command to validate the environment. The KSYS subsystem communicates with the HMC and the VIOS to check and report any issues in the environment. Additionally, the KSYS subsystem checks the CPU and memory resources to predict the host failure recovery count for the HA environment. The host failure recovery count is an attribute of the host group in units of number of hosts. The host failure recovery count indicates how many host failures can be tolerated by the host group. The KSYS subsystem picks up the largest host, which is hosting the LPARs that sum up to largest amount of CPU resources, and checks whether the LPARs from this host can be recovered by using the spare capacity in the remaining hosts. If that validation passes, then the host failure recovery count is set as 1. The KSYS subsystem then picks up the next largest host and checks whether the failure of two largest hosts in the host group can be tolerated. If yes, the host failure recovery count is set as 2. You must deploy the environment such that the environment has enough spare CPU and memory capacity to achieve a host failure recovery count value of at least 1. To view the host failure recovery count, run the following command:

ksysmgr -v report system

While setting up HG from GUI, can a user access HMC deleted from backend using CLI?: No, user cannot access the HMC deleted from backend using CLI. This is not preferred because unavailability of HMC leads to failure of Host Group deployment.

What are global mode and local mode in VM Recovery Manager HA?: The KSYS subsystem creates a health monitoring Shared Storage Pool (SSP) cluster across the Virtual I/O Servers (VIOS) that are part of the host group. One of the Virtual I/O Servers (VIOS) is designated as database node (DBN). The Virtual I/O Servers are considered to be in global mode when the KSYS subsystem can access health information from the database node. When the KSYS subsystem cannot access health information from the database node, the KSYS subsystem is informed about the lack of access to the database node and the Virtual I/O Servers are considered to be in local database mode.