VMware vSphere Replication 6.1 Release Notes

|

VMware vSphere Replication 6.1.0.1 | 29 MAR 2016 | Build 3656323

VMware vSphere Replication 6.1 | 10 SEP 2015 | Build 3051487

Last updated: 23 MAR 2017

Check for additions and updates to these release notes.

For information about the vSphere Replication 6.1.0.x patch releases, see the corresponding section.

What's in the Release Notes

These release notes cover the following topics:

Localization

VMware vSphere Replication 6.1 is available in the following languages:

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

What's New

The following features are new for this release:

  • 5 minute Recovery Point Objective (RPO) for replication between Virtual SAN data stores – This version of vSphere Replication allows customers to replicate virtual machine workloads with an RPO setting as low as 5 minutes between Virtual SAN data stores.
  • Support for NFS v 4.1 – This release introduces support for NFS v 4.1 data stores. It allows customers to protect and recover virtual machines that are provisioned onto NFS v 4.1 environments using vSphere Replication.
  • UI Enhancements – the RPO settings in the Configure Replication wizard are simplified and provide more granular options of predefined RPO settings.
  • UI Enhancements – the number of properties columns in the Monitor tab of the vSphere Web Client is reduced. Additional replication properties are available when you click to view the details for a selected replication.

Product Documentation

In addition to the current release notes, you can use the documentation set for vSphere Replication 6.1 that includes the following deliverables.

The documentation set for VMware vCloud Air – Disaster Recovery includes the following deliverables.

vCloud Suite Licensing and Integration

You can license vSphere Replication 6.1 individually or as part of vCloud Suite 6.0. You should consider the licensing and integration options that are available to you.

Some vCloud Suite components are available as standalone products that are licensed on a per-virtual machine basis. When the products are part of vCloud Suite, they are licensed on a per-CPU basis. You can run unlimited number of virtual machines on CPUs that are licensed with vCloud Suite.

You can combine the features of vSphere Replication with other components of vCloud Suite to leverage the full capabilities of the software-defined data center. For more information, see vCloud Suite Architecture Overview and Use Cases.

Installation

Download the vSphere Replication .zip file and unzip it. The vSphere Replication 6.1 .zip file includes two OVF files. You can deploy each package by using the Deploy OVF wizard in the vSphere Web Client:

  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 Installing vSphere Replication in the vSphere Replication Documentation Center.

NOTE: For vCenter Server to vCenter Server replications, the version of the vSphere Replication Management server on the source and the target site must match.

Upgrading vSphere Replication

The downloadable ISO image is the only means of upgrading from vSphere Replication 5.8.0.2 or 6.0.0.1 to vSphere Replication 6.1. You cannot upgrade vSphere Replication from version 5.8.0.2 or 6.0.0.1 to version 6.1 by using vSphere Update Manager or the official VMware Update Repository from the VAMI of the vSphere Replication appliance. See the interoperability pages for further information on supported versions.

Important: Before you initiate an upgrade, verify that the vSphere Replication appliance has an OVF environment, or context. See Checking and Restoring the OVF Context of the vSphere Replication Appliance (2106709).

Verify that you read section Upgrade under Known Issues.

See Upgrade vSphere Replication by Using the Downloadable ISO Image for the procedure on upgrading to vSphere Replication 6.1.

Operational Limits for vSphere Replication

The operational limits of vSphere Replication 6.1 are documented in the VMware Knowledge Base. See Operational Limits for vSphere Replication 6.x (KB 2102453).

Note: vSphere Replication requires additional configuration to support more than 500 replications per a vSphere Replication Management server. See Operational Limits for vSphere Replication 6.х and Configuring Upgraded vSphere Replication Appliances to Support up to 2000 Replications.

Open Source Components

The copyright statements and licenses applicable to the open source software components distributed in vSphere Replication 6.1 are available at the vSphere Replication Open Source Disclosure page.

Caveats and Limitations of vSphere Replication 6.1

To ensure successful virtual machine replication, you must verify that your virtual infrastructure respects certain limits before you start the replication.

  • vSphere Replication 6.1 requires and fully supports vCenter Server 6.0.
  • 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 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 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.
  • For replications to cloud, a seed vApp can be used for only one replication.
  • The 5 minute RPO requires the source host to be ESXi 6.0 or later.
  • NEW To use the network isolation feature, vSphere Replication requires the host to be ESXi 6.0 or later.

