check-circle-line exclamation-circle-line close-line

VMware Site Recovery Release Notes

VMware Site Recovery | 16 NOV 2017 

VMware Site Recovery Manager 8.1.0.4 | 24 AUG 2018 | Build 9569154 | Release Notes

VMware vSphere Replication 8.1.0.4 | 24 AUG 2018 | Build 9466424  | Release Notes

VMware Site Recovery Manager 8.1.0.3 | 12 JUN 2018 | Build 8738384 | Release Notes

VMware vSphere Replication 8.1.0.3 | 12 JUN 2018 | Build 8744176  | Release Notes

VMware Site Recovery Manager 8.1.0.2 | 18 MAY 2018 | Build 8527244 | Release Notes

VMware vSphere Replication 8.1.0.2 | 18 MAY 2018 | Build 8539865  | Release Notes

VMware Site Recovery Manager 8.0 | 16 NOV 2017 | Build 7111331

VMware vSphere Replication 8.0 | 16 NOV 2017 | Build 7137567

Check for additions and updates to these release notes.

What's in the Release Notes

The release notes cover the following topics:

 

What's New November 2, 2018

  • Support for NSX-T

VMware Site Recovery™ now supports protecting to or from VMware Cloud™ on AWS SDDCs based on NSX-T, giving users more flexibility and control over their networking configuration for their disaster recovery needs.

What's New October 22, 2018

  • Fan-out topology improvements - Activate DR with custom SRM extension ID 

VMware Site Recovery can now be activated on a VMware Cloud on AWS SDDC with a custom extension ID which allows you to pair this instance with an on-premises Site Recovery Manager installation using a custom plug-in identifier or a VMware Site Recovery instance on another VMware Cloud on AWS SDDC deployed with the same custom extension ID. This makes it easier to incrementally implement fan-out disaster recovery topologies. For example, if you already have an on-premises Site Recovery Manager installation deployed with the default plug-in identifier and paired with another on-premises Site Recovery Manager instance or with another VMware Cloud SDDC, you can now install a second on-premises Site Recovery Manager in the same vCenter Server instance with a non-default custom plug-in identifier and pair it to a newly deployed VMware Site Recovery instance activated with the same custom extension ID.

What's New September 6, 2018

  • New region: Asia Pacific (Sydney)

VMware Site Recovery™ now supports activation on Software Defined Data Centers (SDDCs) provisioned in the Asia Pacific (Sydney) region of VMware Cloud™ on AWS.

  • Optimize resource management of your DR cluster after failover, by automating cluster scaling with Elastic DRS.

You can now automate cluster scaling with Elastic Distributed Resource Scheduler (DRS). The Elastic (DRS) automatically scales the number of hosts up or down in an SDDC cluster based on CPU, memory, and storage utilization.

 

What's New May 17, 2018

  • New region: EU (Frankfurt)

VMware Site Recovery™ now supports activation on Software Defined Data Centers (SDDCs) provisioned in the EU (Frankfurt) region of VMware Cloud™ on AWS.

  • Multi-site disaster recovery topology support: fan-out from on-premise

Extend your existing on-premises disaster recovery strategy to the cloud by protecting some on-premises workloads to VMware Cloud™ on AWS using VMware Site Recovery™ while simultaneously protecting other workloads managed by the same on-premises vCenter Server to a secondary on-premises disaster recovery site. Multiple instances of Site Recovery Manager 8.1 can be deployed on-premises, with one paired to VMware Cloud™ on AWS for disaster recovery as a service (DRaaS) and others paired to secondary data centers.

  • Replication Seeding

Accelerate time to protection by leveraging previously replicated base disks of virtual machines as the seeds for the new replication. Replication for VMs that have been protected in the past is able to use previously replicated base disks as seeds, instead of requiring an initial full synchronization.​ For more information, see Replicating Virtual Machines Using Replication Seeds in the vSphere Replication 8.1 Administration guide.

  • Backward compatibility with older vCenter Server versions

Simplify DR protection by pairing VMware Site Recovery™ with sites running earlier versions of vCenter Server. Building on previous releases, VMware Site Recovery™ is compatible with multiple versions of vCenter Server, allowing you to protect sites running vCenter Server versions 6.7, 6.5, and 6.0U3.

 

