This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

vSphere Replication 8.8 | 21 SEP 2023 | Build 22436165 | Download

vSphere Replication Configuration Import/Export Tool 8.8 | 21 SEP 2023 | Build 22297628 | Download

Check for additions and updates to these release notes.

What's New

For interoperability with earlier or later releases of VMware vSphere, see the Compatibility Matrices for vSphere Replication 8.8.

For information about the features of vSphere 8.0 Update 2, see the vSphere 8.0 Update 2 documentation.

Localization

VMware vSphere Replication 8.8 is available in the following languages:

  • English

  • French

  • German

  • Italian

  • Japanese

  • Korean

  • Spanish

  • Simplified Chinese

  • Traditional Chinese

Product Documentation

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

Compatibility

vSphere Replication 8.8 is compatible with vSphere 7.0 Update 3 and later, and supports ESXi versions 7.0 Update 3 and later.

For interoperability and product compatibility information, see the Compatibility Matrices for vSphere Replication 8.8.x.

Installation

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

For vCenter Server to vCenter Server replications, the version of the vSphere Replication Management server on the source and the target site can be 8.7 or 8.8.

vSphere Replication 8.8 requires a supported vCenter Server version on both the source site and the target site. For more information, see VMware Product Interoperability Matrices.

Upgrading vSphere Replication

You use the ISO file and the VRMS Appliance Management Interface to upgrade from vSphere Replication 8.6.x or 8.7.x to vSphere Replication 8.8.

You cannot upgrade vSphere Replication from versions earlier than 8.6 to version 8.8 by using the Virtual Appliance Management Interface (VAMI). See the compatibility matrices 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 the Upgrade and General sections under Known Issues.

See Upgrade Additional vSphere Replication Servers and Upgrade the vSphere Replication Appliance for the procedures on upgrading to vSphere Replication 8.8.

Notes:

  • When you use vSphere Replication with Site Recovery Manager, upgrade vSphere Replication on both of the protected and the recovery sites before you upgrade the Site Recovery Manager Server. After upgrading vSphere Replication, you must restart the Site Recovery Manager Server. For more information, see the VMware Site Recovery Manager Documentation.

Operational Limits of vSphere Replication

The operational limits of vSphere Replication 8.8 are documented in the VMware Knowledge Base. See Operational Limits for vSphere Replication 8.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 8.х and Configuring Upgraded vSphere Replication Appliances to Support up to 4000 Replications.

Open Source Components

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

Caveats and Limitations

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

  • In a federated environment with linked vCenter Server instances, when you log in to the REST API gateway local site this will automatically log you in to the remote site. You do not have to make a POST /remote-session request. It is not possible to log in to the remote site with a different user name.

  • The hms-db-max-connections property value is automatically updated from 99 to 149 during the upgrade to vSphere Replication 8.8. To preserve a custom value, you must change it manually after the upgrade.

  • vSphere Replication 8.8 does not provide support for Federal Information Processing Standards (FIPS).

  • Resizing a replicated disk of a virtual machine by non-multiple of 512 bytes is not supported. If the disk is resized by non-multiple of 512 bytes, the replication fails. To return to the OK state, the disk size must be set to a multiple of 512 bytes.

  • vSphere Replication does not support the protection of virtual machines using persistent memory (PMem) devices.

  • vSphere Replication will stop working correctly if you run the vSphere Prevent Guest Operating System Processes from Sending Configuration Messages to the Host procedure on the vSphere Replication Appliance.

  • vSphere Replication does not support single virtual machine protection with two replication technologies. If a virtual machine is protected with VMware Cloud Disaster Recovery, it cannot be protected with vSphere Replication.

  •  vSphere Replication 8.8 does not provide support bundle management in the VRMS Appliance Management Interface. This includes lists with support bundles and deleting support bundles. To manage the support bundles through SSH, establish an SSH connection to the vSphere Replication Appliance.

  • The 5 minute RPO scales to a maximum supported limit of 50 VMs on a provisional vVol datastore.

  • vSphere Replication does not support VSS quiescing on Virtual Volumes.

  • vSphere Replication cannot replicate virtual machines that share vmdk files.

  • 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 during the initial configuration process in the VRMS Appliance Management Interface. This requires user confirmation to proceed with the new appliance. This situation does not occur when deploying more than one vSphere Replication servers.

  • Each vSphere Replication Management Server can manage a maximum of 4000 replicated virtual machines. See Configuring Upgraded vSphere Replication Appliances to Support up to 4000 Replications (KB 2102463) and Requirements to the Environment... (KB 2107869).

  • vSphere Replication supports a maximum disk size of 62TB. If you attempt to activate 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 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.

  • vSphere Replication does not support VMware vSphere® Trust Authority™. vSphere Replication supports Standard Key Provider and VMware vSphere® Native Key Provider™.

  • When using the TRIM/UNMAP commands to reclaim space, if the UNMAP command is used at the source site, the replication traffic sends the command as a large stream of zeroes, unless compression is used on the replication. The data is stored as zeroes at the target site and space on the replica disks is not reclaimed.

