VMware Site Recovery Manager 8.7 Release Notes

Site Recovery Manager 8.7 \| 18 APR 2023 \| Build 21590800 \| Download Site Recovery Manager Configuration Import/Export Tool 8.7 \| 18 APR 2023 \| Build 21589505 Check for additions and updates to these release notes.

Site Recovery Manager 8.7 | 18 APR 2023 | Build 21590800 | Download

Site Recovery Manager Configuration Import/Export Tool 8.7 | 18 APR 2023 | Build 21589505

Check for additions and updates to these release notes.

What's in the Release Notes

These release notes cover the following topics:

What's New in Site Recovery Manager 8.7
Product Support Notice
Localization
Compatibility
Network Security
Operational Limits for Site Recovery Manager 8.7
Open Source Components
Caveats and Limitations
Known Issues
Known Issues from Previous Releases

What's New in Site Recovery Manager 8.7

VMware Site Recovery Manager 8.7 adds compatibility with VMware vSphere 8.0 Update 1. For more information on interoperability with earlier or later releases of VMware vSphere, see the VMware Product Interoperability Matrices.
Enhancement to Datagrid user interface :
- Display of more object lines per page, based on toggle control. Flexibility in selection of maximum records to be displayed.
- Option to auto fit columns with the data.
- Ability to remember column re-sizing.
Ability to exclude ESXi hosts from registration for vSphere Replication, based on ESXi hosts tags.
Option to retain replica base disk in vSphere Replication reconfigure wizard when excluding a disk from replication.
REST APIs. New REST APIs related to recovery and configuration.

For more information, see the blog.
NVMe VMFS – NVMe-oF provides enhanced performance. The NVMe VMFS support is available with Site Recovery Manager 8.7 release, along with vSphere 8.0 Update 1.
Automatic VM protection updates per current global mapping settings on folder or resource pool relocation.
IP customization improvements:
- Support for IP customization and in-guest custom commands for Linux VMs if the /tmp directory is mounted as noexec.
- Fixed issues with Site Recovery Manager IP customization being skipped for several Linux distributions versions because their IP configuration is not reported for disconnected NICs.
- Start performing Site Recovery Manager IP customization on connected NICs which are attached to isolated recovery networks instead of leaving NICs disconnected during IP customization phase. With this design change Site Recovery Manager addressed the problems with some Linux distributions and IP subnet rules and provides better RTO for Linux VMs with enabled services like networkd-wait-online.service.
The option to start or restart the syslog services through the Site Recovery Manager Appliance Management Interface.
VMware Aria Operations Management Pack for VMware Site Recovery Manager 8.7. For information about the management pack, see VMware Aria Operations Management Pack for VMware Site Recovery Manager 8.7 Release Notes.
VMware Aria Automation Orchestrator Plug-in for VMware Site Recovery Manager 8.7. For information about the new workflows, see VMware Aria Automation Orchestrator Plug-in for VMware Site Recovery Manager 8.7 Release Notes.
Note: For interoperability with earlier or later releases of VMware vSphere, see the Compatibility Matrices for VMware Site Recovery Manager 8.7.
For information about the features of vSphere 8.0 Update 1, see the vSphere 8.0 Update 1 documentation.
For information about the supported databases, see the Compatibility Matrices for VMware Site Recovery Manager 8.7.

Product Support Notice

VMware Site Recovery Manager 8.5 was the last general version that supports storage policy protection groups (SPPGs). You must either remove or migrate your SPPGs to regular array-based replication protection groups before upgrading to Site Recovery Manager 8.7. Site Recovery Manager 8.5.0.5 and later, and Site Recovery Manager 8.6.x have a dedicated Storage Policy Protection Group (SPPG) migration tool that you can use to migrate your SPPGs to regular array-based replication protection groups. See, Migrating Storage Policy Protection Groups to Array-Based Replication Protection Groups to learn how to use the tool.

Localization

VMware Site Recovery Manager 8.7 is available in the following languages:

English
French
German
Italian
Japanese
Korean
Simplified Chinese
Traditional Chinese
Spanish

Compatibility

Site Recovery Manager Compatibility Matrix

Site Recovery Manager 8.7 is compatible with vSphere 7.0 and later, and supports ESXi versions 7.0 and later.

Site Recovery Manager 8.7 requires a supported vCenter Server version on both the protected site and the recovery site.

For interoperability and product compatibility information, including support for guest operating system customization, see the Compatibility Matrices for VMware Site Recovery Manager 8.7.

Compatible Storage Arrays and Storage Replication Adapters

For the current list of supported compatible storage arrays and SRAs, see the Site Recovery Manager Storage Partner Compatibility Guide.