What's New March 7, 2018

  • New region: EU (London)

VMware Site Recovery™ now supports activation on Software Defined Data Centers (SDDCs) provisioned in the EU (London) region of VMware Cloud™ on AWS.

  • Site Recovery Firewall Rules Accelerator

VMware Site Recovery™ now provides a Firewall Rules Accelerator user interface in the VMware Cloud™ on AWS console to streamline the process of creating firewall rules between your on-premises data center and the Management Gateway for disaster recovery purposes. Currently, these firewall rules must be manually created in the Network tab of the SDDC to allow data replication traffic in both directions, communication with the Site Recovery Manager and vSphere Replication management components, and access to the VMware Site Recovery user interface. While you can still follow this manual process to create the rules, now you also have the option of using the Firewall Rules Accelerator to automatically generate the required rules for a remote network that you specify. Rules created through the Firewall Rules Accelerator can be subsequently viewed, edited, and deleted using the Network tab of the SDDC.

About VMware Site Recovery

The VMware Site Recovery™ service expands and simplifies traditional disaster recovery operations by delivering on-demand site protection across a common, vSphere-based operating environment from on-premises to the cloud. The service protects workloads between on-premises datacenters and VMware Cloud™ on AWS, and between different instances of VMware Cloud™ on AWS. Built on top of the enterprise-grade recovery plan automation of VMware Site Recovery Manager and the native hypervisor-based replication capabilities of vSphere Replication, the service provides an end-to-end disaster recovery solution that reduces the requirements for a secondary disaster recovery site, accelerates time-to-protection, and simplifies disaster recovery operations.

Key Features

  • Natively integrated into VMware Cloud™ on AWS
  • Proven Site Recovery Manager orchestration and automation capabilities
  • Recovery plan orchestration delivers aggressive RTO capabilities
  • Non-disruptive testing of disaster recovery plans
  • VM-centric replication for fine-grained control
  • Support for bulk migration of workloads to VMware Cloud on AWS
  • Streamlined HTML 5 user interface
  • Support for multiple vSphere versions on-premises

Localization

VMware Site Recovery is available in the following languages:

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

Compatibility

Site Recovery Manager Compatibility Matrix

Site Recovery Manager 8.1 is compatible with vSphere 6.0 Update 3, vSphere 6.5, vSphere 6.5 Update 1, and vSphere 6.7, and supports ESXi versions that vCenter Server 6.7 supports.

Site Recovery Manager 8.0 is compatible with vSphere 6.0 Update 3, vSphere 6.5, and vSphere 6.5 Update 1, and supports ESXi 6.0U3 and later.

If you use VMware Tools 10.1 and ESXi 6.5 or 6.0U3, ensure the time synchronization between the ESXi host and vCenter Single Sign-On on the recovery site.

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

vSphere Replication Compatibility Matrix

vSphere Replication 8.1 is compatible with vSphere 6.0 Update 3, vSphere 6.5,  vSphere 6.5 Update 1, and vSphere 6.7, and supports ESXi 6.0U3 and later.

vSphere Replication 8.0 is compatible with vSphere 6.0 Update 3, vSphere 6.5, and vSphere 6.5 Update 1, and  supports ESXi 6.0U3 and later.

For interoperability and product compatibility information, including supported guest operating systems and support for guest operating system customization, see the Compatibility Matrices for vSphere Replication 8.0 and the Compatibility Matrices for vSphere Replication 8.1.

Installation

Before you can use VMware Site Recovery™, you must activate the service on VMware Cloud™ on AWS, prepare your on-premises environment, and connect your protected on-premises site with the recovery site on VMware Cloud™ on AWS.

  • Set up your VMware Cloud™ on AWS account. For information about how to create an account, see Create an Account in the VMware Cloud on AWS Getting Started documentation.

  • Deploy a Software-Defined Data Center (SDDC) on VMware Cloud™ on AWS. See Deploy an SDDC from the VMC Console in the VMware Cloud on AWS Getting Started documentation.

  • Activate the VMware Site Recovery™ service. See Activate VMware Site Recovery at the Recovery Site in the VMware Site Recovery Installation and Configuration documentation.