Supported Browser Versions

For supported browser versions for the vSphere Web Client, see the documentation of the vSphere Web Client that you use.

VAMI is dependent on VMware Studio. See VMware Studio 2.5 Release Notes for supported browser versions when using the VAMI.

Available Patch Releases

vSphere Replication 6.1.0.1 Express Patch Release

Released 29 MAR 2016 | Build 3656323

  • The vSphere Replication 6.1.0.1 Express Patch applies the fix for CVE-2015-7547.
Installation Notes

If you are running vSphere Replication 6.1.0.x, upgrade to vSphere Replication 6.1.0.1. See Upgrading vSphere Replication in vSphere Replication Administration for instructions about updating vSphere Replication 6.1.0.x.

You upgrade vSphere Replication by using a downloadable ISO image.

Known Issues

The following known issues have been discovered through rigorous testing and will help you understand some behavior you might encounter in this release.

Upgrade

The following known issues might be observed after the upgrade.

  • The vSphere Replication Management service does not start after the upgrade

    After you upgrade vSphere Replication, the vSphere Replication Management (VRM) service appears as stopped in the VAMI, and the /opt/vmware/hms/logs/hms-configtool.log file in the virtual appliance contains java.net.ConnectException: Connection refused error messages.

    This problem is observed if the upgrade procedure of the embedded DB schema fails because the vPostgreSQL service was not fully started.

    Workaround:

    1. In the virtual appliance console, log in as the root user.
    2. Run the following command: $ /opt/vmware/hms/bin/hms-configtool -cmd upgrade -configfile /opt/vmware/hms/conf/hms-configuration.xml

      The DB schema upgrade starts.

    3. Wait for the DB upgrade procedure to complete.
    4. In the vSphere Replication VAMI, navigate to the Configuration tab, and complete the SSO registration of the appliance.

  • Missing vSphere Replication permissions after upgrading the vSphere Replication appliance, certificate or IP change

    If you upgrade the vSphere Replication appliance, or if for some other reason the certificate or the IP address of the vSphere Replication appliance changes, the permissions that are assigned to the default VRM user roles are deleted.
    This problem is observed every time the vSphere Replication extension is unregistered and registered with the vCenter Server extension manager.

    Workaround: Clone the predefined VRM roles and create your custom roles before upgrading the vSphere Replication appliance, or changing its certificate or IP address. The permissions that are assigned to custom roles are not removed.

  • The vSphere Replication Virtual Appliance Management Interface (VAMI) becomes inaccessible after upgrade

    After the upgrade, the vSphere Replication VAMI changes and you cannot access it in the same browser window that you used before the upgrade.

    Workaround: Do one of the following.

    • Change the browser that you use to open the VAMI.
    • Close the entire browser and open a new browser window to connect to the VAMI.
    • Clear the cache of your browser.

  • After an upgrade from 5.5.x to 6.x, you cannot register more than one vSphere Replication appliance in the same vCenter Single Sign-On domain

    If the appliances in your environment use the default auto-generated self-signed vSphere Replication certificates, you cannot register more than one vSphere Replication appliance within the same Single Sign-On domain.
    The problem is observed because in 5.5.x and earlier releases, all auto-generated self-signed vSphere Replication certificates are issued to the same common name.

    Workaround: Regenerate the self-signed certificates by using the VAMI of each vSphere Replication appliance in the Single Sign-On domain.

  • The vSphere Replication appliance changes to a vSphere Replication server after the upgrade

    If you do not check the OVF context of the vSphere Replication appliance before you perform an upgrade, and the upgrade operation does not fail, the upgraded vSphere Replication appliance appears as a vSphere Replication Server. The data about replications that were configured before the upgrade is lost.

    Workaround:

  • After an upgrade of the vCenter Server and vSphere Replication, configuring the SSO in the vSphere Replication VAMI fails with error Bad exit code: 1

    After you upgrade the vCenter Server to version 6.0 and vSphere Replication to version 6.1, you must register the appliance with vCenter Single Sign-on. On the Configuration tab of the vSphere Replication VAMI, you enter the LookupService address and the credentials of an SSO administrator, and click Save and Restart Service. The following error message appears: Bad exit code: 1.
    This problem is observed because the upgraded vCenter Server changes its IP address or certificate, but the vSphere Replication Management server preserves the old IP address and certificate of the vCenter Server in its OVF environment. As a result, the validation of the vCenter Server fails.

    Workaround: In the vSphere Web Client, right-click the vSphere Replication Management server VM and power it off and on. This operation forces the update of the OVF environment on the vSphere Replication Management server VM.

  • Error: Cannot update the dynamic configuration policy when configuring NTP in an upgraded vSphere Replication appliance

    If you run the yast2 ntp-client add server=<your_chosen_time_server> command in the vSphere Replication appliance to configure synchronization with an NTP server, the following error message appears Error: Cannot update the dynamic configuration policy.

    Workaround: You can ignore this error message and proceed with configuring the synchronization with the NTP server of you choice:

    1. Log in to the vSphere Replication appliance console as the root user.
    2. Run the command yast2 ntp-client add server=<your_chosen_time_server>
      This error message appears in the console: Error: Cannot update the dynamic configuration policy.
    3. Run the command yast2 ntp-client enable
    4. Run the command sntp -P no -r <your_chosen_time_server>
    The ntp.conf file is updated and the NTP synchronization is configured successfully.



  • vSphere Replication appears as Enabled (Not accessible) after the upgrade

    In the vSphere Web Client, on the vSphere Replication Home tab, you can check the list of vCenter Server instances in the Single-Sing On domain, and the status of vSphere Replication on each vCenter Server instance. After you upgrade vSphere Replication, the status of the upgraded vSphere Replication server turns to Enabled (Not accessible).

    Workaround: Configure the synchronization with an NTP server of you choice:

    1. Log in to the vSphere Replication appliance console as the root user.
    2. Run the command yast2 ntp-client add server=<your_chosen_time_server>
      This error message appears in the console: Error: Cannot update the dynamic configuration policy.
    3. Run the command yast2 ntp-client enable
    4. Run the command sntp -P no -r <your_chosen_time_server>
    The ntp.conf file is updated and the NTP synchronization is configured successfully.



  • Site Recovery Manager cannot be upgraded after upgrading vSphere Replication

    On upgrade of vSphere Replication to version 6.1, Site Recovery Manager cannot be upgraded as the vSphere Replication versions is detected as incompatible. Under solutions manager in vCenter, the vSphere Replication version appears not to have been upgraded though the appliance reports the upgrade is successful.

    Workaround: Register the vSphere Replication appliance with vCenter Single Sign-On.

    1. Connect to the VAMI interface of the vSphere Replication appliance by using a supported browser.
      See VMware Studio 2.5 Release Notes for supported browser versions when using the VAMI.
    2. On the Configuration tab, enter the user name and password of an SSO administrator.
      Note: The text boxes for the SSO credentials will not be visible if you are using an unsupported browser.