Compatible Virtual Volumes Partner VASA Providers

For the current list of compatible Virtual Volumes Partner VASA providers, see the VMware Compatibility Guide.

VMware vSAN Support

Site Recovery Manager 8.7 can protect virtual machines that reside on VMware vSAN and vSAN Express Storage by using vSphere Replication. vSAN does not require a Storage Replication Adapter (SRA) to work with Site Recovery Manager 8.7.

Installation and Upgrade

For information about installing and upgrading Site Recovery Manager, see Site Recovery Manager Installation and Configuration.

For the supported upgrade paths for Site Recovery Manager, select Upgrade Path and VMware Site Recovery Manager in the VMware Product Interoperability Matrices.

NOTES:

VMware Site Recovery Manager 8.5.x was the last general version that supports storage policy protection groups (SPPGs). You must either remove or migrate your SPPGs to regular array-based replication protection groups before upgrading to Site Recovery Manager 8.7. Site Recovery Manager 8.5.0.5 and 8.6.x has a dedicated Storage Policy Protection Group (SPPG) migration tool that you can use to migrate your SPPGs to regular array-based replication protection groups. See, Migrating Storage Policy Protection Groups to Array-Based Replication Protection Groups to learn how to use the tool.
If the vCenter Server instances on the protected and recovery sites are in Enhanced Linked Mode, they must be direct replication partners. Otherwise, upgrade might fail.

Network Security

Site Recovery Manager requires a management network connection between paired sites. The Site Recovery Manager Server instances on the protected site and on the recovery site must be able to connect to each other. In addition, each Site Recovery Manager instance requires a network connection to the Platform Services Controller and the vCenter Server instances that Site Recovery Manager extends at the remote site. Use a restricted, private network that is not accessible from the Internet for all network traffic between Site Recovery Manager sites. By limiting network connectivity, you limit the potential for certain types of attacks.

For the list of network ports that Site Recovery Manager requires to be open on both sites, see Network Ports for Site Recovery Manager.

Operational Limits for Site Recovery Manager 8.7

For the operational limits of Site Recovery Manager 8.7, see Operational Limits of Site Recovery Manager.

Open Source Components

The copyright statements and licenses applicable to the open source software components distributed in Site Recovery Manager 8.7 are available at VMware Site Recovery Manager Downloads. You can also download the source files for any GPL, LGPL, or similar licenses that require the source code or modifications to the source code to be made available for the most recent generally available release of Site Recovery Manager.

Caveats and Limitations

Site Recovery Manager does not support the protection of virtual machines using persistent memory (PMem) devices.
When exporting history reports in HTML format, the custom per virtual machine commands are missing from the report. To see the custom per virtual machine commands, export the history reports in XML format.
In a federated environment with linked vCenter Server instances, when you log in to the REST API gateway local site this will automatically log you in to the remote site. You do not have to make a POST /remote-session request. It is not possible to log in to the remote site with a different user name.
The protection and recovery of encrypted virtual machines with vSphere Replication requires VMware vSphere 7.0 Update 2c or later.
When a linked clone virtual machine is created, some of its disks continue to use the base virtual machine disks. If you use vVols replication, you must replicate the linked clone virtual machine on the same replication group as the base virtual machine, otherwise you get the following error message: "Virtual machine '{vmName}' is replicated by multiple replication groups." If you have to replicate the base virtual machine in a different replication group than the linked clone virtual machines, or the base virtual machine cannot be replicated at all, the linked clone virtual machines must be converted to full clones.
Site Recovery Manager does not support Virtual Volumes replication of unattached disks which are present only in a snapshot.
Site Recovery Manager does not currently support NetApp Cloud Volumes Service for Google Cloud VMware Engine neither as source nor as target for a replication.
VMware Site Recovery Manager does not currently support AVS ANF for NetApp ONTAP NFS storage neither as source nor as target for a replication.
The VMware Site Recovery Manager 8.7 Configuration Import/Export Tool Importing attempts to import the recovery settings of protected virtual machines only once no matter whether the protected virtual machines are part of one or many recovery plans.
vSphere Flash Read Cache is disabled on virtual machines after recovery and the reservation is set to zero. Before performing a recovery on a virtual machine that is configured to use vSphere Flash Read Cache, take a note of the virtual machine's cache reservation from the vSphere Web Client. You can reconfigure vSphere Flash Read Cache on the virtual machine after the recovery.
Site Recovery Manager 8.7 supports the protection of virtual machines with uni-processor vSphere FT, but deactivates uni-processor vSphere FT on the virtual machines on the recovery site after a recovery.
- If you use uni-processor vSphere FT on virtual machines, you must configure the virtual machines on the protected site so that Site Recovery Manager can deactivate vSphere FT after a recovery. For information about how to configure virtual machines for uni-processor vSphere FT on the protected site, see https://kb.vmware.com/kb/2109813.
Site Recovery Manager 8.7 supports vSphere Replication 8.7 with vSphere Virtual Volumes with the following limitations.
- You cannot use vSphere Replications Point-in-Time Snapshots with virtual machines where the replication target is a Virtual Volumes datastore.
- When using vSphere Virtual Volumes storage as a replication target all disks belonging to the virtual machine must be replicated to a single vSphere Virtual Volumes datastore.
- When a replicated virtual machine is located on vSphere Virtual Volumes storage, all disks belonging to that virtual machine must be located on a single vSphere Virtual Volumes datastore.
Site Recovery Manager 8.7 does not support NFSv4.1 datastores for array-based replication. You can use Site Recovery Manager 8.7 with NFSv4.1 datastores for vSphere Replication.
To use Two-factor authentication with RSA SecureID or Smart Card (Common Access Card) authentication your environment must meet the following requirements:
1. Use the administrator credentials of your vCenter Server to install Site Recovery Manager 8.7 and to pair your Site Recovery Manager 8.7 sites.
2. The vCenter Server instances on both Site Recovery Manager 8.7 sites must work in Enhanced Linked Mode. To prevent failures during upgrade of Site Recovery Manager from 8.7 to a newer version of Site Recovery Manager, the vCenter Server instances on both sites must be direct replication partners.