Installing vSphere Replication

Download the vSphere Replication .iso image and mount it. You can deploy the vSphere Replication appliance by using the Deploy OVF wizard in the vSphere Web Client. Navigate to the \bin directory in the .iso image and use the corresponding OVF file:

  1. vSphere_Replication_OVF10.ovf: Use this file to install all vSphere Replication components, including the vSphere Replication Management Server and a vSphere Replication Server.
  2. vSphere_Replication_AddOn_OVF10.ovf: Use this file to install an optional additional vSphere Replication Server.

For more information on installation, see section Install vSphere Replication in the VMware Site Recovery Installation and Configuration.

Installing Site Recovery Manager

For information about installing Site Recovery Manager, see Installing Site Recovery Manager at the Protected Site in the VMware Site Recovery Installation and Configuration.

Caveats and Limitations

VMware Site Recovery

  • Site Recovery Manager 8.0 and vSphere Replication 8.0 do not support co-existence with older versions. Before installing Site Recovery Manager 8.0 and vSphere Replication 8.0, you must uninstall any already existing older versions.
  • Site Recovery Manager server call-out scripts and Pre-Power On Steps on the recovery Site Recovery Manager server on VMware Cloud on AWS are not supported.
  • VMware Site Recovery does not support the protection of a single VMC on AWS SDDC to two different recovery sites.
  • VMware Site Recovery does not support the protection of multiple protected sites to a single VMC on AWS SDDC shared recovery site.
  • Array-based replication is not supported with VMware Cloud on AWS.
  • vSphere Replication self-replication is not supported.
  • Recovery of a single virtual machine without Site Recovery Manager is not supported.
  • Multiple point in time instances are not supported.
  • Replication to a vCloud Director-based cloud is not supported.
  • vSphere Replication charts are not supported.
  • If the Alarms tab is not selected, there is no visible notification for new Site Recovery Manager or vSphere Replication alarms.
  • VMware Site Recovery standalone UI does not display vSphere Replication server tasks, events, and alarms. To check the vSphere Replication server tasks, events, and alarms, go to the vSphere Client.
  • The cloud admin user cannot define, acknowledge or reset alarms in Site Recovery Manager and on the the cloud site vCenter Server.

Site Recovery Manager

  • The following advanced settings are available in the VMware Site Recovery UI, but are not supported in Site Recovery Manager 8.0.
    • Storage Provider
    • ABR Storage Policy
    • Storage
  • 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.0 does not support the protection of virtual machines that are configured with multiple-CPU vSphere Fault Tolerance (FT). Site Recovery Manager 8.0 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 multi-CPU vSphere FT on virtual machines, Site Recovery Manager does not deactivate vSphere FT on the recovered virtual machines and powering on those virtual machines fails. You must manually deactivate vSphere FT on the recovered virtual machines by removing FT properties and running the recovery plan again.
    • 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 http://kb.vmware.com/kb/2109813.
  • Site Recovery Manager 8.0 does not support NFS v 4.1 datastores.
  • 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.0 and to pair your Site Recovery Manager 8.0 sites.
    2. The vCenter Server instances on both Site Recovery Manager 8.0 sites must work in Enhanced Linked Mode. To prevent failures during upgrade of Site Recovery Manager from 8.0 to a newer version of Site Recovery Manager, the vCenter Server instances on both sites must be direct replication partners.