General

The issues in this section pertain to the vSphere Replication vApp, or to all types of replication.

  • You experience a 120 seconds data request timeout after which the vCenter Server inventory and related views in the vSphere UI remain empty and unusable

    If the storage where the vSphere Replication appliance is installed becomes unavailable, you might experience a 120 seconds data request timeout. Due to the cancelled data request the UI cannot recover to the expected state and as a result becomes unusable. If the vSphere Replication appliance becomes available again and there is no data corruption, logging off and then logging in again should fix the problem. If the appliance cannot be recovered, you can resolve the problem by unregistering the appliance from the vCenter Server. See Unregister vSphere Replication from vCenter Server if the Appliance Was Deleted. Performing that procedure uninstalls the vSphere Replication UI plugin at next login.

    Workaround: Disable the vSphere Replication UI plugin in vSphere UI, Administration -> Client Plug-ins.

  • vSphere Replication UI does not warn the user if the selected target datastore is not compliant with the default datastore policy

    When you configure a VM for replication, the Target Location page has the default datastore policy as the preselected VM Storage Policy. No warning is shown if a storage that is non-compliant with its policy is selected. Depending on the type of non-compliance the replication configuration might fail or succeed. The replicated VM can be recovered, but will later fail to power on due to non-compliance.

    Workaround: Select a concrete policy, and then select a datastore from the Compatible group in the list.

  • Replacing the SSL certificate of vCenter Server causes certificate validation errors in vSphere Replication

    If you replace the SSL certificate on the vCenter Server system, a connection error occurs when vSphere Replication attempts to connect to vCenter Server.

    Workaround: For information about how to update vCenter Server certificates and allow solutions such as vSphere Replication to continue to function, see http://kb.vmware.com/kb/2109074.

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

  • The initial configuration task fails with error InvalidArgument

    If you configure a replication for a virtual machine that contains disks without UUID, vSphere Replication assigns UUIDs for these disks during the initial configuration. However, if these disks have parent disks, for example preceding snapshots, vSphere Replication cannot assign UUIDs for them and the initial configuration task fails with error InvalidArgument.

    Workaround: Consolidate the disks on the source virtual machine and try configuring a replication again.

  • Target datastores are not displayed in the Configure Replication wizard

    If you try to configure a replication, the datastores at the target site are not listed in the Target Location page of the Configure Replication wizard.

    Workaround: Restart the vSphere Web Client at the source site.

    • For Linux-based installations, establish an SSH connection to the vCenter Server and run the command service vsphere-client restart
    • For Windows-based installations, open the list of Windows services on the vCenter Server, right-click the VMware vSphere Web Client service, and click Restart.
  • 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.

  • Virtual machines that are located in the target folder are overwritten during recovery

    If the target folder contains a registered virtual machine with the same name as the replicated virtual machine, the registered virtual machine is overwritten during the recovery. When you start the Recovery wizard, vSphere Replication checks the target folder and displays a dialog box for you to confirm the overwrite operation. On rare occasions, after the target check is complete, and while the wizard is still open, a virtual machine might be registered to the target folder. On these occasions, the virtual machine that was copied to the target folder will be overwritten without further notice.

    Workaround: None.

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

  • The error message Unable to compute permissions appears when you start the Reconfigure wizard for an incoming replication

    When a replication is configured between two remote sites and you do not have a current session to the source site, when you right-click a replication from the Incoming Replications list and select Reconfigure, the following error message appears: Unable to compute permissions.

    Workaround: Navigate to the vSphere Replication Target Sites view, and reconnect the source and the target site.

  • Users that are assigned the VRM administrator or VRM virtual machine replication role cannot access the Configure Replication wizard

    The Configure Replication wizard is not launched if a user that is assigned the predefined VRM administrator or VRM virtual machine replication role logs in the vSphere Web Client and attempts to configure a replication.

    Workaround: Clone the default role to add the Profile-driven storage -> Profile-driven storage view privilege to it, and assign the cloned role to the user.

  • Clicking the Configure link for an embedded VR Server does not open the VAMI

    If you navigate to the Replication Servers view, select an embedded vSphere Replication server, and invoke the Configure action, the VAMI is not displayed.

    Workaround: Open a browser and enter the address https://<VR_Appliance_Address>:5480 to open the VAMI.

  • Empty Reconfigure wizard for user roles that are not assigned the View VR privilege

    If a custom role that does not have the View VR privilege is assigned to a user, and that user attempts to reconfigure a replication, the Reconfigure wizard is launched empty.

    Workaround: None.

  • vSphere Replication tasks are not localized in the vSphere Web Client

    The vSphere Replication tasks that appear in Tasks pane of the vSphere Web Client are not localized.

    Workaround: You can ignore this localization problem. vSphere Replication tasks run as expected.

  • The option to enable quiescing is disabled in Configure Replication wizard for a powered off replication source VM, though the guest OS supports quiescing

    For both Linux and Windows sources, the Enable Quiescing option is enabled based on the information about the guest OS. If a virtual machine has never been powered on, ESXi hosts always report no support for quiescing, because the guest OS information is not available.

    Workaround: Verify that replication source VMs have been powered on at least once before you configure replications.

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

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

  • During replication of multiple virtual machines, a vSphere Replication server might enter a state where it does not accept any further VRMS connections but continues to replicate virtual machines

    Workaround: Reboot the vSphere Replication server.

  • vSphere Replication operations fail with a Not Authenticated error

    If you start an operation on one site, for example configuring vSphere Replication on a virtual machine, and then restart vCenter Server and the vSphere Replication appliance on the other site, vSphere Replication operations can fail with the error VRM Server generic error. Please check the documentation for any troubleshooting information. The detailed exception is: 'com.vmware.vim.binding.vim.fault.NotAuthenticated'. This problem is caused by the fact that the vSphere Replication server retains in its cache the connection session from before you restarted vCenter Server and the vSphere Replication appliance.

    Workaround: Clear the vSphere Replication connection cache by logging out of the vSphere Web Client and logging back in again.

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

  • The VAMI might not respond when you install an update

    When you upgrade vSphere Replication, a status message 'Installing Updates' might not disappear even after the updates install successfully because the VAMI is not responding.

    Workaround: Refresh the VAMI UI in the browser or open it in a new tab.

  • A virtual machine recovered in vSphere Replication does not power on in vCenter Server

    When you use vSphere Replication to run a recovery on a virtual machine, it fails, and the status of the replication is not 'Recovered'. The virtual machine is registered in the vCenter inventory, but when you try to power it on, it fails with error: File [datastorename] path/vmname.vmx was not found. The virtual machine registration as part of the vSphere Replication recovery workflow can succeed in vCenter Server, but the response might not reach the vSphere Replication Management Server due to a transient network error. vSphere Replication reverts the replication image and reports a failed recovery task due to virtual machine registration error. If you initiate another recovery, it fails with a message that a virtual machine with the same name is already registered in vCenter Server.

    Workaround: Remove the partially recovered virtual machine from the vCenter Server inventory. Do not delete the files from disk. Try the recovery again.

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