Known Issues

Upgrade

  • New - Upgrade to vSphere Replication 8.8 fails with an error

    When you attempt to perform a chain upgrade from an earlier version of vSphere Replication, for example from version 8.3 to version 8.8, the upgrade might fail with an error: Operation Failed: Failed to install update.

    The logs located in /opt/vmware/var/log/vami/updatecli.log show the following:

    Error: Failed to synchronize cache for repo 'VMware Photon Linux 3.0 (x86_64)' from 'https://packages.vmware.com/photon/3.0/photon_release_3.0_x86_64'1. package xml-security-c-1.7.3-4.ph2.x86_64 requires libcrypto.so.1.0.0()(64bit), but none of the providers can be installed.

    The previous upgrades from Photon 2.0 to Photon 3.0 did not clean the packages properly causing the error in the upgrade procedure.

    Workaround: Before performing the upgrade check whether package xml-security-c exist. If the package exists, remove it.

    1. Revert the appliance before the update begins.

    2. Check if the xml-security-c package exist. Run the following command rpm -qa | grep ph2.

      The output will be similar to this:

      xml-security-c-1.7.3-4.ph2.x86_64
xerces-c-3.2.1-1.ph2.x86_64
openjre8-1.8.0.232-1.ph2.x86_64
libarchive-3.3.1-5.ph2.x86_64
apache-ant-1.10.1-7.ph2.noarch
libdnet-1.11-5.ph2.x86_64

    3. To remove the xml-security-c package, run the following command rpm -e xml-security-c-1.7.3-4.ph2.x86_64.

    4. Continue with the upgrade of the appliance.

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

General

  • New - vSphere Replication alarms are not visible in the alarm definitions

    vSphere Replication events might not be visible when adding an alarm definition in vCenter Server 8.0 and vCenter Server 8.0 Update 1.

    Workaround: Upgrade your vCenter Server instance to vCenter Server 8.0 Update 2.

  • New - DR REST API v.8.8. hits DR server session limit exceeded

    A bug in the DR REST API v.8.8 Rate Limiter tier Session prevents the DR server session to auto-close after a preconfigured timeout interval. The DR REST API client maintains a high number of DR sessions which results in exhaustion of the maximum possible number of DR server live sessions.

    Workaround: Switch off the DR REST API Rate Limiter tier Session by performing the following steps.

    1. Navigate to /opt/vmware/dr-rest/webapps/rest/WEB-INF/web.xml and comment out the following section.

      <!--
<filter>
   <filter-name>SessionRateLimitFilter</filter-name>
   <filter-class>com.vmware.dr.restapi.infrastructure.rateLimit.SessionRateLimitFilter</filter-class>
   <async-supported>true</async-supported>