vSphere Replication

  • vSphere Replication 8.0 requires and fully supports vCenter Server 6.0 Update 3, vCenter Server 6.5, or vCenter Server 6.5 Update 1.
  • vSphere Replication 8.0 does not support multiple points in time.
  • You cannot configure the vSphere Replication appliance when the Platform Services Controller is installed with a custom port.
  • vSphere Replication does not support VSS quiescing on Virtual Volumes.
  • vSphere Replication cannot replicate virtual machines that share vmdk files in this release.
  • vSphere Replication does not support vSphere APIs for IO Filtering on both the source and the target sites. You cannot replicate a virtual machine that is assigned a VM Storage Policy that contains IOFilters, nor can you assign such a policy to the replication target VM. Before configuring a virtual machine for replication, verify that the VM Storage Policy that is assigned to it does not contain IOFilters. Do not assign VM Storage policies with IOFilters to virtual machines that are already configured for replication.
  • Deploying more than one vSphere Replication appliance produces a warning on the boot screen. This requires user confirmation to either continue and configure all replications again or shut down the new appliance so that it does not interfere with the old one. This situation does not occur when deploying more than one vSphere Replication servers.
  • Each vSphere Replication Management Server can manage a maximum of 2000 replicated virtual machines. See Configuring Upgraded vSphere Replication Appliances to Support up to 2000 Replications (KB 2102463) and Requirements to the Environment... (KB 2107869).
  • vSphere Replication supports a maximum disk size of 62TB. If you attempt to enable replication on a virtual machine with a disk larger than 62TB, the virtual machine will not perform any replication operation and will not power on.
  • vSphere Replication tracks larger blocks on disks over 2TB. Replication performance on a disk over 2TB might be different than replication performance on a disk under 2TB for the same workload depending on how much of the disk goes over the network for a particular set of changed blocks.
  • vSphere Replication no longer supports IBM DB2 as the vSphere Replication database, in accordance with the removal of support for DB2 as a supported database for vCenter Server 5.5. If you use DB2 as an external vSphere Replication database, contact VMware support for instructions about how to migrate your data to a supported database.
  • vSphere Replication does not support upgrading the VMware Tools package in the vSphere Replication appliance.
  • vSphere Replication supports replicating RDMs in Virtual Compatibility Mode. RDMs in Physical Compatibility Mode cannot be configured for replication.
  • vSphere Replication does not replicate virtual machine snapshot hierarchy at the target site.
  • You can configure virtual machines that are powered off for replication. However, actual replication traffic begins when the virtual machine is powered on.
  • When using Storage DRS at a replication site, ensure that you have homogeneous host and datastore connectivity to prevent Storage DRS from performing resource consuming cross-host moves (changing both the host and the datastore) of replica disks.
  • The 5 minute RPO requires the source host to be ESXi 6.0U3 or later for vSAN, and ESXi 6.5 for other supported datastores.
  • To use the network isolation feature, vSphere Replication requires the host to be ESXi 6.0U3 or later.

 

Resolved Issues

  • NEW If you use a Firefox browser, you cannot configure for replication multiple virtual machines

    If you use a Firefox browser, you receive an error when you attempt to configure for replication multiple virtual machines.

    This issue is fixed.

  • If you use an Active Directory user account for VMware Site Recovery operations​, you receive the error: Permission to perform this operation was denied.

    When you use Hybrid Linked Mode the Active Directory user account that is used to access inventories both on the cloud and on-premises is not authorized to work with VMware Site Recovery. If you try to pair Site Recovery sites or to replicate virtual machines, you receive the error: Permission to perform this operation was denied. You must log in with the cloudadmin@vmc.local user for VMware Site Recovery operations on the VMware Cloud on AWS site.

    This issue is fixed.

  • Unsupported version errors appear on every refresh operation in the Site Recovery Manager 6.5 user interface

    If you have Site Recovery Manager 6.5 and Site Recovery Manager 8.x registered under the same Platform Services Controller or under federated PSCs, you get unsupported version errors on every refresh operation in the Site Recovery Manager 6.5 UI.

    This issue is fixed in Site Recovery Manager 6.5.1.1.

Known Issues

The known issues are grouped as follows.

