VMware Site Recovery Manager 8.5 Virtual Appliance | 05 OCT 2021 | Build 18710731 | Download

VMware Site Recovery Manager 8.5 Configuration Import/Export Tool  | 05 OCT 2021 | Build 18710000 

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 VMware Site Recovery Manager 8.5

Note: For interoperability with earlier or later releases of VMware vSphere, see the Compatibility Matrices for VMware Site Recovery Manager 8.5.

For information about the features of vSphere 7.0 Update 3, see the vSphere 7.0 documentation.

For information about the supported databases, see the Compatibility Matrices for VMware Site Recovery Manager 8.5.

Product Support Notice

NEW VMware Site Recovery Manager 8.5 is the last general version that supports storage policy protection groups (SPPGs).

VMware Site Recovery Manager no longer supports the Windows version of the installer and is available only as an appliance.

Localization

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

  • English
  • French
  • German
  • Japanese
  • Korean
  • Simplified Chinese
  • Traditional Chinese
  • Spanish

Compatibility

VMware Site Recovery Manager Compatibility Matrix

VMware Site Recovery Manager 8.5 is compatible with vSphere 6.7 and later, and supports ESXi versions that vCenter Server 7.0 supports.

VMware Site Recovery Manager 8.5 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.5.

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 vVols Partner VASA Providers

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

VMware vSAN Support

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

Installation and Upgrade

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

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

NOTE:

  • 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.

Migration to the VMware Site Recovery Manager Virtual Appliance

You can migrate your Site Recovery Manager 8.3.x instance from Windows to the Site Recovery Manager 8.3.x virtual appliance and then upgrade to Site Recovery Manager 8.5 Virtual Appliance. For information about the migration procedure, see Migrate from Site Recovery Manager for Windows to Site Recovery Manager Virtual Appliance.

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 VMware Site Recovery Manager 8.5

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

Open Source Components

The copyright statements and licenses applicable to the open source software components distributed in VMware Site Recovery Manager 8.5 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 vCenter Site Recovery Manager.

Caveats and Limitations

  • Site Recovery Manager does not support the protection of virtual machines using persistent memory (PMem) devices.
  • The protection and recovery of encrypted virtual machines with vSphere Replication requires VMware vSphere 6.7 Update 1 or later for 6.7.x based versions and vSphere 7.0 Update 2c or later for 7.0.x based versions.
  • Preservation of vSphere Tags is not supported for storage policy protection groups.
  • 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.
  • The protection and recovery of encrypted virtual machines with VMware Virtual Volumes protection groups requires vSphere 7.0 or later.
  • Site Recovery Manager does not support Virtual Volumes replication of unattached disks which are present only in a snapshot.
  • Site Recovery Manager does not support protection and orchestrated recovery of NVMe over Fabrics (NVMe-oF) datastores. For more information about NVMe storage, see VMware NVMe Concepts in the VMware vSphere 7.0 Documentation.
  • 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.
  • Network auto-mapping for storage policy protection groups is not supported on NSX-T Data Centers.
  • The protection and recovery of encrypted virtual machines with vSphere Replication requires VMware vSphere 6.7 Update 1 or later.
  • The VMware Site Recovery Manager 8.5 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.
  •  VMware Site Recovery Manager 8.5 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.
  •  VMware Site Recovery Manager 8.5 supports vSphere Replication 8.5 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.
  • VMware Site Recovery Manager 8.5 does not support NFSv4.1 datastores for array-based replication. You can use Site Recovery Manager 8.5 with NFSv4.1 datastores for vSphere Replication.
  • VMware Site Recovery Manager does not support reconfiguration of storage profile protection groups, such as changing the set of associated storage policies, group name, or descriptions. To modify a storage profile protection group, you must delete it and recreate it with the new configuration.
  • VMware Site Recovery Manager cannot protect RDM disks or fault-tolerant virtual machines in storage policy protection groups.
  • VMware Site Recovery Manager does not support the mapping or exclusion of nonreplicated virtual devices in storage policy protection groups.
  • 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 Platform Services Controller to install Site Recovery Manager 8.5 and to pair your Site Recovery Manager 8.5 sites.
    2. The vCenter Server instances on both Site Recovery Manager 8.5 sites must work in Enhanced Linked Mode. To prevent failures during upgrade of Site Recovery Manager from 8.5 to a newer version of Site Recovery Manager, the vCenter Server instances on both sites must be direct replication partners.

