VM Recovery Manager DR limitations

Edit online

Consider the restrictions that are described in the topic for the VM Recovery Manager DR solution.

Limitations

1.10.0.0 Limitations

PBHA-PBR support

Host groups and workgroups can be created only from the home site. Host group creation from the backup site is not supported.
VM Recovery Manager DR does not create DR target partitions or enable partition-level disaster recovery configuration on the storage system. The required storage configuration must be completed before resources are discovered.
The DR rehearsal operation can be initiated only from the home site.
Before unmanaging a disk, virtual machine, or deleting a cluster, move the associated volumes from the replicated storage volume group to another non-replicated volume group.
Unmanaging disk/VM is supported only from Home site.
Moving virtual machines between host groups or workgroups that belong to different storage partitions is not supported.

1.9.0.1 Limitations

Safeguarded snapshot policies are supported only on SVC storage agents running firmware 8.7 or later and are not applied automatically during discovery, after a restore, virtual machines must be restarted, and volume groups cannot be deleted until all safeguarded snapshots are removed.
If all Virtual I/O Servers in SSP are in local database mode, the Failure Detection Engine (FDE) does not detect the host failure of other hosts through running Virtual I/O Servers efficiently.
Discovery is required to detect the host failure.

Safeguarded snapshot policies are supported only on SVC storage agents running firmware 8.7 or later and are not applied automatically during discovery, after a restore, virtual machines must be restarted, and volume groups cannot be deleted until all safeguarded snapshots are removed.
If all Virtual I/O Servers in SSP are in local database mode, the Failure Detection Engine (FDE) does not detect the host failure of other hosts through running Virtual I/O Servers efficiently.
Discovery is required to detect the host failure.

1.9 Limitations

host_lun_validation is supported only for SVC and EMC(SRDF) storage types.
The command ksysmgr q vm display_all shows the wrong host name after an unplanned workgroup move to the backup site, before cleanup.
When the workgroup is created on backup site, we will not honor flex capacity.
The KSYS subsystem cannot retrieve or monitor the SSP state of VIOS nodes if the VIOS name configured in the HMC does not match the hostname of the VIOS node
The KSYS subsystem cannot retrieve or monitor the SSP state of VIOS nodes if the VIOS name configured in the HMC does not match the hostname of the VIOS node

1.8 to 1.3 Limitations

In ksys-HA cluster, while restoring the snapshot hostname of ksys nodes should be identical to hostname collected during snapshot.
During cluster removal or workgroup modification, hosts created on target storage by ksys discovery may not be automatically removed. Manual cleanup may be required to ensure accurate configuration.
VM Recovery Manager does not support adding more than one storage agent per site, if policy based replication is configured.
At least one valid replication policy with a volume group must exist on the backup storage for Policy-Based Replication (PBR) to function correctly. If the backup storage does not have any replication policies, the system may encounter errors during site discovery or replication setup.
The status information of a host that is shown in the HMC must be consistent across the HMCs in which the host is connected and added to the KSYS configuration.
At least one valid replication must exist across source and backup unity storage to run a successful discovery.
While adding a host to the KSYS configuration, the Resource Monitoring Control (RMC) connection between the configured HMCs of the host, Virtual I/O Servers, and the virtual machines must be in an active state.
The Virtual I/O Servers in the cluster that are in the unhealthy state must be unmanaged.
If the serial number of a storage agent has changed, remove the storage agent from the KSYS subsystem and add the storage agent again for the serial number change to take effect in the KSYS configuration.
The VM Recovery Manager DR does not support sharing a managed disk or unmanaged disk between virtual machines of two different workgroups or host groups.
The site-level cleanup operation might not show proper results when the previous move operation has failed because of restarting the KSYS daemon or the KSYS subsystem.
- Workaround: Run the cleanup operation on the host group.
Removing a consistency group in the Hitachi storage system and the EMC storage system takes a longer time. Therefore, the KSYS cluster deletion operation might also take a longer time depending on the number of workgroups in the KSYS subsystem.
Do not perform the Live Partition Mobility (LPM) operation across host groups. All LPM operations must be performed within a host group. If the LPM operation is initiated across host groups, and if the virtual machine is part of a workgroup, the site-level discovery operation might not complete because of an error.
On VIOS nodes, if the disks of a shared storage pool (SSP) are not accessible after the system is reactivated because it was shutdown or rebooted, the state of the disks continues to be down. This does not start the SPPR correctly and requires a quorum to come back online. Choose one of the following workaround options.
- Workaround option 1: If you don’t want to reboot the VIOS, complete the following procedure:
  1. Restore the disk connectivity.
  2. To make the disks available to the system, run the cfgmgr command as a root user.
  3. Run the following commands:
    - padmin: clstartstop -stop -m <node>
    - padmin: clstartstop -start -m <node>