VMware Site Recovery
  • If you open the History tab of a recovery plan that you have not run yet, you might see an Operation Failed error

    When you open the History tab of a recovery plan that you have not run yet, you might see the following error:
    Error: Operation Failed
    The recovery plan history identified by '-2300' was not found.

    Workaround: Discard the error. It disappears if you run the recovery plan.

  • During the very first login in the vCenter Server on VMware Cloud on AWS, the VMware Site Recovery plug-in might not appear into the vSphere HTML5 client

    When you simultaneously deploy a Software-Defined Data Center on VMware Cloud on AWS and activate the VMware Site Recovery service, the VMware Site Recovery plug-in does not appear into the vSphere HTML5 client on the very first login.

    Workaround: Log out from the vSphere HTML5 client and then log in again.

  • When using Internet Explorer 11 or Edge browsers, you might notice slow performance in rendering while interacting with the VMware Site Recovery UI

    You experience slow performance in rendering of the VMware Site Recovery UI in Internet Explorer 11 and Edge browsers.

    Workaround: Use Chrome or Firefox browsers.

  • Site Recovery Manager status in the VMware Site Recovery HTML 5 and Flex plug-in in the vSphere Web Client might indicate OK, if the SRM server is installed but disconnected

    Site Recovery Manager status in the VMware Site Recovery HTML 5 and Flex plug-in in the vSphere Web Client might indicate OK, if the Site Recovery Manager server is installed but disconnected.

    Workaround: Check the Site Recovery Manager connection status in the VMware Site Recovery HTML 5 standalone user interface.

  • When using Internet Explorer or Firefox, you cannot select custom date from the drop down menu for a recovery plan history report

    If you use Internet Explorer or Firefox browsers, when you select a custom date in the Recovery Plan>History tab a java.lang.NullPointerException error occurs.

    Workaround: Use Chrome browser.

  • When using Internet Explorer the Register new replication server list is empty

    When you attempt to register new vSphere Replication server using Internet Explorer, the Register new replication server list is empty

    Workaround: Use Chrome browser.

  • The Configure Replication action in the VMware Site Recovery HTML 5 UI plug-in is not displayed when you use vSphere 6.5 U1 HTML 5 UI in your on-premises environment

    If you use vSphere 6.5 U1 HTML 5 UI for your on-premises environment, the Configure Replication action in the VMware Site Recovery HTML 5 UI plug-in is not displayed.

    Workaround 1: Restart the vSphere HTML 5 client and login again.

    1. Logout from vSphere HTML 5 client.
    2. SSH to vCenter Server and run the following commands:
      service-control --stop vsphere-ui
      service-control --start vsphere-ui
    3. Login in the vSphere HTML 5 client.

    Workaround 2: Use the vSphere Flex Web Client.

  • When you right-click on a replicated VM and select Reconfigure Replication in the vSphere UI, the pop-up window for the VMware Site Recovery UI is blocked without notification in Mozilla Firefox browser

    By default the VMware 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 VMware Site Recovery 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.

  • When you select Export All from Recovery Plans History for a time period with no entries, you get Response with status: 500 OK for URL: error

    When you go to the Site Pair > Recovery Plan History and select Export All for a time period with no entries, you get the following error.
    500 - OK
    Response with status: 500 OK for URL:...

    Workaround: Discard the error and select a time period with run plan entries to export.

  • Recovery fails for VMs that have CD or floppy images backed with images from vmimages folder

    If you have a protected virtual machine that has CD or floppy images that were backed with images from vmimages folder, recovery operation fails with Invalid datastore path error.

    Workaround: Do not use images from vmimages folder for backing.

  • vSphere HTML 5 client does not load if you have Windows vCenter Server 6.5 U1 installed with custom port

    If you have installed Windows vCenter Server 6.5 U1 with a custom port, for example 8443, when you attempt to use the vSphere HTML 5 client, you get the following error: Empty SSO response string.

    Workaround 1:

    1. Open file C:\ProgramData\VMware\vCenterServer\runtime\vsphere-ui\server\configuration\tomcat-server.xml
    2. Find the entries below and edit port 443 to 8443 accordingly:
      <connector ...="" address="127.0.0.1" port="5090" protocol="HTTP/1.1" proxyport="443"></connector>
      <connector ...="" address="::1" port="5090" protocol="HTTP/1.1" proxyport="443"></connector>
    3. Restart the vsphere-ui service:
      C:\Program Files\VMware\vCenter Server\vmon\vmon-cli" --restart vsphere-ui

    Workaround 2: Use the vSphere Flex Web Client.

  • Site Recovery Manager plug-in does not display in the vSphere Web Client if Site Recovery Manager service stops

    After you install Site Recovery Manager and the service stops for any reason, the vSphere Web Client does not display the Site Recovery Manager plug-in.

    Workaround: Restart the vSphere Web Client.

  • You cannot configure replication for a virtual machine that has vmdk files with the same name

    A virtual machine can have vmdk files (hard disks) with the same name. This might happen when you add a new hard disk to a virtual machine after you have created the VM, and the new disk is on a different datastore from the existing hard disks. Such virtual machine cannot be configured for replication.

    Workaround: None.

  • After uninstalling vSphere Replication 8.0, the VMware Site Recovery plug-in is still visible in the vSphere Client

    If you uninstall vSphere Replication 8.0 of the VMware Site Recovery service, the VMware Site Recovery plug-in in the vSphere Client is still visible.

    Workaround: Restart the vSphere Client service.