</filter>
-->
...
<!--
<filter-mapping>
   <filter-name>SessionRateLimitFilter</filter-name>
   <url-pattern>/*</url-pattern>
</filter-mapping>
-->

    2. To close all live sessions, restart the DR service.

    3. Restart the DR REST API service to switch off the DR REST API Rate Limiter tier Session.

    4. Apply the workaround on all DR REST API instances of the server ecosystem.

  • New - After reconfiguring a replication to a vSAN ESA datastore, the replication gets stuck and cannot proceed

    Due to changes in ESXi version 8.0 Update 2 that affect the vSphere Replication Appliance 8.8, moving a replication to a target vSAN ESA datastore, regardless of the type of the source datastore, will cause the replication to get stuck as the disk hierarchy at the new location will become read-only. Any further write operations to these disks, coming from the source site of the replication, will fail.

    Workaround: Reconfigure the replication back to its original place or move it to a different datastore which is not vSAN ESA.

  • New - Planned migration and failover might fail with an error during the power on operation

    When performing a planned migration or test failover at 4000 scale, the operation might fail with the following error while powering on the virtual machine: "Unable to write VMX file: /vmfs/volumes/...vmx".

    Workaround: Rerun the failed recovery plan.

  • New - Changing the storage policy of a replication fails for an encrypted VM when the target datastore is vSAN or vSAN ESA

    If a replication uses a storage policy with vSAN storage attributes and virtual machine encryption, and then the replication is reconfigured to a storage policy without the vSAN storage attributes, the replication gets into an error state with the following message: 'Cannot apply policy to vSAN object <id> (status: 'failed'), fault: InvalidArgument, message: Non vSAN Profile' . This might happen in the workflows of configuring a replication with seeds, reversing a replication during a reprotect operation, or changing the storage policy during reconfigure replication.

    Workaround: Change the attributes of the new storage policy to use vSAN attributes.

  • New - Continuous HBR Agent VIB install errors in the vCenter Server tasks after upgrade

    After upgrading vCenter Server, if there are ESXi hosts in the inventory that are not managed by vSphere Lifecycle Manager, you might observe HBR Agent VIB install errors in the vCenter Server tasks view.

    Workaround: Reconfigure the vSphere Replication Management Server.

  • New - Failover or planned migration might fail due to storage errors

    At 4000 scale on the target datastore, the test failover or planned migration might fail with the following error: "Cannot create a failover image for group <GID> on vSphere Replication Server <server>. A problem occurred with the storage on datastore path <path>".

    Workaround: None.

  • New - Planned migration fails with an error

    If you trigger a replication sync, the replication might fail with the following error due to connectivity issues: "VR synchronization failed for VRM group 'VM Name'. A general system error occurred: VM has no replication group". Even though this might be a sporadic issue, the replication might not get back to an OK status automatically.

    Workaround: Reconfigure the replication of all the failed virtual machines.

  • Custom hms-db-max-connections property value is not preserved after vSphere Replication upgrade to version 8.8

    hms-db-max-connections property value is automatically updated in hms-configuration.xml during the upgrade to vSphere Replication 8.8. The value is changed from 99 to 149. The previously set custom value for this property is overridden after the upgrade.

    Workaround:

    If you want to preserve your old hms-db-max-connections property value, you must set it manually:

    1. Establish an SSH connection to the vSphere Replication Appliance.

    2. Open /opt/vmware/hms/conf/hms-configuration.xml file with any editor, modify the hms-db-max-connections property value and save the changes.

    3. Restart the HMS Service in the VRMS Appliance Management Interface or by establishing an SSH connection to the vSphere Replication Appliance and running the systemctl restart hms command.

  • The replication keeps the last error even though the latest status is OK

    The replication is in OKstatus, but the last error message "A replication error occurred at the vSphere Replication Server for replication <replication ID> "No connection to VR Server for virtual machine <vm name> on host <host IP> in cluster <cluster ID> in SDDC-Datacenter: Unknown" still exists on the Site Recovery user interface. This is because the events that provide the information that the replication is OK and that the error must be cleared are sent at the host level. As there are too many events in a short time, they are unproperly filtered and therefore lost.

    Workaround:

    1. In the vSphere Client, navigate to the vCenter Server instance.

    2. Select the Configure tab > Advanced Settings > Edit Settings.

    3. On the source site, configure a key-value to enable the config.vpxd.event.burstFilter.whiteList option. Events that should be included in the allowlist are: vim.event.UserLoginSessionEvent; vim.event.UserLogoutSessionEvent; hbr.primary.DeltaCompletedEvent; hbr.primary.NoConnectionToHbrServerEvent; hbr.primary.ConnectionRestoredToHbrServerEvent; hbr.primary.FSQuiescedDeltaCompletedEvent; hbr.primary.AppQuiescedDeltaCompletedEvent; hbr.primary.UnquiescedDeltaCompletedEvent.

    4. Restart the vmware-vpxd service for all changes to take effect.

  • Reprotect fails with the Unable to reverse replication for the virtual machine error

    During a reverse replication, vSphere Replication prepares the source virtual machine by removing its snapshots and collapsing disks. This task might take longer than expected and vSphere Replication constructs a reverse replication spec using a child disk. The following error appears: Unable to reverse replication for the virtual machine...

    Workaround: Retry the reprotect operation.

  • Reprotect from the vSAN datastore fails with an error

    In rare cases, the vSphere Replication reprotect operation might fail with the error message Unable to reverse replication for the virtual machine '<VM_name>'. Permission to perform this operation was denied when attempting to create a seeds directory on a vSAN datastore.

    Workaround:

    1. Restart the management services on the designated host and retry the reprotect operations. See Restarting the Management agents in ESXi (KB 1003490).

    2. Reboot the host if needed and retry the reprotect operations.

    3. Unconfigure and configure replications on the failing virtual machines if needed.

  • Replication reconfiguration attempts fail with a TaskInProgress fault

    You might encounter a situation where a snapshot is created due to the enabled quiescing feature. If a reconfiguration attempt is made, it internally invokes the vim.HbrManager API, which might result in a TaskInProgress exception if a snapshot creation is still in progress.

    Workaround: Retry the reconfiguration operation.

  • Moving seed replica disks from different datastores into one datastore fails

    When you try to move seed replica disks with identical names from different datastores into one datastore, the process fails. Seed replica disks with the same names cannot exist in the same location.

    Workaround: Rename the seed replica disks before the move.

  • An unexpected error appears in the Summary tab if you have a second NIC, configured with a static route set

    If you have a second NIC and if you configured a static route set for it, the VRMS Appliance Management Interface cannot obtain an IP address from the second NIC. This might result in the following unexpected error in the IP Address for Incoming Storage Traffic field, under the Summary tab:

    The Storage Traffic IP address <IP_address> must match one of the NIC IP addresses.

    Workaround: The NIC is correctly configured and you can discard the error. You can verify if the replication traffic uses the correct IP address by running the following command: cat /etc/vmware/hbrsrv-nic.xml.

  • When you modify the VM disks configuration, the replication goes into an Error state

    When a VM is part of an ongoing replication, and you modify the VM storage configuration (add, delete, or resize disks), this action starts a replication reconfiguration task. If another reconfiguration operation is already in progress on this replication, the replication might fall into an Error state with an error. For example, "Invalid configuration spec. Some disks are not specified for replication, nor excluded." error.

    Workaround: Manually reconfigure the replication.

  • If you reconfigure a replication to assign a new storage policy to replicated virtual disks that are not targeted to a vSAN target datastore, the policy is not applied to the replica disks at the target site

    The storage policy is applied to the replica disks at the target site at the time you first configure or recover a replication. If you reconfigure the replication with a new storage policy, and the replicated virtual disks are not targeted to a vSAN target datastore, the change is not automatically reflected in the pair site.

    Workaround:

    1. Recover the virtual machines with reconfigured replication.

    2. By using the vSphere Client, change the storage policy of the recovered virtual machines to the new policy.

    3. Unregister the recovered virtual machines from the vCenter Server inventory.

    4. Configure replication again by using seeds and with the new storage policy.

  • A replicated VM becomes unresponsive or cannot serve network requests

    During a vSphere Replication sync operation, the VM disk I/O blocks for the duration of the sync. The vSphere Replication filter driver fails the SCSI UNMAP commands during a sync operation, if these commands override the transfer of the current replica disk to the target site.

    Workaround: Allow vSphere Replication to accommodate the UNMAP commands.

    1. Establish an SSH connection to the source ESXi Server.

    2. Run the following command:

    esxcli system settings advanced set -o /HBR/DemandlogFailCollidingUnmap -i 0

    The command takes immediate effect and you don't need to perform a system reboot.

  • Reprotect fails with an error

    When you are replicating virtual machines at a large scale, reprotect might fail with the following error:

    "Unable to reverse replication for the virtual machine A generic error occurred in the vSphere Replication Management Server "java.net.SocketTimeoutException: Read timed out"

    Workaround:

    1. Establish an SSH connection to the vSphere Replication Appliance.

    2. Run the following command:

      /opt/vmware/hms/bin/hms-configtool -cmd reconfig -property hms-default-vlsi-client-timeout=15

    3. Restart the HMS service.

  • The replication goes into Error state when you both remove and add disks to the source VM.

    Auto include new disks option is activated. If you edit the settings of the VM and both remove one of the disks and add а new disk in a single task, the replication might go into Error state.

    Workaround 1: Reconfigure the replication manually in the Site Recovery UI.

    Workaround 2: When you modify the VM, add and remove new disks with two separated tasks

  • Automatic replication does not start when a disk is replaced on the same SCSI device

    Auto replication new disks is activated. When in a single step you both remove and add protected disk on the same SCSI device, the replication goes into an Error state:​

    The set of disks on the vSphere Replication Server does not match the source set for replication '<vm name>'.

    Workaround 1: Replace disk with two separated configuration operations.

    Workaround 2: If you replaced the disk on the SCSI device with a single configuration operation, reconfigure the replication.

  • If you try to run a sync operation after disk resizing, the operation fails.

    If you perform disk resizing, depending on the size of the disk, the operation might take up to a few hours. When you try to run a sync operation in the meantime, the operation fails, even if the replication is in OK state.

    Workaround: Wait for the disk resizing operation to complete. You can verify the completion by checking the /var/log/vmware/hbrsrv.log log file, where you should be able to see this entry:

    Resizing disk <replicated disk ID>

  • The recovery of a replication of a VM, encrypted with vSphere Native Key Provider, fails

    If you remove from the cluster, which is configured with Native Key Provider, all hosts to which the target datastore is attached, the existing replications remain in OK state. However, if you try to perform а recovery, the recovery fails and the replication goes into Error state.

    Workaround: Make the datastore accessible in the cluster again. If you did not attempted recovery and the replication is still in OK state, reconfigure the replication and change the target datastore to a datastore, which is accessible in the cluster.

  • Newly added virtual disk is not replicated upon reprotect operation

    If you perform recovery and add a new disk to the recovered VM, the new disk is not replicated upon reprotect operation. The new disk is not automatically replicated if the initial replication was configured to automatically replicate new disks either.

    Workaround: Manually include the new disk to the replication.

  • Recovery operation does not progress

    If, within a short period of time, you exclude a virtual disk with a vVOL target datastore from the replication, and then incluce it again, this might affect a subsequent recovery operation. If you attempt to perform the recovery, it might not progress.

    Workaround 1

    If you already started the recovery operation:

    1. Remove the replication, retaining the replica disks.

    2. Configure the replication again, using seeds.

    3. Perform recovery.

    Workaround 2:

    If you have not yet started the recovery operation:

    1. Exclude the disk with a vVOL target datastore.

    2. Sync the replication.

    3. Include the disk again.

    4. Perform recovery.

  • Replication sync does not progress

    If, within a short period of time, you exclude a virtual disk with a vVOL target datastore from the replication, and then incluce it again, this might affect a subsequent replication sync operation. If you attempt to perform a replication sync, it might not progress.

    Workaround:

    1. Exclude the disk with a vVOL target datastore.

    2. Sync the replication.

    3. Include the disk again.

  • When you attempt to configure IPv6 through the VMware VRMS Appliance Management you receive an invalid property - dns error

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

    Workaround:

    SSH to the vSphere Replication Appliance host machine and run $netmgr ip6_address --set --interface --dhcp 0 --autoconf 1.

    To receive an IP address through DHCP run $netmgr ip6_address --set --interface --dhcp 1 --autoconf 1.

  • You cannot reconfigure the IPv6 settings through the VMware VRMS Appliance Management

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

    Workaround:

    SSH to the vSphere Replication Appliance host machine and run $netmgr ip6_address --set --interface --dhcp 0 --autoconf 1.

    To receive an IP address through DHCP run $netmgr ip6_address --set --interface --dhcp 1 --autoconf 1.

  • Reconfiguring a replication fails after removing and then adding the same disk to a different Virtual Device Node on the source VM

    If you remove a virtual disk and add a new one with the same VMDK file, and then you try to perform a manual or an automatic (if you activated the Auto include new disks option) reconfiguration of the replication, the process fails with the following error:

    Cannot reconfigure replication group '<VM_ID>' (managed object ID: 'GID-<group-ID>'). Details: 'Duplicate key (hms.Disk) { dynamicType = null, dynamicProperty = null, deviceKey = <DEVICE_KEY>, destination = (hms.ExtendedDatastorePath) { dynamicType = null, dynamicProperty = null, datastore = MoRef: type = Datastore, value = <DATASTORE>, serverGuid = null, path = <PATH>, fileName = <FILENAME>, dsCluster = null }, storageProfileId = null, useOfflineCopy = false, virtualDiskType = thin, skipDiskUuidValidation = true, replicationDiskId = null, contentId = null, capacityInKb = <CAPACITY> }'. ThrowableProxy.cause The operation is not allowed in the current state.

    Workaround

    1. Stop the replication and preserve the replica disks.

    2. Configure the replication again by using the disks as seeds.

  • Configuring replication fails after switching from vSphere Trust Authority to KMS as an encryption mechanism

    If you are using vSphere Trust Authority as an encryption mechanism, but switch back to the old encryption mechanism using KMS servers, and then try to configure a replication, the process might fail. The problem is observed, because the encryption keys might not be properly distributed to the target hosts, after switching the encryption mechanisms.

    Workaround: Restart the HMS service.

  • Test recovery fails with an error

    If you configure a replication to a VMFS datastore and then reconfigure any disk of this group to be replicated to a vSAN datastore (while the VM home is still configured to a VMFS datastore), when you try to perform a test recovery, it fails with the following error:

    Cannot create a test bubble image for group '<group-ID>' on vSphere Replication Server...

    Workaround 1: Reconfigure all replica disks back to using a VMFS datastore.

    Workaround 2: Reconfigure the VM home to be replicated to a vSAN datastore.

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

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

    Workaround: From the Options menu in Mozilla Firefox, select the Content tab and add the URL of the vCenter Server to the Pop-ups exception list.

  • Configuring a replication that uses seeds on a vVol target datastore succeeds, but the replication is in Error state

    If you configure a replication to use as a seed a VM that has snapshots, the configure operation succeeds, but the replication goes into the Error state at the end of the Initial Full Sync. An issue with a similar error description appears:

    A replication error occurred at the vSphere Replication Server for replication 'vmname'. Details: 'Error for (datastoreUUID: "vvol:9148a6192d0349de-94149524b5f52bc4"), (diskId: "RDID-fd3ed4de-2356-43c7-a0e2-7bc07a7da012"), (hostId: "host-33"), (pathname: "vmname/vmname.vmdk"), (flags: retriable): Class: NFC Code: 10; NFC error: NFC_DISKLIB_ERROR (Input/output error); Set error flag: retriable; Can't write (multiEx) to remote disk; Can't write (multi) to remote disk'.

    Workaround: Delete the snapshots from the seed VM.

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

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

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

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

  • 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 Site Recovery user interface 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.

  • The option to activate quiescing is deactivated 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 activated 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.

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

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

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

  • 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/jre-vmware/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

  • You cannot move a replication to another server

    If you run vSphere Replication 8.7 on your local site and vSphere Replication 8.6 on your remote site, and you try to move a replication to a different server, the process fails with the following error:

    Cannot complete the operation due to an incorrect request to the server

    Workaround 1: When you are moving the replication, specify a target replication server in reconfigure wizard.

    Workaround 2: Upgrade the target site to the same version as the local site.

  • Configure and reconfigure replication processes fail with an error

    When you try to configure or reconfigure a replication with seed disks, a vSAN target datastore and a VM Encryption Policy storage policy, the process fails with an error:

    A generic error occurred in the vSphere Replication Management Server. Exception details: Cannot apply policy to vSAN object 'xxx' (status: 'failed', fault: InvalidArgument, message: Non vSAN Profile)

    This error occurs because it is not possible to apply storage profiles without at least one vSAN rule to vSAN objects.

    Workaround 1: Use a predefined storage policy, for example Management Storage policy - Encryption.

    Workaround 2: Create a custom storage policy that contains at least one vSAN rule.

  • Configuring a replication to a newly registered VM fails with an error

    If after performing a successful failover, you remove the recovered VM and then re-register it, when you attempt to configure a replication for this VM, the process fails with the following error:

    VM ‘<VM_ID>’ was recovered in optimized reprotect mode in another replication group. To configure new replication for the VM, you must first remove the existing recovered replication.

    Workaround: Deactivate vSphere Replication on this VM. See https://kb.vmware.com/s/article/2106946.

  • You cannot encrypt an unencrypted source VM in an active replication

    If you try to encrypt an unencrypted virtual machine in an active replication configuration, the encryption fails.

    Workaround: Recover the unencrypted virtual machine and configure a new replication with encrypted seed disks.

    1. Recover the VM on the remote site, but do not power the VM on.

    2. Remove the replication of the source VM.

    3. Edit the settings of the VM on the target site and change the VM storage policy to VM Encryption Policy.

    4. Edit the settings of the source VM on the source site and change the VM storage policy to VM Encryption Policy.

    5. Unregister the recovered virtual machine on the target site, but do not delete the disks.

    6. Configure a new replication and select the disks of the recovered VM on the target site as seeds.

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

  • Recovering a virtual machine with vSphere Replication 8.8 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.

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