- Workaround option 2: If you want to restart the VIOS, complete the following procedure:
  1. Restore the disk connectivity.
  2. Reboot the VIOS node.
If a VM is migrated from host1 to host2 because failure of virtual machine or applicaiton, and the applications are stable in the virtual machines that are on the host2. At a later time, if the VM from the host2 needs to be migrated because of an application failure, the host1 will not be considered as a backup host for application failure migration because the VM had previously failed on host1. If host1 needs to be considered as a backup host for a future application failure, use the following workaround.
- Workaround: After the VM is stable on host2, clear the FailedHostList list of the VM by running the following command:
```
chrsrc -s 'Name="VMName"' IBM.VMR_LPAR VmRestartFailedCecs='{""}' 
```
If you want the system to ignore the unmanaged Virtual I/O Servers in the HMC during a discover operation, disable the storage area network (SAN) zones from the selected VIOS before performing the DR operation.
The cleanup operation on a VM with vSCSI disk fails in the local database mode.
- Workaround: Bring the SSP cluster back to the global mode.
The ksysmgr command fails to start or stop applications that belong to an application dependency setup if Virtual I/O Servers are in local database mode.
The discovery operation or the KSYS restart operation automatically starts the dependent applications that are part of an application dependency setup and that were stopped manually.
- Workaround: Consider one of the following workaround options:
  - Do not perform the discovery operation after stopping the dependent application.
  - Disable the auto-discover and the quick discovery features.
  - Do not restart the KSYS subsystem after you stopped the dependent application.
The reboot operation of the VMs that are running on the Linux VM agent might take a longer time than expected, and the discovery operation might fail and display the following message:
```
Restart has encountered error for VM <vm_name>.
```
- Workaround: Re-run the discovery operation.
The VM Recovery Manager DR solution cannot be used if the Live Partition Mobility (LPM) feature is disabled at firmware level.
In the HADR and HADRHA cluster type, when the DR-test discovery operation or the move operation is in progress, the KSYS subsystem does not migrate virtual machines automatically when the host fails. The KSYS subsystem only generates a host failure event.
- Workaround: You must manually recover virtual machines by running the ksysmgr restart command.
When temporary I/O errors occurs at the VIOS cluster-level, the migration process of the virtual machines after the host failure is not triggered automatically.
- Workaround: You must initiate the host-level restart operation by using GUI or command-line interface. To initiate the host-level restart operation, run the following command:
```
ksysmgr restart host <host_name>
```
If a virtual machine is migrated across host groups, you must run the discovery operation on the source host group and the target host group, respectively. After running the discovery operation on both host groups, the KSYSNODE node reflects the migration status of the virtual machine.
The backup and restore LPAR control blob (LCB) feature is not supported for virtual machines that are part of an asymmetric host-group configuration.
If a VM profile exists on multiple hosts, the command ksysmgr query vm host=<hostname> might not display the VM details properly.
- Workaround: Run the command with another host that has the same VM profiles.
If a current repository disk is down, automatic replacement does not occur on previously used repository disk that has the same cluster signature. If no other free backup repository disk is available the automatic replacement operation fails.
- Workaround: Run the following command to clear the previous cluster signatures:
```
cleandisk -r <diskname> 
```
As part of the HA verification operation, the KSYS subsystem verifies configuration of each VM against all backup hosts within a site. In a scalable environment, when the KSYS subsystem sends parallel verification requests, if HMC is busy with already received requests, the new request can lead to exceeding the maximum supported requests, then the verification operation fails with the following error:
```
HSCLB401 The maximum number of partition migration commands allowed are already in progress. 
```
- Workaround: Re-run the verify operation on the host group.
The move operation fails when all NPIV ports of a physical Fibre Channel (FC) port are used by VMs, and none of the NPIV ports on the FC adapters are free.
- Workaround: You must keep at least 20% of NPIV ports free on each Fibre Channel (FC) port.
The discovery operation at the site level fails and the VM is not recoverable after a VM is migrated from one host group to another host group by using live partition mobility (LPM) from the hardware management console (HMC).
- Workaround: Run the discovery operation on the source host group, then run the discovery operation on the target host group.
Note: If the scheduled site-level auto discovery operation is run before performing the above mentioned workaround and the discovery operation on the source host group fails while adding the migrated virtual machine's disk(s) to the existing consistency group, you must perform the following workaround:
- Workaround: You must manually delete the virtual machine's disk(s) from the consistency group of the source host group.
The VMR daemon crashes if you remove the hardware management console (HMC) from the KSYS configuration when the discovery or migration operation is in progress. Do not make any changes in the KSYS configuration when the discover or migration operation is in progress.
The EMC Unity's REST API call might not send the complete information about disks of the replication session to the KSYS subsystem. The ksysmgr displays the member exception error while running the disaster recovery operations.
- Workaround: Run the same operation again for which the ksysmgr has displayed the member exception error.
The storage agent password must not contain any special characters.
For the move operation between sites, in the HADR and HADRHA configuration that has asymmetric (MXN) host group configuration, the KSYS policy manager does not consider the DR-specific drTargetHost attribute that is set for the VMs that are in a HA-specific collocation group policy. Instead, the policy manager selects the most appropriate host for the VMs from the target host list.
In the HADRHA configuration, discovery process internally performs HA-specific and DR-specific discovery. If either of them fails, KSYS indicates as failure as expected. After an unplanned move operation in the HADRHA configuration, if failure occurs during the sync DB (PreDiscovery) process of the discovery operation, the ksysmgr command-line interface does not display the progress details of high availability operations, although the KSYS subsystem performs the required high availability operation.