Replications to vCenter Server

The issues in this section are specific to replications to a vCenter Server.

  • Cannot reconnect sites if the connection status is "Connection issue"

    When two sites are connected, but the status of the connection is Connection issue, the following error message appears if you try to reconnect the sites:
    An internal error has occurred - scheme and schemeSpecificPart should not be null.

    Workaround: Disconnect the sites and connect them again.

  • No replications are shown in Outgoing/Incoming views on the target site when the source vCenter Server is unavailable

    If you have configured replications between two remote sites, and currently the source vCenter Server is unavailable, the Monitoring views on the target site do not show any incoming or outgoing replications.

    Workaround: Start the source vCenter Server if available.

  • You cannot use custom defined users and roles with vSphere Replication

    You are unable to configure a replication with a custom user, even if that custom user is assigned all required VRM privileges on both sites. The error message Permission to perform this operation is denied appears on the Target Location page in Configure Replication wizards.

    Workaround: None. All vSphere Replication operations must be performed with the SSO administrator user on both sites.

  • A recovered virtual machine with multiple point-in-time instances enabled can lose the attached disks to the latest snapshot when you revert to a previous snapshot and then revert to latest snapshot again

    When you recover a virtual machine for which you enabled point-in-time instances and attach a disk for unresolved disks, if any, the disks attach to the latest snapshot. If you revert to a previous snapshot and then revert to the latest one, the attached disks are not available.

    Workaround: Edit settings of the virtual machine and add the required disks as existing hard disks.

  • When a target vSphere Replication server is not available, vSphere Replication does not show an error in the vSphere Web Client Monitor -> Issues page

    If the target vSphere Replication server is not available because it is powered off or has network connectivity issues, and a replication is in an initial full-sync state, vSphere Replication does not report an issue in the Web Client at Monitor -> Issues page of the target vCenter Server. Instead, you see an event on the vCenter Server and a disconnected status at Manage -> vSphere Replication -> Replication servers.

    Workaround: Check if a target vSphere Replication server is currently available at Manage -> vSphere Replication -> Replication Servers page. Alternatively, set an alarm for "VR Server disconnected" event on the target vCenter Server.

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

  • Cannot configure a virtual machine with physical mode RDM disk even if the disk is excluded from replication

    If you configure a replication for a virtual machine with physical mode, you might see the following error:

    VRM Server generic error. Check the documentation for any troubleshooting information. 
    The detailed exception is: HMS can not set disk UUID for disks of VM : MoRef: 
    type = VirtualMachine, value = 
       
          
           
        , serverGuid = null'.
       
          

    Workaround: None.

  • Recovering a virtual machine using the "Recover with latest available data" option is possible when the source virtual machine is powered on

    Before you start a recovery operation on the target site, you must power off the replication source virtual machine. However, if you select the option Recover with latest available data when recovering a virtual machine, it is possible to perform the recovery while the source virtual machine is powered on. This causes the following problems.

    • The state of the replication temporarily changes to Error after a recovery operation has been started for it

      If you initiate a recovery operation while the source virtual machine is still powered on, the state of the replication changes temporarily from Recovering to Error and back to Recovering before the recovery operation completes successfully.

      Workaround: You can ignore this transient Error state as the recovery on the target site is successful.
      Note: During recovery operation, replication of the source virtual machine to the target site does not proceed. It will resume immediately after recovery operation, if the recovery operation does not succeed.

    • The network cards of the recovered virtual machine are disconnected when it powers on.

      Workaround: Ensure that the source virtual machine is powered off before you connect the recovered virtual machine to the network.

    If you select Recover with recent changes when you recover a virtual machine, it is not possible to complete the recovery if the source virtual machine is powered on.

  • Recovering a virtual machine with vSphere Replication 6.1 fails to power on the recovered virtual machine

    If a replicated virtual machine is attached to a distributed virtual switch and you attempt to perform a recovery in an automated DRS cluster, the recovery operation succeeds but the resulting virtual machine cannot be powered on.

    Workaround: Edit the recovered virtual machine settings to attach it to the correct network.

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