Known Issues

  • 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.

     

  • 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 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.

  • Exporting Site Recovery Manager configuration by using a remote Site Recovery Manager solution user fails with an error

    In a Site Recovery Manager environment with only array-based replication, when you attempt to export the Site Recovery Manager configuration by using a script without credentials, the export fails. The Impex log contains the following error:

    2022-05-02 04:35:57,061 [srm-reactive-thread-13] ERROR com.vmware.srm.client.impex.Main - Export SRM configuration ended.
    (vim.fault.NoPermission) {
    faultCause = null,
    faultMessage = null,
    object = ManagedObjectReference: type = Folder, value = group-d1, serverGuid = e288c277-4377-4abe-80ad-0e981d64badf,
    privilegeId = StorageProfile.View }

    Workaround 1: Add "policy-driven storage view" to the remote SRM solution user role.
    Workaround 2: Export the Site Recovery Manager configuration by either using a properties file or in interactive mode with credentials. See, Use a Properties File to Export Site Recovery Manager Configuration Data and Export Site Recovery Manager Configuration Data with the Standalone Import/Export Tool. 

  • After performing a Disaster Recovery to the remote site and enabling protection of virtual machines at the remote site, the replication status of the VMs is Not Active

    When you perform a Disaster Recovery of virtual machines to a remote site with multiple clusters and enable the protection of the VMs at the remote site once the primary site is back online, the Replication status of the VMs is Not Active with the following error: 'No connection to VR Server.'

    Workaround:

    1. Establish an SSH connection to the vSphere Replication Appliance.
    2. Modify the lwdSslHandshakeTimeoutSec value in the /etc/vmware/hbrsrv.xml file to 5.
    3. Restart the problematic HBR server.

     

  • After upgrading vCenter Server, you might observe error messages in the Site Recovery UI

    When you open the Site Recovery UI after upgrading your your vCenter Server to version 6.7 Update 3p or version 7.0 Update 3 P04, you might observe the following error message: "User is not logged in. Terminating method execution due to lack of privileges."
    The same error is observed in the dr.log and the HMS logs.

    Workaround: None. Discard the error. 

  • Automatic protection removal for array-based replication protection groups and vVols replication protection groups does not function without the automatic protection advanced setting 

    If you activate only the automatic protection removal advanced settings and the automatic protection settings are deactivated, the automatic protection removal for array-based replication protection groups and vVols replication protection groups does not function.

    Workaround: Activate both the automatic protection advanced settings and the automatic protection removal advanced settings for the protection group type you use.

  • 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.

     

  • Additional NIC does not acquire network configuration and remains in DOWN state

    Configuring the additional network interfaces from the Config Service UI does not change the state of the network interface, and the network interface does not connect to the network.

    Workaround: SSH to the Site Recovery Manager Appliance or the vSphere Replication Appliance and run the following commands:

    1. "ip link" - to locate the required NIC that is in DOWN state. The output will look like this:
      1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
      2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 00:50:56:bc:f4:db brd ff:ff:ff:ff:ff:ff
      3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:50:56:bc:53:2e brd ff:ff:ff:ff:ff:ff
    2. "ip link set dev <name> up" - to set the network interface state to UP.

     

  • 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.

  • Recovery plan execution fails in a stretched storage cluster environment

    When you attempt to perform Planned Migration or Disaster Recovery of a virtual machine protection group in a stretched storage cluster environment without vMotion, the operation might fail during the "Create writable storage snapshot" step for one or more virtual machines. You receive the following error message: "Some virtual machines in the protection group [PGxxx] could not be recovered."

    Workaround: Re-run the Recovery plan.

  • 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.

  • The name of the downloaded file with exported recovery steps is not displayed properly

    If you have a recovery plan with non-ascii characters in the name, when you export the recovery plan steps, the name of the downloaded file is not displayed properly. Site Recovery Manager replaces all non-ascii characters with an underscore sign.

    Workaround: None. Do not use non-ascii characters for the name of the Recovery Plan.

  • After performing a failover, the recovered virtual machine icon shows 3 dots

    If you manually map the protected disk of a virtual machine to another disk or detach the disk in the VM protection properties under the protection group, the recovered VM icon shows 3 dots after performing a failover as if it is still a placeholder VM.

    Workaround: None.

  • The information about the DNS servers in the Networking settings is empty and cannot be edited and saved

    If the Site Recovery Manager appliance is deployed with DCHP and router advertisement settings, the DNS servers are received automatically. If you are using IPv6 and you try to manually setup new DNS servers and save them using the form for Network settings, the data for DNS servers is not saved and the DNS is not set correctly on the Site Recovery Manager instance.

    Workaround: If you want to change the DNS servers settings and continue to use DHCP and router advertisement for the IPv6 addresses, you must uncheck the Use static IPv6 addresses setting in the Network Settings form. The form will then save the new settings correctly.

  • 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.

  • Reprotect operation fails with an error for one VM

    Reprotect operation fails with the following error:

    Unable to reverse replication for the virtual machine '<vm-name>'. A general system error occurred: Fault cause: vim.fault.GenericVmConfigFault

    On the target vCenter Server site, the task for the virtual machine fails with the following details:

    Task Name: Remove all snapshots
    Status: A general system error occurred: Fault cause: vim.fault.GenericVmConfigFault
    Initiator: <initiator>
    Target: <vm-name>
    Server: <VC-name>

    Workaround:

    1. Remove the replication.
    2. Configure the replication again, using seed disks.
  • 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.
  • Test recovery and real recovery of Storage Policy Protection Groups that contain vTA encrypted virtual machines might fail with an error

    When you run a test recovery or real recovery of Storage Policy Protection Groups that contain vTA encrypted virtual machines, the operation might fail with the following error: An encryption key is required.

    Workaround: Re-run the operation. This issue if fixed in vCenter Server 7.0 Update 3.

  • An unexpected error appears in the Summary tab and the Virtual Machines tab of the protection group while reprotect is in progress or shortly after reprotect completes

    If you navigate to either the Summary tab or the Virtual Machines tab while a reprotect operation is in progress, you might observe an unexpected error message: 'The ManagedObjects in 'spec.objectSet' belong to more than 1 server.' or 'Missing value for non-optional field placeholderVmInfo' . If the latter one is opened, you might not see any virtual machines listed.

    Workaround: Discard the error and wait for a while. The virtual machines will reappear in the Protection Group and will be protected and powered on as expected.

  • 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.

  • Virtual machines protected with Site Recovery Manager that are using NVDS for protected and or recovery network have protection issues after NVDS-CVDS migration

    If the protected virtual machines are attached to an NVDS network and you perform NVDS-CVDS migration, after the migration the protected VMs have protection issues. The same applies when performing NVDS-CVDS migration and the network is used for recovery network.

    Workaround: Reconfigure the protection of the affected virtual machines.

  • 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.

     

  • If you use Chromium-based browser and you try to resize a column of a grid, the Site Recovery user interface freezes and becomes unresponsive

    LayoutNG in Chromium is having a bug that causes performance issues. For more information, see https://bugs.chromium.org/p/chromium/issues/detail?id=1008523 and https://bugs.chromium.org/p/chromium/issues/detail?id=1098231.

    Workaround 1: 

    1. Close all Chrome windows.
    2. Edit the Chrome shortcut link and update it to: "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-blink-features=LayoutNG
    3. Open Chrome again.

    Workaround 2: Update your Chrome browser to version 85.0.4183.83 or later.

  • 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.

  • Site Recovery Manager plug-in does not appear in the vCenter Server web client or HTML5 client

    When you install or upgrade to Site Recovery Manager and register it with a vCenter Server version 6.7.x which is installed on a Windows Server, the Site Recovery Manager plug-in does not appear in the vCenter Server web client or HTML5 client.

    Workaround: See https://kb.vmware.com/s/article/78678.

  • Automatic protection of virtual machines created while a test recovery is running is delayed until the test completes and cleaned up

    When you create a virtual machine on a protected datastore while there is a test recovery is running on an array-based protection group, the virtual machine might not be automatically protected if the test recovery process is not cleaned up within 15 minutes after the virtual machine provisioning.

    Workaround 1: To initiate automatic protection, restart the Site Recovery Manager server on the protected site.
    Workaround 2: Use manual protection for virtual machines in a Not configured state after a test recovery.

  • 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.

  • After a successful login in the Single Sign-On, you are unable to login in the Site Recovery user interface

    The Site Recovery user interface log contains the following error message "Certificate for <host> doesn't match any of the subject alternative names: <subjectaltlist>". When you attempt to do a remote login within the Site Recovery user interface by using the remote login dialog, you receive similar error message in the user interface.
    The Site Recovery user interface might not be able to connect to the Platform Services Controller hosts because of the way the host certificate is generated:

    • If the Platform Services Controller certificate does not have a host's address (IP or FQDN) as a subject alternative name;
    • If Platform Services Controller certificate lacks subject alternative names and the host name is not matched in the certificate's CN fields.

    Workaround:

    1. Reconfigure the Platform Services Controller with a certificate with a SAN (Subject Alternative Name Field) that contains an entry for the Platform Services Controller address (the '<host>' string from the error message). 
    2. If the certificate is properly generated, but the address used by user interface is not, you must reconfigure the user interface and the corresponding Site Recovery Manager and vSphere Replication Appliances to use the correct Platform Services Controller address. 
    3. Reconfigure the existing pairings for the appliances.

     

  • 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 arrays are not getting required notifications and this causes the reprotect operation to fail.

    Workaround:

    1. Navigate to the /opt/vmware/srm/conf directory and open the vmware-dr.xml file 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.

     

  • When you attempt to configure IPv6 through the Site Recovery Manager Appliance Management Interface you receive an invalid property - dns error

    When you attempt to configure IPv6 through the Site Recovery Manager Appliance Management Interface and select the 'Obtain IPv6 settings automatically through router advertisement'  option with auto assigned dns, the following error occurs invalid property - dns. 

    Workaround: SSH to the Site Recovery Manager Appliance host machine and run netmgr ip6_address --set --interface --dhcp 0 --autoconf 1 .
    To receive an IP address through DHCP run netmgr ip6_address --set --interface --dhcp 1 --autoconf 1 instead.

  • You cannot reconfigure the IPv6 settings through the Site Recovery Manager Appliance Management Interface

    If you have configured the IPv6 network with the 'Obtain IPv6 settings automatically through router advertisement' or 'Obtain IPv6 settings automatically through DHCP' option, you are unable to reconfigure the IPv6 settings with only 'Obtain IPv6 settings automatically through DHCP'. Either both options must be selected or none of them.

    Workaround: SSH to the Site Recovery Manager Appliance host machine and run netmgr ip6_address --set --interface --dhcp 0 --autoconf 1 .
    To receive an IP address through DHCP run netmgr ip6_address --set --interface --dhcp 1 --autoconf 1 instead.

  • During a test recovery one of the ESXi hosts crashes

    While you are running a test recovery one of the ESXi hosts might crash with PSOD: Assert bora/vmkernel/main/bh.c:981.

    Workaround: Upgrade to vCenter Server 7.0 Update 1 or restart the ESXi host. 

  • Sometimes after starting the Site Recovery Manager virtual appliance, the VMware Console is not visible in the vSphere UI

    There is no blue screen, that shows information about the appliance. All other VMware related services in the Site Recovery Manager appliance are up and running.

    Workaround: Restart the Site Recovery Manager appliance.

  • vSphere Replication appliances are not working correctly after converging vCenter Server instances in Enhanced Linked Mode with external Platform Services Controllers to embedded vCenter Sever instances in Enhanced Linked Mode

    If you have an Enhanced Linked Mode environment with external Platform Services Controllers and you converge it to embedded node, your vSphere Replication appliances might not work correctly.

    Workaround: Re-register the solution user or manually add the solution user to the required groups.

  • 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.

  • When recovering a storage policy protection group, the recovery plan might fail with the following error "Cannot fetch hosts associated with placeholder VMs. Mapping for resourcePool 'XXXXXX' missing in resource mappings." The 'XXXXXX' resourcePool' is a compute resource (host or cluster) that does not contain virtual machines protected by the storage policy protection group.

    The error appears when there is no resource inventory mapping for the compute resource, but some hosts belonging to the same compute resource have mounted some of the datastores protected by the storage policy protection group. By design, storage policy protection groups require existing resource inventory mappings for all such compute resources.

    Workaround 1: Do not remove the compute resource from the vSphere inventory. Create a resource inventory mapping for the mentioned compute resource and re-run the recovery.

    Workaround 2: If you have already removed the compute resource from the vSphere inventory, perform the following steps:

    1. Stop the protection Site Recovery Manager server to make placeholder mappings appear in the Site Recovery user interface, and create a placeholder mapping for the same compute resource.
    2. Re-run the recovery.
    3. After the recovery succeeds, you might still get errors when running reprotect. If the errors persist:
      1. Delete the affected storage policy protection group from Site Recovery Manager.
      2. If Site Recovery Manager reprotect failed to reverse the storage replication, reverse the replication for the affected LUNs by using storage administration tools.
      3. Run Discover Devices on the involved Site Recovery Manager array pair and verify that replication direction for the affected LUNs is correctly detected by Site Recovery Manager.
      4. Recreate the affected storage policy protection group in the reverse direction and add it back to the affected recovery plan.
  • After migrating the Windows Site Recovery Manager server to Site Recovery Manager Virtual Appliance, the srm-server service fails to start

    After a successful migration from Site Recovery Manager for Windows to Site Recovery Manager Virtual Appliance in a federated IPv6 environment, the srm-server service of the virtual appliance fails to start.

    Workaround: Reconfigure the Site Recovery Manager Virtual Appliance through the Site Recovery Manager Appliance Management Interface.

  • When you run a Test Recovery of a recovery plan that contains storage policy protection groups on a stretched storage cluster, you receive a warning 'The name <Datastore_name> already exists'.

    During the Test Recovery operation Site Recovery Manager attempts to rename a test recovered stretched storage devices with the same name as the actual production stretched storage devices that is already mounted. As a result you receive a warning message The name <Datastore_name> already exists.

    Workaround: Ignore the warning. The Site Recovery Manager workflow is not affected by the warning messages. 

  • The planned migration of a storage policy protection group constantly fails with ProtectionGroupNotSynced fault

    The planned migration of a storage policy protection group might fail with a ProtectionGroupNotSynced fault: "The peer site has not finished synchronizing changes to protection group 'SP_protection_group_name'. If this is a planned migration, wait for the peer site to synchronize and then retry the workflow." 

    If you continue to observe this issue after multiple planned migration re-runs, you can disable this check to complete the planned migration process successfully.

    Workaround:

    1. Navigate to the /opt/vmware/srm/conf directory and edit the vmware-dr.xml file for both the protection and the recovery Site Recovery Manager servers with the following additional configuration:
      <replication>
      <failPlannedMigrationIfSitesNotSynced>false</failPlannedMigrationIfSitesNotSynced>
      </replication>
    2. Restart both Site Recovery Manager servers.
    3. Re-run the planned migration of the storage policy protection group.

     

  • When you run Test Recovery on a storage policy protection group with stretched storage, you receive a warning message about possible failure of live migration​

    When you run Test Recovery, you observe a warning message for a virtual machines configured for storage policy protection with stretched storage, the vpxd service restarts, and might create a core dump.

    Workaround: Ignore the warning. The Site Recovery Manager workflow is not affected by the warning messages. This issue is fixed in vCenter Server 6.7 Update 1.

  • Recovery plan execution might fail to power on a virtual machine with 'InvalidArgument:path'

    When you run a recovery plan, Site Recovery Manager might fail to power on a VM with a (vmodl.fault.InvalidArgument:path) error. The following error message appears in the Site Recovery Manager recovery site server logs:

    YYYY-MM-DDT20:24:35.996-08:00 error vmware-dr[02448] [SRM@6876 sub=Recovery ...] Plan execution (test workflow) failed; 