In the KSYS LPAR, if you upgrade the AIX operating system after upgrading the KSYS software, a few class IDs might be missing in the /usr/sbin/rsct/cfg/ct_class_ids file and the KSYS daemon might stop working.

Workaround: Run the following command to check whether the class IDs are reserved.

cat /usr/sbin/rsct/cfg/ct_class_ids
IBM.VMR_HMC                                     510
IBM.VMR_CEC                                     511
IBM.VMR_LPAR                                    512
IBM.VMR_VIOS                                    513
IBM.VMR_SSP                                     514
IBM.VMR_SITE                                    515
IBM.VMR_SA                                      516
IBM.VMR_DP                                      517
IBM.VMR_DG                                      518
IBM.VMR_KNODE                                   519
IBM.VMR_KCLUSTER                                520
IBM.VMR_HG                                      521
IBM.VMR_APP                                     522
IBM.VMR_CLOUD                                   523
IBM.VMR_DP_CLD                                  524
IBM.VMR_SA_CLD                                  525
IBM.VMR_LPAR_CLD                                526
IBM.VMR_SITE_CLD                                527
IBM.VMR_VMG_CLD                                 528
IBM.VMR_APP_CLD                                 529
IBM.VMR_SITE_PVS                                530
IBM.VMR_WORKSPACE_PVS                           531
IBM.VMR_WG_PVS                                  532
IBM.VMR_LPAR_PVS                                533

If any of the class IDs that are displayed in the preceding screen are missing in your output, add the missing entries in the /usr/sbin/rsct/cfg/ct_class_ids file to restart the VMR services.

For DR, HADR, and HADRHA cluster types, use unique names for each cluster if you are using the same storage for more than one cluster. If you use the same cluster name for more than one cluster, a error might occur when you create a disk group.
For a multi-node KSYS setup, while adding clusters, it is recommended to have the operating system version and the RSCT version to be same 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 to add nodes to the cluster.
Though, all the VIOSes on the backup site are down, the discovery operation completes successfully. Eventually, the move operation fails if all the target VIOSes are down.
The ksysmgr displays a command and its respective output in ksysmgr.consolelog. So, when you run a ksysmgr commands from multiple terminals or console, it displays the command and its output whenever it is executed. So, if the messages are same or similar for the different commands they can viewed by their process ID.
For a multi-node KSYS cluster, the VM Recovery Manager DR Version 1.7 supports only two KSYS nodes, but later versions can support more than two KSYS nodes.

GUI limitations