Site Recovery Manager 8.0
  • Site Recovery Manager uses the default value of the remoteSiteStatus.drPanicDelay setting even if you changed the value

    Even if you set a custom value for the delay between a not responding event and a site down event, the drPanicDelay has a default value in the Tasks view.

    Workaround: Change the value of the remoteSiteStatus.drPanicDelay setting and restart Site Recovery Manager Server.

  • 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.
  • A Test Recovery Fails with the Cannot create a test bubble image for group message

    If you have a VM with multiple disks that are replicated with vSphere Replication to different vSphere Virtual Volumes datastores on the secondary site, a test recovery operation fails. During a test recovery, vSphere Replication tries to create Linked Clones for the vSphere Virtual Volumes replica disks, but the operation fails because Linked Clones across different datastores are not supported. vSphere Replication creates Linked Clones only during a test recovery. The planned recovery, unplanned recovery, and reprotect complete successfully.

    Workaround: A test recovery operation using vSphere Virtual Volumes disks pass successfully only if all disks are replicated to the same vSphere Virtual Volumes datastore on the secondary site.

  • The First Attempt for Recovery of VMs placed on vSphere Virtual Volumes might fail during the customization steps

    Site Recovery Manager cannot recognize old VMware Tools versions installed on VMs placed on vSphere Virtual Volumes storage during the first recovery attempt. You might observe the following failures that depend on the VMware Tools version installed on the recovered VMs. Vim::Fault::OperationNotSupportedByGuest : "The guest operating system does not support the operation." Vim::Fault::InvalidGuestLogin : "Failed to authenticate with the guest operating system using the supplied credentials.

    Workaround:

    1. Rerun the failed recovery plan or clean the test plan up and rerun the test recovery again.
    2. Update VMware Tools to the latest version for all VMs placed on vSphere Virtual Volumes storage.

  • 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 Recovery Plan fails if your recovered VM uses the latest VMware Tools version and is not synchronized with the ESXi host on the recovery site

    If you use an IP customization or in-guest callout operations and the time of your guest OS on the recovered VM is not synchronized with your ESXi host on the recovery site, you receive the following error.

    Error - Failed to authenticate with the guest operating system using the supplied credentials.

    Workaround: If the recovery.autoDeployGuestAlias option in Advanced Settings is FALSE, ensure the time synchronization between the recovered VM and vCenter Single Sign-On on the recovery site, and rerun the recovery plan.

    If the recovery.autoDeployGuestAlias option in Advanced Settings is TRUE and 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 recovery.autoDeployGuestAlias option in Advanced Settings is TRUE and the guest OS of the recovered VM is Linux, ensure the time synchronization between the ESXi host and vCenter Single Sign-On on the recovery site, 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.
  • Valid vCenter Server addresses might not be listed as possible targets when you install Site Recovery Manager

    If there are duplicated vCenter Server addresses in your environment due to multiple service registrations of one vCenter Server with different versions, a valid address might not be listed. Site Recovery Manager writes an error for duplicated key in its installation log file.

    The following error message appears in the installation log file of your Site Recovery Manager:

    VMware: Srm::Installation::XmlFileHandler::GetElementMap: INFORMATION: Inserted key 'xxxxxx' and value '76B00E54-9A6F-4C13-8DD9-5C5A4E6101E3'

    VMware: Srm::Installation::XmlFileHandler::GetElementMap: INFORMATION: Inserted key 'xxxxxx' and value 'default-first-site:b84bcef3-85fb-4d92-8204-2392acf0088d'

    VMware: Srm::Installation::XmlFileHandler::GetElementMap: ERROR: Duplicate key 'xxxxxx' exists

    Workaround: See https://kb.vmware.com/kb/2145520.

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

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

  • Renaming a datastore associated with a protected virtual machine can result in loss of protection and recovery settings.

    A protected virtual machine can lose its protection status as well as recovery settings when you rename the datastore associated with the virtual machine. First shut down the Site Recovery Manager server, then rename datastores to avoid losing recovery settings for the virtual machine.

    Workaround: To restore the protection status, restart the protected site Site Recovery Manager server or remove the affected datastore from the protection group and then add it back, then reconfigure recovery settings.

  • Site Recovery Manager installation fails if the Platform Services Controller certificate has expired.

    When connecting to Platform Services Controller during Site Recovery Manager installation, you can accept the Platform Services Controller certificate even if it has expired or is not yet valid. The installation then fails at the step when you select the vCenter Server instance to connect to, with the error Failed to validate vCenter Server. Details: Internal error: unexpected error code: -1. The same error occurs if the Platform Services Controller certificate expires after you install Site Recovery Manager and you run the Site Recovery Manager installer in Modify mode. If the Platform Services Controller certificate expires after you have installed Site Recovery Manager, different errors can also appear in the Site Recovery Manager interface.

    Workaround: Replace the Platform Services Controller certificate and attempt installation again.

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

  • Rerunning reprotect fails with error: Protection Group '{protectionGroupName}' has protected VMs with placeholders which need to be repaired.

    If a ReloadFromPath operation does not succeed during the first reprotect, the corresponding protected virtual machines enter a repairNeeded state. 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 ReloadFromPath operation failed.

    Workaround: Rerun reprotect with the force cleanup option enabled. This option completes the reprotect operation and enables the Recreate placeholder option. Click Recreate placeholder to repair the protected virtual machines and to restore the placeholder virtual machines.

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

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

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