Known Issues

New - Site Recovery Manager alarms are not visible in the alarm definitions

Site Recovery Manager events might not be visible when adding an alarm definition in vCenter Server 8.0 and vCenter Server 8.0 Update 1.

Workaround: Upgrade your vCenter Server instance to vCenter Server 8.0 Update 2.
New - Site Recovery Manager REST API GET returns "Config service not found error"
Some of the endpoints in the Site Recovery Manager REST API v2 proxy the request to a specified path and port. Currently the port value is hard-coded to port 5480 which causes the following error: {"error_code":"2.13.2","message":"Config service not found."}

The affected endpoints are:
- [GET] Download Support Bundle
- [GET] Download SRA Configuration
- [POST] Upload SRA Configuration
- [POST] Copy SRA Configuration
- [POST] Reset SRA Configuration
- [POST] Reload SRA Configuration
- [POST] Create SRA
Workaround:
1. Log in to the Site Recovery Manager appliance virtual machine.
2. Create a backup of the file /opt/vmware/dr-rest/webapps/rest/WEB-INF/web.xml.
3. Edit the file /opt/vmware/dr-rest/webapps/rest/WEB-INF/web.xml and search for the term "/sra/load". Locate the filter called "UploadSRAProxyFilter" and remove the following section:
```
<init-param>
<param-name>proxy_port</param-name>
<param-value>5480</param-value>
</init-param>
```
4. Restart the dr-rest service by using the following command systemctl restart dr-rest.
New - Creating a site pair from Site Recovery Manager 8.6 to Site Recovery Manager 8.7 fails with an error

When you attempt to create a new site pair from a site with Site Recovery Manager 8.6 to a site with Site Recovery Manager 8.7, the operation fails with the following error. "Failed trying to retrieve token:..."

Workaround 1: Create a site pair from the site with Site Recovery Manager 8.7.

Workaround 2: Upgrade the site with Site Recovery Manager 8.6 to Site Recovery Manager 8.6.0.1.
New - Site Recovery Manager status is Not Connected after upgrading Site Recovery Manager in a shared recovery vCenter Server topology

After performing an upgrade of Site Recovery Manager 8.5.x or 8.6.x to Site Recovery Manager 8.7, you might observe a Not connected remote SRM status in the Site Recovery UI Summary tab with the following error. "SRM Server cannot connect to vCenter Server at '<vc-address>:443/sdk'. Permission to perform this operation was denied." This might happen when the remote vCenter Server has multiple Site Recovery Manager instances installed on it and you use it as a shared recovery site.

Workaround: Use the Site Recovery user interface to reconnect the Site Recovery Manager pair.
New - The OS stops the Site Recovery Manager server process

The Site Recovery Manager server is overloaded with notifications from the vSphere Replication Management server and exhausts the appliance memory. As a result the appliance OS stops the Site Recovery Manager server process.

Workaround: Restart the vSphere Replication Management server service and then restart the Site Recovery Manager service.
New - Upgrade might not complete successfully and just restarts the appliance