The VM Recovery Manager DR GUI does not support multiple sessions that are originating from the same computer.
The VM Recovery Manager DR GUI does not support duplicate names for the host group, HMC, host, VIOS, VMs, site, workgroup, and storage agent. If a duplicate name exists in the KSYS configuration, the GUI might encounter an error during the host group creation or while displaying the dashboard data.
The VM Recovery Manager DR GUI refreshes automatically after each topology change (for example, after a move operation or a host migration operation completes). After the refresh operation of VM Recovery Manager DR GUI is complete, the default KSYS dashboard is displayed. You must expand the topology view in the Activity window to view the log information for a specific entity.
Any operation performed by a user from the command-line interface of VM Recovery Manager DR is not displayed in the activity window of the VM Recovery Manager DR GUI.
The VM Recovery Manager DR GUI does not support failover rehearsal for IBM XIV vSCSI disks. Failover rehearsal for IBM XIV vSCSI disks can be performed only by using the command-line interface (CLI) of the VM Recovery Manager DR for Power Systems solution.
GUI reports only show details about operations triggered from GUI. The operations triggered from the command-line interface are not displayed in the GUI reports.
Do not refresh the browser when adding a user, modifying a user, adding a role, and modifying a role.

SCSI reservations

If the virtual machines in the active site are using Small Computer System Interface (SCSI)-2 or SCSI-3 persistent reservations to control access to a shared storage device (for example, if the value of the reserve_policy attribute is set to PR_shared in the AIX® operating system), and a virtual machine is moved to the backup site, all the reservations are lost and policies are set to default reservation policies according to the storage and operating system associated with the virtual machine. It happens because the storage subsystems do not transfer reservations across mirror copies of data. In addition, the host or storage adapter identities, which are part of reservation management, also change across the active site and the backup site during the disaster recovery move operation.

Example: A PowerHA® SystemMirror® cluster is established across a set of virtual machines and disk fencing is enabled on the active site. In this case, PowerHA SystemMirror performs disk fencing by using SCSI-3 persistent reservations. Therefore, in the active site, each virtual machine must have stored its own key for disk fencing. When the VM Recovery Manager DR solution moves these virtual machines to the backup site, all these virtual machines start in the backup site, a cluster is established, reservation is enabled, and the keys are stored back into the storage subsystem.

Date and time of virtual machines

When virtual machines are moved from the active site to the backup site, the date and time in the virtual machine depends on the backup site environment in the following ways:

For POWER7 and POWER8 processor-based systems: If time reference is set up for the system, for example, you set the reference of all virtual machines in the host based on a single source like a Virtual I/O Server (VIOS), and the move operation is performed, the virtual machines acquire the time and date information of the reference VIOS on the target host.
For POWER8 processor-based systems: If simplified remote restart option is enabled for a virtual machine, and the virtual machine is moved to a target POWER8 processor-based system, the virtual machine retains its original time and date value from the active site.

Change of disk names and disk queue depth values

After the disaster recovery operation, the disk names are not sustained on the backup site. In case of replicated disks, the disk identifier changes when the virtual machines are started on the backup site and the disks are renamed based on the disk identifiers. Therefore, disk names are not sustained across sites. However, you can create customized scripts to be run after the disaster recovery operation and the disks can be renamed based on predefined information.

Similarly, as the disk identifier changes during the disaster recovery operation, the disks are added to the backup sites as new disks are plugged in. Therefore, custom queue depth values change on the backup site. The AIX operating system provides a tunable parameter in the chdef command to manage the queue depth as a global policy that works only for EMC storage systems and DS8000® series of storage systems. By using the chdef command, you can set the value of a predefined attribute for the entire AIX environment. Any new disks that are added after you run this command, can inherit the value from the specified global policy. For more information about the chdef command, see the chdef command in the IBM Knowledge Center.

Dependency on VMR daemon

If you stop the VMR daemon (IBM.VMR subsystem) forcefully for some reason and then start it again, the VMR daemon might take up to 2 minutes to become stable and perform any operations depending on the number of hosts and virtual machines in the KSYS configuration settings.

Miscellaneous

If a specific VM profile already exists on the target site, during the DR restart operation, the KSYS subsystem does not restart the specific VM on the target site.
The skip power on feature is supported only for the move operation from the home site to the backup site.
After each manage or unmanage VIOS operation, you must run the discovery operation.
The flex capacity policy for host is ignored.
You cannot add more than 10 scripts to the ksysmgr add notify command.