vSphere Replication 8.0
  • During full synchronization vSphere Replication fails with error: A replication error occurred at the vSphere Replication Server.

    During full synchronization vSphere Replication might fail with the following error.
    A replication error occurred at the vSphere Replication Server for replication <group_name>. Details: 'Error for (datastoreUUID: "..."), (diskId: "..."), (hostId: "..."), (pathname: "..."), (flags: retriable, pick-new-host, nfc-no-memory): Class: NFC Code: 5; NFC error: NFC_NO_MEMORY; Set error flag: nfc-no-memory; Code set to: Host unable to process request.; Set error flag: retriable; Set error flag: pick-new-host; Can't write (single) to remote disk'.

    Usually, this error is transient and the operation succeeds after some time.

  • vSphere Replication operations fail when there is heavy replication traffic

    vSphere Replication operations might fail with error java.net.UnknownHostException. These errors occur because DNS requests are dropped due to network congestion.

    Workaround: Configure your network to ensure that management traffic is not dropped, by configuring traffic shaping, quality of service, or DNS on the vSphere Replication appliance. One possible solution is to modify the network address caching policy for the vSphere Replication appliance.

    1. Log into the vSphere Replication appliance as root.
    2. Open the file /usr/java/jre1.7.0_72/lib/security/java.security in an editor.
    3. Uncomment the line networkaddress.cache.ttl and set its value to at least 86400 seconds (24 hours) or to the longest time that is required for an initial full sync to complete.
    4. Save the file and reboot the vSphere Replication appliance.
    5. Repeat the procedure for all remaining vSphere Replication appliances.
  • Data synchronization fails and the log file of the source vSphere Replication Management Server contains error DeltaAbortedException

    If your environment experiences connectivity issues during data synchronization, you might observe the following problems.

    • Replication group synchronizations fail and the hms<n>.log file in the vSphere Replication Management server at the source site contains the following error message:
      DeltaAbortedException.
    • In Site Recovery Manager, replication group synchronizations fail with the following error message:
      VR synchronization failed for VRM group <group_name>. A generic error occurred in the vSphere Replication Management Server. Exception details: 'com.vmware.hms.replication.sync.DeltaAbortedException' .

    Workaround: Resolve the connectivity issues in your environment before you proceed.

  • Replications appear in Not Active (RPO violation) status after changing the IP address of the vSphere Replication server at the target site

    If the IP address of the vSphere Replication server at the target site changes, the status of all replications to this site turns to Not Active (RPO violation). This problem is observed because replications on the source site are not reconfigured automatically when the IP address changes.

    Workaround: Reconfigure all replications, so that the source hosts use the new IP address of the target vSphere Replication server.

  • Transient Error state during the initial full synchronization

    During the initial synchronization, you might observe that the state of the synchronization changes temporarily to Error and back to normal multiple times. The error state might indicate resource deficiency at the target site. If the IO workload caused by the sync operation is higher than the load that target hosts can handle, the state of the replication will turn to Error. When the IO workload decreases, the error disappears.

    Workaround: Reduce the value of the host configuration option called HBR.TransferMaxContExtents on each ESXi host where replication source VMs are running. The default value is 8, and a lower value decreases the size of data blocks that are sent during one sync update, but increases the duration of the initial full sync. After the initial full sync, change the value back to its default (8) to achieve maximum RPO performance. If transient errors continue to appear during delta synchronizations, it might mean that a lot of changed blocks are transferred during each delta, and the hosts at the target site cannot accommodate the incurred IO workload. In such cases, keep the value of the HBR.TransferMaxContExtents configuration option low.
    Alternatively, you can add more hosts to the secondary site.

  • Registering additional vSphere Replication servers takes a long time

    If vCenter Server manages several hundred ESXi Server hosts, registering an additional vSphere Replication server with the vSphere Replication appliance can take several minutes.
    This is because the vSphere Replication server must register with each ESXi Server host.

  • Operation in vSphere Replication Management Server fails with error "... UnmarshallException"

    When the vSphere Replication Management Server experiences high load or transient network errors, operations can fail with UnmarshallException due to errors in the communication layer.

    Workaround: Try the failed operation again.

  • vSphere Replication Management Server (VRMS) might leak a partially recovered virtual machine in the target vCenter Server after a failed recovery

    In rare cases VRMS might stop during recovery immediately after registering the recovered virtual machine in the target vCenter Server. The last recovery error in the replication details panel says VRM Server was unable to complete the operation. When VRMS restarts, it cleans up the files for the partially recovered virtual machine. In some cases, it fails to unregister the virtual machine from the target vCenter Server. Subsequent recovery attempts show an error in the recovery wizard that the selected virtual machine folder already contains an entity with the same name.

    Workaround: Manually remove the virtual machine from the target vCenter Server, but keep its disks as they point to the replica placeholder files.

  • vSphere Replication service is inaccessible after vCenter Server certificate changes

    If the vCenter Server certificate changes, vSphere Replication becomes inaccessible.

    Workaround: See vSphere Replication is Inaccessible After Changing vCenter Server Certificate.

  • Failover with "Sync latest changes" might fail with SocketTimeoutException when multiple replications are recovered concurrently and there is a huge accumulated delta since the latest synchronization

    The vSphere Replication Management server might not receive due responses through the vCenter reverse proxy when there is heavy replication traffic at the same network. Some replication management or monitoring operations might fail with the following error message:
    'com.vmware.vim.vmomi.client.exception.ConnectionException: java.net.SocketTimeoutException: Read timed out'

    Workaround: Configure network traffic isolation for vSphere Replication traffic, so that the management communication between vCenter and the vSphere Replication Management server is not affected by the heavy replication traffic. See Isolating the Network Traffic of vSphere Replication.

  • Cannot reconfigure replication after switching from embedded database to existing external database

    If you configure vSphere Replication with an external database and configure replication within the same site, then switch to the embedded database, the replication is not available, which is as designed. If you switch back to the external database, the replication is in an error state. Reconfiguring the replication fails with the following error: ManagedObjectNotFound

    Workaround: When restoring the vSphere Replication database to the previous external or embedded database, you must reset its contents.