Cloud Replications

The issues in this section are specific to replications to and from cloud.

  • org.hibernate.exception in the VCTA log file

    In the vcta-info.log.<n> file or the vcta-debug.log file, you might observe the following message:
    org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update

    Workaround: You can ignore this message because it does not affect the operation of vCloud Air - Disaster Recovery.

  • The vApp in the cloud organization is not powered off after a recovery on premise

    When you recover a replication from cloud at the tenant site and, in the Recovery wizard, you select to recover the VM by using the option Use latest available data, vSphere Replication does not power off the source vApp in the cloud.
    This is because the option Use latest available data assumes that there is no connection to the replication source site.

    Workaround: You can connect to the cloud site to manually power off the source vApp.

  • Replications from cloud turn into Error state

    If you use the vCloud Air web user interface to add a new disk to a virtual machine that serves as a replication source, vSphere Replication at your local site automatically pauses the incoming replication for that machine, and moves the replication group into Error state.

    Workaround: Stop the replication from cloud that indicates Error state, and configure a new replication.

  • Hardware changes on the replication source VM might not be automatically copied to the placeholder vApp in the cloud

    Changes to the protected virtual machine on the source site, such as changes to memory, CPU, networks, and so on, might not be replicated to the placeholder vApp in your cloud organization if you apply them while vSphere Replication is running a workflow, for example, a test recovery.

    Workaround: Edit the hardware of the replication source VM again to trigger a full synchronization.

    1. In the vSphere Web Client inventory tree, right-click the source VM.
    2. From the drop-down menu, select Edit Settings, and apply a change to the virtual hardware.
      Note: Opening and closing the Edit Setting dialog box is not enough. You must apply some change to the hardware.
    3. Click OK.
  • Disks are not automatically consolidated during recovery at the cloud site

    If you configure a replication to cloud that has the MPIT functionality enabled, and you recover the replicated virtual machine at the cloud site, its retained instances are not consolidated during the recovery. By design, replication instances are not consolidated to speed up the recovery process.
    The unconsolidated disks in the recovered virtual machine might cause performance problems as follows.

    • The recovered virtual machine runs slower than expected.
    • The recovered virtual machine requires more storage resources.

    Workaround: Use the vCloud Air interface to manually consolidate the disks on the recovered virtual machine.



  • Outgoing replications to cloud remain in Not Active state

    By default, when you power on the vSphere Replication appliance, a vSphere Installation Bundle (VIB) is installed on all supported ESXi hosts in the vCenter Server inventory where the appliance is deployed. The VIB creates a firewall rule, Replication-to-Cloud Traffic, that opens TCP ports 10000 to 10010 for outgoing traffic. However, the automatic installation of the VIB file might fail due to network issues in your environment. When the firewall rule is missing on the source ESXi hosts, outgoing replications to cloud remain in Not Active state.

    Workaround: Install the vSphere Replication VIB file on each ESXi instance that hosts a cloud replication source VM.

    1. Temporarily disable the firewall on the ESXi host.
    2. Establish an SSH connection to the ESXi Server.
    3. Run the following command:
      $ esxcli software vib install -v https://VR_APPLIANCE_IP:8043/vib/vr2c-firewall.vib
    4. Enable the firewall on the ESXi host.
  • Incoming replications from cloud remain in Not Active state

    If, in your vCloud Air inventory, you have a virtual machine that has disks of size not equal to whole Megabytes, for example 104.56 MB as opposed to 104 MB, and, at your local site, you configure a replication from cloud or a reverse replication for that VM, the replication appears in the Incoming Replications list, but remains in Not Active state.

    The problem is observed because the disk size that the cloud system reports is rounded down.

    Workaround:

    1. At your local site, stop the replication from cloud that appears as Not Active.
    2. In vCloud Air, locate the virtual machine and open its properties.
      The disk size is rounded down. For example, the disk size for a 104.56 MB disk appears as 104 MB.
    3. Increase the disk size by one MB.
      For example, for a 104.56 MB disk change the size from 104 MB to 105 MB.

  • The network configuration of replication source VM is mirrored when a replication is configured, but only partially updated after that

    By default, when you configure a virtual machine for replication to cloud, its NICs and MAC addresses are copied automatically to the target site as part of the provisioning of the placeholder virtual machine. If, after the provisioning of the placeholder VM, you update the NICs on the replication source VM, the NICs on the target site are updated. However, if you update the MAC address of a NIC on the source VM, the address of the placeholder VM on the target site is not updated. The MAC addresses of newly-added NICs are not copied to the target VM, either.

    Workaround: None.

  • Planned migration or synchronization fails with error: A replication error occurred at the vSphere Replication Server.

    If, during planned migration, the infrastructure (hosts, network, or storage) is under heavy load, running a planned migration 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): Class: NFC Code: 10; NFC error: The operation completed successfully; Set error flag: retriable; ...'
    Usually, this error is transient and the operation succeeds if you retry running it.

    Workaround: If the error occurs frequently in your environment, you can increase the toleration period for replication synchronizations on the vSphere Replication Management Server (VRMS).

    1. Log in to the VRMS appliance as the root user and navigate to /opt/vmware/hms/conf/.
    2. Open the hms-configuration.xml file for editing and set the value of the hms-sync-replication-error-toleration-period property to 300000.
    3. Try running the planned migration task again.

  • All operations on a seed vApp in vCloud Air are disabled

    If you configure a replication to cloud and select a vApp from the vCloud Air inventory to be used as a replication seed, all operations on the seed vApp are disabled.

    Workaround: None. Replication seeds cannot operate as virtual machines. A seed vApp can be used for only one replication.

  • You cannot disable the automatic mirroring of source VM NICs and MAC addresses to the target site

    When you configure a virtual machine for replication to cloud, its NICs and MAC addresses are copied automatically as part of provisioning the placeholder VM on the cloud site.
    If the test network is not isolated from the production network and the networks have common routing, a test recovery of the replicated virtual machine might result in duplicate MAC addresses in your virtual data center.

    Workaround: Use the vCloud Director UI to reset the MAC address of the replicated virtual machine. See Resetting the MAC Address of a Virtual Machine that is Replicated to Cloud (KB 2086292).

  • The network configuration of replication source VM is mirrored when a replication is configured, but only partially updated after that

    If, after the initial full sync, you update the NICs on the replication source VM, the NICs on the target site are updated. However, if you update the MAC address of a NIC on the source VM, the address on the target VM is not updated. The MAC addresses of newly-added NICs are not copied to the target VM, either.

    Workaround: None.

Documentation Issues

  • The vSphere Replication Administration guide is updated with new information.
  • For a list of the documentation enhancements, see Updated Information.

  • The vSphere Replication for Disaster Recovery to Cloud guide is updated with new information.
  • For a list of the documentation enhancements, see Updated Information.

Some Super Hot Topic

Quisque cursus enim sem. Curabitur faucibus, odio a lobortis fringilla, sapien nibh auctor urna, vel pharetra dolor diam sed purus. Proin pulvinar nulla in vulputate tempor.

Some Super Newest KB's

Quisque cursus enim sem. Curabitur faucibus, odio a lobortis fringilla, sapien nibh auctor urna, vel pharetra dolor diam sed purus. Proin pulvinar nulla in vulputate tempor.

Some Super Most Helpfull

Quisque cursus enim sem. Curabitur faucibus, odio a lobortis fringilla, sapien nibh auctor urna, vel pharetra dolor diam sed purus. Proin pulvinar nulla in vulputate tempor.