When uprgading Site Recovery Manager, the procedure might not complete successfully and just restart the appliance. As a result the appliance version remains the same. There might be some leftover internal folders from a previous upgrade procedure that impact the current upgrade.
Workaround:
1. Log in to the appliance and use the following command to delete the leftover job folders. rm -rf /opt/vmware/var/lib/vami/update/data/job/*
2. Re-run the upgrade.
New - Reprotect fails with an error "Unable to reverse replication for the virtual machine ...The operation is not allowed in the current state"

In large-scale environments with lots of datastore modification operations, reprotect might fail due to overloaded OSFS module of vSAN.

Workaround: Verify that there are no inaccessible virtual machines. See Virtual Machine Appears as Noncompliant, Inaccessible or Orphaned in vSAN.
New - When a virtual machine is on a vSAN datastore and is replicated by vSphere Replication with NSX-T present, it takes additional 60 seconds to recover when migrating back to the protected site after being recovered on the recovery site

The NSX-T is storing port configuration inside the VM directory, which is not replicated by vSphere Replication. When the VM is migrated to the recovery site, the port configuration becomes invalid and is removed. Migrating the VM back to the protected site and resolving the removed port configuration causes a 60 second per VM delay when registering it in the vCenter Server inventory.

Workaround: None.
New - Planned migration after reprotect fails during vSphere Replication synchronization with an error

During reprotect of large scale VMs, the VMware Crypto Manager module that takes care of the encryption keys on the hosts looses track of some of the encryption keys. As a result the planned migration cannot complete successfully and fails with the following error.

"An encryption key is required."

Workaround 1: Use the following PowerCLI cmdlet to unlock all locked virtual machines in the vCenter Server instance.

Get-VM|Where-Object {$_.ExtensionData.Runtime.CryptoState -eq 'locked'} | Unlock-VM

Workaround 2: In the vSphere UI, navigate to the Summary tab of the virtual machine and click Issues and Alarms > Virtual Machine Locked Alarm > Actions > Unlock VM.
New - Disaster recovery with stretched storage freezes during the 'Change recovery site storage to writable' step

When using Pure Storage storage arrays with unified configuration for stretched storage, if Site Recovery Manager on the protected site loses connection but the vCenter Server remains accessible, disaster recovery freezes during the 'Change recovery site storage to writable' step. This is related to the way Pure Storage SRA commands operate.

Workaround: Navigate to the protected site and power off the virtual machines you are trying to recover. This unblocks the disaster recovery operation and all virtual machnies are successfully recovered.

Known Issues from Previous Releases

For additional information, see the Troubleshooting Site Recovery Manager chapter in the Site Recovery Manager Administration guide.

A CD/DVD device is not connected after the recovery of a Virtual Volumes protected VM, when the device points to an image file on a datastore

When a virtual machine with a CD/DVD device pointing to an image file on a datastore is recovered, you receive the following error "Connection control operation failed for disk 'sata0:0'." and the device is not connected.

Workaround: Recreate the device pointing to the desired image file.
Site Recovery Manager workflow fails with a NotAuthenticated error

Every 8 hours, there is a 0-60 seconds time period when a remote operation might wrongly fail with a NotAuthenticated error. When running a Site Recovery Manager workflow, for example, Reprotect or Failover, if you hit that time window, the workflow might fail with a NotAuthenticated error. Although all connections are up when you start the workflow, the active login token might expire during the execution of the workflow, causing the error.

Workaround: Re-run the workflow.
Changing the value of the recovery.powerOnTimeout settings does not change the actual timeout

When you attempt to change the value of the recovery.powerOnTimeout advanced setting, the changes do not take effect.
Workaround:
1. In the vSphere Client, click Site Recovery > Open Site Recovery.
2. On the Site Recovery home tab, select a site pair, and click View Details.
3. In the left pane, click Configure > Advanced Settings > Replication.
4. Click Edit and set replication.archiveRecoverySettingsLifetime to 0.
5. Repeat the steps on the other site.
6. In the left pane, click Configure > Advanced Settings > Recovery.
7. Click Edit and set recovery.powerOnTimeout to the required value.
8. Repeat the step on the other site.
Two similar items for VMware Site Recovery integration plug-in are visible in the vCenter Server Client Plug-ins list

When you install vSphere Replication or Site Recovery Manager on vCenter Server 8.0, the vCenter Server Client Plug-ins list contains two similar items for the VMware Site Recovery integration plug-in. This does not affect the plug-in functionality as long as both plug-ins are activated or deactivated.

Workaround: No actions are required to continue to use the plug-in functionality. If you must deactivate the plug-in, deactivate both plug-ins. If you want to activate the plug-in, activate both plug-ins.
Disaster recovery fails with an error

Disaster recovery for virtual machines residing on stretched storage fails with the following error: "A general system error occurred: Cannot allocate memory"

Workaround: Re-run the disaster recovery operation.
Recovery plan in a Recovery incomplete state cannot be successfully completed

If a failover with vMotion is interrupted during the vMotion step and the plan goes into Recovery interrupted state, all the following plan re-runs might fail at the Change recovery site storage to writable step. The error at this step is incorrect and Failover is successfully completed. However, the plan stays in Recovery incomplete state and cannot be switched back to Ready state because of this.

Workaround: To successfully failback VMs to the primary site, recreate the Protection Groups and the Recovery Plan.
Reprotect fails with an error

When you are replicating virtual machines at a large scale, reprotect might fail with the following error: "Unable to reverse replication for the virtual machine A generic error occurred in the vSphere Replication Management Server "java.net.SocketTimeoutException: Read timed out"
Workaround:
1. Navigate to the /opt/vmware/hms/conf/hms-configuration.xml file.
2. Increase the value of hms-default-vlsi-client-timeout to 15 minutes on both sites.
3. Restart the HMS services.
Recovery plan with a vSphere Replication replicated virtual machine fails with an error

If the vSphere Replication replicated virtual machine with MPITs has several replicated disks on several different datastores and you stop the replication of one disk and detach it from the protection group, the failover will fail with the following error "Invalid configuration for device '0'".

Workaround: Do not stop the replication of one of the disks and do not detach the disk from the protection group.
Reprotect operation for a large scale of VMs fails with an error

When you try to perform a reprotect operation for a large scale of VMs, the process might fail with one of the following erros:

Unable to reverse replication for the virtual machine <VM_name>

or

A general system error occurred: Failed to open virtual disk

These problems might be observed due to temporary storage overload or network issues.

Workaround: Retry the reprotect operation for these VMs.
After performing disaster recovery and then powering on the same site some virtual machines go into orphaned state

When powering on the down site after performing a Disaster Recovery in a Stretched Storage environment, some virtual machines might appear in an orphan state. The problem is observed for virtual machine protection groups in a Stretched Storage environment.

Workaround: Remove the entries for all orphaned virtual machines from the vCenter Server inventory before running other Site Recovery Manager workflows.
When a replicated disk is on Virtual Volumes storage and is resized, the disk is recovered as Thin Provisioned regardless of original disk type

The internal working of the disk resize operation involves making a copy of the disk, which due to the specifics of Virtual Volumes storage defaults to Thin Provisioned disk type regardless of the base disk type. The disk resize is completed but the resulting resized disk now has the Thin Provisioned type when recovered by vSphere Replication.

Workaround: If required, you can change the disk type manually after recovery.
One or more replications go into Error (RPO violations) state after reprotect operation

After you perform a reprotect operation, one or more of the replications go into error state with the following error:

A problem occurred with the storage on datastore path '[<datastore-name>] <datastore-path>/hbrdisk.RDID-<disk-UUID>.vmdk
Workaround:
1. Remove the replication
2. Configure the replication again, using seed disks.
The Configure Replication wizard starts lagging

If you are using a Mozilla Firefox browser on an Apple Mac OS, you might experience UI performance degradation and lagging in the Configure Replication wizard.

Workaround: Use a Chrome browser.
Reprotect fails with error: Protection Group '{protectionGroupName}' has protected VMs with placeholders which need to be repaired.

When Site Recovery Manager runs a reprotect on the protection group, Site Recovery Manager cannot repair the protected virtual machines nor restore the placeholder virtual machines. The error occurs when the first reprotect operation fails for a virtual machine because the corresponding placeholder operation failed. The protected virtual machine is marked with a configuration error and protection group is left in a partially reprotected state.
Workaround:
1. Rerun reprotect with the force cleanup option enabled. This option completes the reprotect operation and enables the Recreate placeholder option. Note that the reprotect execution will be marked with success status on completion.
2. Explicitly initiate Recreate placeholder operation to repair the affected protected virtual machines and to restore the placeholder virtual machines. Note that if this is not done and you run disaster recovery workflow, the recovery of those virtual machines will fail with the following error Placeholder VM for the protected VM '<vm-name>' is missing.
Some of the recovered virtual machines throw the following alarm 'vSphere HA virtual machine failover failed'

During a Site Recovery Manager workflow, post Test Recovery or Failover operations, some of recovered virtual machines might throw the following alarm: vSphere HA virtual machine failover failed. From Site Recovery Manager perspective, there is no functional impact as all virtual machines are recovered successfully.

Workaround: None. You must acknowledge the alarm.
DNS servers are available in the network configuration of the Site Recovery Manager Appliance Management Interface, even if you selected static DNS without DNS servers

When the requirements of the network settings are for No DNS servers but with automatic DHCP adapter configuration, the setting static DNS and DHCP in the adapter configuration results in DNS servers acquired from DHCP.

Workaround: Use 127.0.0.1 or ::1 in the static DNS servers list, depending on the selected IP protocol.
Reprotect fails when using stretched storage on some storage arrays

The command to reverse the replication on some devices is skipped intentionally when the devices are already in the expected state. As a result the storage array are not getting required notifications and this causes the reprotect operation to fail.
Workaround:
1. Navigate to the vmware-dr.xml file and open it in a text editor.
2. Set the configuration flag storage.forcePrepareAndReverseReplicationForNoopDevices to true.
```
<storage>
<forcePrepareAndReverseReplicationForNoopDevices>true</forcePrepareAndReverseReplicationForNoopDevices>
</storage>
```
3. Save the file and restart the Site Recovery Manager server service.
Exporting grids is not working in the Microsoft Edge browser

When you open a view with a grid, select Export, and click All rows/Selected rows no file is downloaded. When you attempt to export and download the history of a recovery plan, you receive an error in the console and the download files are corrupted.

Workaround: Upgrade to the latest version of the Microsoft Edge browser based on the Chromium engine.
PowerCLI Connect-SrmServer command fails to connect to the Site Recovery Manager appliance using the default port

When you try to connect to the Site Recovery Manager appliance by using the PowerCLI Connect-SrmServer command, the connection fails with the following error: Unable to connect to the remote server.

Workaround: Specify port 443 to the Site Recovery Manager appliance by using the following command Connect-SrmServer -Port 443. For a complete list of all Site Recovery Manager network ports, see Network Ports for Site Recovery Manager.
Devices and Datastores information is missing during the failover of a recovery plan with array-based replication protection groups

When you run a recovery plan failover, depending on the SAN type and whether it detaches the datastore from the host during recovery, the information in the Devices and the Datastores tabs might disappear during the failover process.

Workaround: None. The information in both tabs appears again after a successful reprotect.
Updated - Customization through IP subnet mapping rules is not fully supported for Linux VMs using multiple NICs which are named ethX

Site Recovery Manager does not fully support IP rule-based customization for Linux virtual machines that have multiple NICs, if the NICs have mixed DHCP and static IP settings. Site Recovery Manager customizes only the NICs with static IP addresses for which it has matching IP subnet mapping rule and might clear some configuration settings for the other NICs configured with DHCP. Known issue related to this scenario was observed for Red Hat Enterprise Linux 6.x/7.x and CentOS 6.x/7.x, where Site Recovery Manager customization deletes /etc/sysconfig/network-scripts/ifcfg-ethX files for the NICs configured with DHCP and successfully customizes the rest with static IP settings according to the matched IP subnet mapping rule. This issue also happens when the VM's NICs are all configured with static IP addresses, but some of them have a matching IP subnet rule while others do not. Some configuration settings for those NICs without a matching IP subnet rule might be cleared after IP customization.

Workaround: For correct IP customization for Linux VMs using multiple NICs with some of them having a matching IP subnet mapping rule while the others do not, use the Manual IP Customization Site Recovery Manager option.
The Site Recovery UI becomes unusable showing a constant stream of 403 - OK error message

The Site Recovery UI shows no data and an error 403 - OK.
Workaround:
1. Log out from Site Recovery UI and log in again.
2. Disable the browser's 'Restore last session' checkbox. For Chrome disable the 'Continue where you left off' option.
Datastore cluster that consists of datastores that are not replicated or are from different consistency groups visible to Site Recovery Manager does not have an SRM warning.

You create a datastore cluster that consists of datastoreas that are not all in a same consistency group or are not replicated. A Site Recovery Manager warning should exist but does not.

Workaround: None
Export report from the Recovery Plan History or the Recovery Steps screens does not work when using Microsoft Edge browser

When you try to export the report from the Recovery Plan History or the Recovery Steps screens using MS Edge browser, you get the following error in the dev console.

ERROR XML5610: Quote character expected.

ERROR Error: Invalid argument.

This is a known Microsoft Edge browser issue with XSLTProcessor used to transform server's xml into html.

Workaround: Use Chrome, Microsoft Internet Explorer, or Firefox browser.

This issue is fixed in the Chromium-based version of the Microsoft Edge browser.
When you right-click on a replicated VM and select Reconfigure Replication in the vSphere UI, the pop-up window for the Site Recovey UI is blocked without notification in Mozilla Firefox browser

By default the Site Recovery UI opens in a new tab. When you right-click on a replicated VM and select Reconfigure Replication in the vSphere UI, the pop-up window for the Site Recovey UI is blocked without notification in Mozilla Firefox browser.

Workaround: From the Options menu in Mozilla Firefox, select the Content tab and add the URL of the vCenter Server to the Pop-ups exception list.
The Test and Recovery operations fail if a vSAN stretched cluster has one fault domain that is not available

If you test or recover a VM on a vSAN stretched cluster with one fault domain that is not available, the operation fails. The cause is that the vSAN Default Storage Policy cannot be satisfied and provisioning a VM with Site Recovery Manager on the storage fails.

Workaround: Register the recovered VM on the vSAN stretched cluster manually. The VM becomes compliant with the vSAN Default Storage Policy when the fault domain is available.
Your datastore might appear as inactive in the inventory of the original protected site after reprotect

If you use a stretched storage and run reprotect after a disaster recovery, you might receive the following warning.

The requested object was not found or has already been deleted.

After reprotect, the datastore in the inventory of the original protected site appears as inactive.
Workaround: Refresh or rescan the storage adapters.
1. Click the Configure tab and click Storage Adapters.
2. Click the Refresh or Rescan icon to refresh or rescan all storage adapters.
Recovery of an encrypted VM might fail during the Power On step if the encryption key is not available on the recovery site

If you recover an encrypted VM and the encryption key used on the protected site is not available on the recovery site during the recovery process, the recovery fails when Site Recovery Manager powers on the VM.
Workaround: Complete the following steps.
1. Remove the encrypted VM from the inventory of the recovery site.
2. Ensure that the Key Management Server on the recovery site is available and that the encryption key used on the protected site is available on the recovery site.
3. Register the encrypted VM to the inventory of the recovery site.
4. In the Site Recovery Manager user interface, open the recovery settings of the encrypted VM and disable power on of the VM during recovery.
5. Rerun recovery.
Planned Migration might fail with an error for VMs protected on vSphere Virtual Volumes datastore

If you have VMs protected on vSphere Virtual Volumes datastores, the planned migration of the VMs might fail with the following error on the Change recovery site storage to writable step.

Error - Storage policy change failure: The vSphere Virtual Volumes target encountered a vendor specific error. Invalid virtual machine configuration. A specified parameter was not correct: path.

Workaround: Rerun the recovery plan.
Updated - The IP customization or in-guest callout operations might fail with Error - Failed to authenticate with the guest operating system using the supplied credentials

If the time of the ESXi host where the VM is recovered and running is not synchronized with vCenter Single Sign-On servers on the recovery site you might receive an error.
Workaround:

When recovery.autoDeployGuestAlias option in Advanced Settings is TRUE (default).
- If the guest OS of the recovered VM is Windows, ensure the time synchronization between the ESXi host and vCenter Single Sign-On on the recovery site, and rerun the failed recovery plan.
- If the guest OS of the recovered VM is Linux and the time is ahead from the ESXi host on which the recovered VM is running, update the configuration parameters of the VM by using the following procedure and rerun the failed recovery plan.
  1. Right-click the recovered VM.
  2. Click Edit Settings.
  3. In the Options tab, click General.
  4. Click Configuration to update the configuration parameters.
  5. Click Add Row and enter time.synchronize.tools.startup.backward in the Name text box and TRUE in the Value text box.
  6. Click OK to confirm.
When the recovery.autoDeployGuestAlias option in Advanced Settings is FALSE.
- Ensure proper time synchronization between your guest OS on the protected VM and vCenter Single Sign-On servers on the recovery site.
- Ensure that your protected VMs have correct guest aliases configured for the Solution User on the recovery site SRM server. For more information see, the description of recovery.autoDeployGuestAlias option in Change Recovery Settings.
For more information, see the related troubleshooting sections in the Site Recovery Manager 8.7 Administration guide.
Replacing the SSL certificate of vCenter Server causes certificate validation errors in Site Recovery Manager.

If you replace the SSL certificate on the vCenter Server system, a connection error might occur when Site Recovery Manager attempts to connect to vCenter Server.

Workaround: For information about how to update vCenter Server certificates and allow solutions such as Site Recovery Manager to continue to function, see http://kb.vmware.com/kb/2109074.
Test network mappings are not deleted when the corresponding network mapping is deleted.
If, when you create network mappings, you configure a specific network mapping for testing recovery plans, and if you subsequently delete the main network mapping, the test network mapping is not deleted, even if the recovery site network that you configured is not the target of another mapping. For example:
- You configure a network mapping from Protected_Network_Main on the protected site to Recovery_Network_Main on the recovery site.
- You configure a test network mapping from Recovery_Network_Main to Recovery_Network_Test to use as the network for testing recovery plans.
- Recovery_Network_Main on the recovery site is not used as the target for any other network mappings.
- You delete the network mapping from Protected_Network_Main to Recovery_Network_Main that is used for full recoveries.
- The test network mapping from Recovery_Network_Main to Recovery_Network_Test is not deleted.
Workaround: Delete the test network mapping manually.
Dependency between two virtual machines, one vMotion enabled and one vMotion disabled, on stretched storage fails during a migrating workflow.

Workarounds: Remove dependency between virtual machines and rerun planned migration with vMotion. Manually re-enable dependency for future recovery workflows.

If you want to preserve the dependency between virtual machines, then run planned migration without vMotion. Both virtual machines migrate as regular virtual machines according to the dependency order.
Site Recovery Manager fails to track removal of non-critical virtual machines from the vCenter Server inventory, resulting in MONF errors in recovery, test recovery and test cleanup workflows.

Site Recovery Manager loses connections to the vCenter Servers on the protected and recovery sites and cannot monitor removal of non-critical virtual machines.

Workaround: Restart the Site Recovery Manager server.
Cleanup fails if attempted within 10 minutes after restarting recovery site ESXi hosts from maintenance mode.

The cleanup operation attempts to swap placeholders and relies on the host resilience cache which has a 10 minute refresh period. If you attempt a swap operation on ESXi hosts that have been restarted within the 10 minute window, Site Recovery Manager does not update the information in the Site Recovery Manager host resiliency cache, and the swap operation fails. The cleanup operation also fails.

Workaround: Wait for 10 minutes and attempt cleanup again.
Recovery Fails to Progress After Connection to Protected Site Fails

If the protection site becomes unreachable during a deactivate operation or during RemoteOnlineSync or RemotePostReprotectCleanup, both of which occur during reprotect, then the recovery plan might fail to progress. In such a case, the system waits for the virtual machines or groups that were part of the protection site to complete those interrupted tasks. If this issue occurs during a reprotect operation, you must reconnect the original protection site and restart the recovery plan. If this issue occurs during a recovery, it is sufficient to cancel and restart the recovery plan.
Recovered VMFS volume fails to mount with error: Failed to recover datastore.

This error might occur due to a latency between vCenter, ESXi, and Site Recovery Manager Server.

Workaround: Rerun the recovery plan.
Temporary Loss of vCenter Server Connections Might Create Recovery Problems for Virtual Machines with Raw Disk Mappings
If the connection to the vCenter Server is lost during a recovery, one of the following events might occur:
- The vCenter Server remains unavailable, the recovery fails. To resolve this issue re-establish the connection with the vCenter Server and re-run the recovery.
- In rare cases, the vCenter Server becomes available again and the virtual machine is recovered. In such a case, if the virtual machine has raw disk mappings (RDMs), the RDMs might not be mapped properly. As a result of the failure to properly map RDMs, it might not be possible to power on the virtual machine or errors related to the guest operating system or applications running on the guest operating system might occur.
  - If this is a test recovery, complete a cleanup operation and run the test again.
  - If this is an actual recovery, you must manually attach the correct RDM to the recovered virtual machine.
Refer to the vSphere documentation about editing virtual machine settings for more information on adding raw disk mappings.
Error in recovery plan when shutting down protected virtual machines: Error - Operation timed out: 900 seconds during Shutdown VMs at Protected Site step.

If you use Site Recovery Manager to protect datastores on arrays that support dynamic swap, for example Clariion, running a disaster recovery when the protected site is partially down or running a force recovery can lead to errors when rerunning the recovery plan to complete protected site operations. One such error occurs when the protected site comes back online, but Site Recovery Manager is unable to shut down the protected virtual machines. This error usually occurs when certain arrays make the protected LUNs read-only, making ESXi unable to complete I/O for powered on protected virtual machines.

Workaround: Reboot ESXi hosts on the protected site that are affected by read-only LUNs.
Planned migration fails with Error: Unable to copy the configuration file...

If there are two ESXi hosts in a cluster and one host loses connectivity to the storage, the other host can usually recover replicated virtual machines. In some cases the other host might not recover the virtual machines and recovery fails with the following error: Error: Unable to copy the configuration file...

Workaround: Rerun recovery.
Test cleanup fails with a datastore unmounting error.

Running cleanup after a test recovery can fail with the error Error - Cannot unmount datastore 'datastore_name' from host 'hostname'. The operation is not allowed in the current state.. This problem occurs if the host has already unmounted the datastore before you run the cleanup operation.

Workaround: Rerun the cleanup operation.