plan id: 34f86036-3bc7-4c2d-a841-e15c5d781532, plan name: HBRRP_LIMITS, error: (vmodl.fault.InvalidArgument) {
-->    faultCause = (vmodl.MethodFault) null, 
-->    faultMessage = <unset>, 
-->    invalidProperty = "path"
-->    msg = "A specified parameter was not correct: path"
--> }
-->

    This error is a result of a failing 'Relocating VM before powered on' operation on the target destination ESXi host. The related error message in the ESXi vpxa service logs is:

    YYYY-MM-DDT03:56:48.255Z error vpxa[2099931] [Originator@6876 sub=vpxaVmprov opID=failedOpId] 
Failed to canonicalize vm register path; 
/vmfs/volumes/.../recoveredVm.vmx, err: 16(Device or resource busy)
...
YYYY-MM-DDT03:56:48.256Z info vpxa[2099931] [Originator@6876 sub=Default opID=failedOpId] 
[VpxLRO] -- ERROR task-1824 -- vpxa -- vpxapi.VpxaService.registerVm: vmodl.fault.InvalidArgument:
--> Result:
--> (vmodl.fault.InvalidArgument) {
-->    faultCause = (vmodl.MethodFault) null,
-->    faultMessage = <unset>,
-->    invalidProperty = "path"

     

    Workaround: Re-run the failed recovery plan.

  • 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.

  • Reprotect fails with Internal error: Received unexpected exception during prepare phase. The session is not authenticated

    When you run reprotect, the operation fails with the following error.
    Internal error: Received unexpected exception during prepare phase. The session is not authenticated.

    Workaround: Re-run the reprotect operation.

  • If the source VM for a replication runs on ESXi 6.7, replication synchronization seems to progress, but the replication instance never completes successfully

    In ESXi 6.7, it is possible that more demand log chunks be scheduled for parallel transfer than the actual number that can be transmitted. If you are replicating a VM that is running on such a host and this coincides with a slow target host or temporary network errors, this might result in replication failure with DiskQueue is full errors.

    Workaround:
    1. Migrate all the VMs to another ESXi host.
    2. Edit the value of the HBR.DemandlogTransferMaxNetwork ESXi Advanced setting to 63 instead of the default 64.
    3. Place the ESXi host in maintenance mode.
    4. Reboot the ESXi host.

    This issue is fixed in vCenter Server 6.7 Update 3.

  • If the source VM for a replication runs on ESXi 6.7 or ESXi 6.7 Update 1, an initial or full synchronization might stop progressing before completion

    If you are using vSphere Replication and you are running a protected VM on ESXi 6.7 or ESXi 6.7 Update 1, an initial or full synchronization of replications might stop progressing before completion. The synchronization of replications remains in progress, but the checksum bytes value in the replication details information does not progress. The power off, take a snapshot, revert to snapshot, and migration VM operations fail with a timeout or Task in progress errors.

    Workaround:
    1. In the ESXi Advanced settings, disable the checksum for vSphere Replication by setting HBR.ChecksumUseChecksumInfo = 0.
    2. Migrate all VMs and power off the ones that cannot be migrated on the ESXi host.
    3. Place the host in maintenance mode.
    4. Reboot the ESXi host.
    Note: This workaround disables the checksum part of the sync process and all of the allocated blocks will be sent to the remote site, regardless of whether they are different or not. This workaround disables the seed functionality.

    This issue is fixed in vCenter Server 6.7 Update 2.

  • Site Recovery Manager might create dummy networks from the protection vCenter Server on the recovery vCenter Server when the network names are different form the recovery ones

    When you have protected VMs attached to networks with network labels different from the ones that exist on the recovery site, during Test\Recovery\Reprotect the operations succeed, but dummy networks with same network labels from protected site might be created on the recovery vCenter Server. Dummy networks are created only once, not every time you execute the Test\Recovery\Reprotect.

    Workaround 1: Disable the preservation of VM snapshots by changing the value of vrReplication.preserveMpitImagesAsSnapshots in the Site Recovery Manager advanced settings.
    Workaround 2: Discard the dummy network and continue working with Site Recovery Manager.

  • VMware Site Recovery Manager Configuration Import/Export Tool might error out when you import a configuration with protected VMs in no recovery plans

    If you put protected virtual machines in recovery plans, then delete all recovery plans containing these VMs, and export your configuration with the VMware Site Recovery Manager Configuration Import/Export Tool, the VM recovery settings for those VMs are exported but you are unable to import them later. If you try to import your settings, you see errors like:
    Error while importing VM settings for server with guid '6f81a31e-32e0-4d35-b329-783933b50868'.
    The rest of your exported configuration is properly imported.

    Workaround: Recreate your recovery plan, reconfigure the desired recovery settings, and export your configuration again. Do not delete recovery plans if you want to export and import VM recovery settings.

  •  Virtual machines protected in a Storage Profile Protection Groups are not listed in the CSV file created when running the DR IP Customizer tool.

    When you use the DR IP Customizer tool in a multiple vCenter Server environment, for example setup with federated PSCs where more then one vCenter Server instance is available on each site, you must specify the option '--vcid UUID' to be used to gather networking information about the virtual machines protected by Site Recovery Manager. If you provide the secondary site vcid, the DR IP Customizer tool connects to the secondary Site Recovery Manager server which does not store the network information for VMs protected with SPPGs. Providing the vcid from the secondary site results in connecting to the wrong vCenter Server and the VMs are not listed in the generated CSV file.

    Workaround: When using the DR IP Customizer tool, provide only the primary vCenter Server vcid and uri.

  • 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.

  • IP customization fails when you use special characters in the Recovery Plan name

    When you run a Test Recovery for a Recovery Plan with special characters in the name and configured IP customization, the IP customization fails.

    Workaround: Remove any OS-specific special symbols from the Recovery Plan name.

  • If the protected vCenter Server is down, you might experience performance degradation in the HTML 5 user interface on the recovery site, especially in the Configure Recovery Settings dialog.

    You might experience performance degradation in the HTML 5 user interface on the recovery site, especially in the Configure Recovery Settings dialog, if the protected vCenter Server is down.

    Workaround: Refresh the HTML 5 user interface on the recovery site and re-try your operation.

  • Site Recovery Manager privileges are not localized in the vSphere 6.7 Client

    Site Recovery Manager privileges are not localized in the vSphere 6.7 Client.

    Workaround: None. The issue is resolved in vSphere 6.7 Update 1.

  • 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

  • After you perform a failover, the virtual machine NICs at the disaster recovery site might remain disconnected

    When you re-run a failover after an IP customization failure, the NICs of the VM on which the customization failed during the previous run might remain disconnected even after a successful customization in the current failover.

    Workaround: None. Manually reconnect the NICs by reconfiguring the VM devices.

  • 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. 

  • Site Recovery Manager Server might crash if you re-enable recovery of a VM

    You can disable recovery of a VM if the recovery operation for the VM fails. If you run a recovery plan and the recovery fails, you can re-enable the recovery of the VM and rerun the recovery, but Site Recovery Manager Server crashes.

    Workaround: Start Site Recovery Manager Server and disable the recovery of the VM.

  • 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.
  • A VM and a consistency group assigned to a deleted storage policy appear in the Virtual Machines and Consistency Groups tabs

    If you delete a storage policy, the VMs and the consistency group that are assigned to the storage policy appear in the Virtual Machines and Consistency Groups tabs to the SPPG group.

    Workaround: Recreate the storage policy protection group. After you recreate the group the VMs and consistency group do not appear in the Virtual Machines and Consistency Groups tabs.

  • 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.

  • 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.5 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.

  • Disaster recovery for a VM that is attached to a VSS network shows the protected site network in the UI for temporary placeholder network mappings.

    If you use a VSS network for which you have not configured a regular network mapping and you run disaster recovery on a recovery plan that contains a storage policy protection group, Site Recovery Manager creates a temporary placeholder mapping for this network. When you complete the temporary placeholder mapping, a network might appear on the secondary site that has the same name as the network on the primary site. If you did not explicitly create this network, it is not a genuine network. However, it is possible to select it as the target for the temporary placeholder mapping and recovery will succeed. The network is then displayed as inaccessible after the recovery completes, even though the recovered VMs are shown as being connected to this network on the recovery site.

    Workaround: After the recovery, manually map the VMs to a different network and connect them to a genuine network.

  • 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.

  • When you edit a temporary placeholder mapping, you might see error The specified key, name, or identifier '6458aed1-6c80-4565-907f-189e6a102046' already exists.

    This error can occur when a regular mapping for the same protected site inventory object exists.

    Workaround: None. You can ignore the error as regular mappings take priority over placeholder mappings. The regular mapping will be used at recovery time as expected.

  • Site Recovery Manager displays incorrect names for some protected site objects in placeholder mappings.
    • Datacenters display the name vm instead of the user-defined datacenter name.
    • Resource pools display the name Resources instead of the user-defined resource pool name.
    • If you move a virtual machine to another folder or resource pool after protecting the virtual machine in a storage profile protection group, the placeholder mappings generated after the move display internal IDs such as folder-3 or resgroup-5 instead of the user-defined object names.

    Workaround: There is no workaround for incorrect object names in inventory mappings. Check the history report from the failed test or recovery workflow that caused the placeholder mappings to be created. For example, if you know the protected site inventory, you can determine the protected site datacenter, folder, and resource pool that contained the protected virtual machine that failed to recover due to a missing mapping.

  • After the recovery plan workflow completes, the last recovery steps continue to show a "Running" status.

    The incorrect status is a transient UI problem. Site Recovery Manager executes all the steps to completion.

    Workaround: Click the global refresh icon to refresh the interface. All steps display the correct completed status.

  • Prompts and commands disappear from the list of steps in recovery view.

    After you add a prompt or command in Recovery Steps > Recovery View, you can see the same prompt or command in test view. However if you try to edit a prompt or command in test view, the prompt or command specific to the recovery view might disappear from the list of steps.

    Disappearing prompts or commands is a transient UI problem that affects only the detailed list of recovery steps. Site Recovery Manager executes all prompts and commands when you run a test or recovery even if they do not appear in the detailed list of steps.

    Workaround: Click the global refresh icon to refresh the interface. All callouts reappear in the list of steps.

  • When the storage array fails at the protected site, Site Recovery Manager cannot recover virtual machines in storage profile protection groups.

    The virtual machines become unprotected but the data is still protected.

    Workaround: Manually recover the datastores and virtual machines at the recovery site.

  • The placeholder virtual machine on the recovery site still exists after you delete the protection group and recovery plan.

    When you delete the recovery plan and protection group from the SRM inventory, the placeholder VM is still visible on the recovery site. An error occurs when you try to create a new protection group with the same datastore and virtual machine. When you try to manually delete the placeholder virtual machine from the vCenter Server inventory, an error occurs. Site Recovery Manager marks the virtual machine as orphaned.

    Workaround: Delete the placeholder virtual machine and remove the orphaned virtual machine, then create the protection group with the same virtual machine.

  • 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.

  • Cancellation of Recovery Plan Not Completed

    When a recovery plan is run, an attempt is made to synchronize virtual machines. It is possible to cancel the recovery plan, but attempts to cancel the recovery plan run do not complete until the synchronization either completes or expires. The default expiration is 60 minutes. The following options can be used to complete cancellation of the recovery plan:

    • Pause vSphere Replication, causing synchronization to fail. After recovery enters an error state, use the vSphere Client to restart vSphere Replication in the vSphere Replication tab. After replication is restarted, the recovery plan can be run again, if desired.
    • Wait for synchronization to complete or time out. This might take considerable time, but does eventually finish. After synchronization finishes or expires, cancellation of the recovery plan continues.

  • 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.

  • When you remove permission for a user on a protected site while logged in as that user, the following error message appears: Unable to retrieve Permissions data. The session is already logged in. A similar error appears on the Advanced Settings tab.

    This error appears when you remove your own permissions at the site level. Instead, the message should inform you that you do not have permissions to view the page.

  • Running a recovery plan fails with a virtual machine error in the Configure Storage step.

    Subsequent runs of the recovery plan fail at the same Configure Storage step for the same virtual machine with the error The specified key, name, or identifier already exists.. If you look in the vCenter Server Inventory, you see two virtual machines with the same name as the failed virtual machine, one of which is in the Discovered Virtual Machines folder. This problem is caused by a known communication issue between vCenter Server and the ESXi Server instance.

    Workaround: Unregister the duplicate virtual machine in the Discovered Virtual Machines folder from vCenter Server. After completing this for all affected virtual machines, re-run the recovery plan.
    This issue is fixed in vCenter Server 6.7

check-circle-line exclamation-circle-line close-line
Scroll to top icon