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

These release notes cover the following topics:

VMware vSphere Replication 8.3 is available in the following languages:

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

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:

For more information on installation, see 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 either 8.2 or 8.3.

You use the ISO file or the VAMI to upgrade to a major version of vSphere Replication, for example from 8.1 or 8.2 to 8.3.

You cannot upgrade vSphere Replication from version 6.5.1 to version 8.3 by using the official VMware Update Repository from the VAMI of the vSphere Replication appliance. 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.

Мake sure that you deploy the new vSphere Replication 8.3 OVF first. In the console of the newly deployed vSphere Replication appliance, make sure that you select the Upgrade Option.

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

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

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

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

Installation Notes

If you are running vSphere Replication 8.3.0.x, upgrade to vSphere Replication 8.3.0.2. See the Upgrading vSphere Replication in vSphere Replication Administration for instructions about updating vSphere Replication 8.3.x.x.

Installation Notes

If you are running vSphere Replication 8.3, upgrade to vSphere Replication 8.3.0.1. See the Upgrading vSphere Replication in vSphere Replication Administration for instructions about updating vSphere Replication 8.3.x.x.

After resizing a replicated virtual disk, the storage consumption might be increased for a long time. This might happen if you have configured a replication with MPIT retention policy that stores PIT instances for several days.

You try to remove an incoming replication, but the Retain replica disks check box is inactive. The check box might be inactive, if you have vSphere Replication 8.2 on the source site and vSphere Replication 8.3 on the target site.

Initial or full synchronization takes a very long time. This might happen if AsyncNFC is switched on.

After upgrading to vSphere Replication 8.3, the vSphere Replication appliance uses more CPU power than it was using before the upgrade.

The known issues are grouped as follows.

On upgrade of vSphere Replication to version 6.5, 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: 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.

After you upgrade the vCenter Server to version 7.0 and vSphere Replication to version 8.3, 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: Do one of the following.

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

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.

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

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.

1. Establish an SSH connection to the vSphere Replication Appliance. 2. Navigate to /opt/vmware/hms/conf/ . 3. Open hms-configuration.xml in a text editor and set the <hms-auto-install-hbragent-vib> value to true . 4. Restart the HMS service.

After upgrading from vSphere Replication 8.1 to version 8.3, you cannot use the network encryption feature.

Workaround: Remove the replication which is in error state and configure it again.

After you upgrade vSphere Replication 8.1.2.1 to vSphere Replication 8.3 and run Disaster Recovery while the source site is active, the replication might fall into an error state.

NEW VMware vCenter Server 7.0 and VMware vCenter Server 7.0.0b show an error that vSphere Replication 8.3 and Site Recovery Manager 8.3 are not compatible If you have vSphere Replication 8.3 installed on a vCenter Server 7.0 or a vCenter Server 7.0.0b, when you navigate to vCenter>Monitor Tab>vCenter Server>Interoperability, vSphere Replication 8.3 and Site Recovery Manager 8.3 are displayed as "No compatible version". Workaround: None. vSphere Replication 8.3 and Site Recovery Manager 8.3 are compatible as indicated in the interoperability matrix.

Reconfiguring a replication fails after changing the Virtual Device Node on the source VM If you change the Virtual Device Node settings on a replicated disk and then you attempt to reconfigure the replication, the process fails with the following error: Unable to complete the reconfiguration task at remote site for replication group '<VM_ID>' (managed object ID: 'GID-<group-ID>'): task 'HTID-<hms-task-ID>'. Details: 'A runtime error occurred in the vSphere Replication Management Server. Exception details: 'VR Server error: 'Error for (diskId: "RDID-<replica-disk-ID>"): SQLite error 19: UNIQUE constraint failed: ReplicatedDisk.diskID; Returned error message: UNIQUE constraint failed: ReplicatedDisk.diskID; Code set to: A disk with the given ID already exists.; Disk ID already in database!; Adding replica disk RDID-<replica-disk-ID> (groupID=GID-<group-ID>) to database; Adding disk RDID-<replica-disk-ID>; Adding disk info to database.'.'.'. Workaround: Reconfigure the replication in the Site Recovery UI and exclude the disk, whose Virtual Device Node settings you changed. Reconfigure the replication again and include the previously excluded disk.

Reconfiguring a replication fails with an error If you exclude a disk from a replication and then try to include it again, the reconfiguration fails with the following error: Unable to complete the reconfiguration task at remote site for replication group '<vm_id>' (managed object ID: 'GID-<group-id>'): task 'HTID-<hms-task-id>'. Details: 'Disk file name '<vm_id2>.vmdk' already exists. Workaround: Wait for a time period, which is greater than the RPO, after you exclude the disk, to be able to include it again. If you have enabled MPIT, you must wait until all replication instances, which contain references to the excluded disk, expire. Alternatively, you can manually delete the vmdk file from the destination datastore (you can see the name of the vmdk file in the error message.)

Instance archiving does not apply for all instances The instance archiving does not work for all instances, but only for the latest instance. This might happen if the retention policy is incorrectly applied. Workaround: 1. Establish an SSH connection to the vSphere Replication Server virtual machine.

2. Navigate to /etc/vmware .

3. Open hbrsrv.xml in a text editor, uncomment the property and change the <removeMPITsBeforeBaseDisks> value to false.

4. Restart the HBR service by using the command service hbrsrv restart .

Replications with network encryption appear 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 automatic installation of the VIB file might fail due to different reasons. Workaround: Install the vSphere Replication VIB file on each ESXi instance that hosts 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/vmware-hbr-agent.vib

4. Enable the firewall on the ESXi host.

You cannot configure new replications with network encryption 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 automatic installation of the VIB file might fail due to different reasons. Workaround: Install the vSphere Replication VIB file on each ESXi instance that hosts 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/vmware-hbr-agent.vib

4. Enable the firewall on the ESXi host.

Recovery operation fails with an error If you add a new disk to the source VM, which is configured for a replication with multiple points in time, and you try to run a recovery, the recovery fails with the following error: Group instance not found Workaround: 1. Establish an SSH connection to the vSphere Replication Server virtual machine.

2. Navigate to /etc/vmware .

3. Open hbrsrv.xml in a text editor and change the <removeMPITsBeforeBaseDisks> value to true.

4. Restart the HBR service by using the command systemctl restart hbrsrv .

5. If you have registered multiple vSphere Replication servers, repeat the steps to all the servers.

6. Re-run the recovery.

Importing or exporting replication configuration data with the vSphere Replication Import/Export tool fails with an error If you are using vSphere 6.5 with a vVol datastore and you try to import or export replication configuration data, the operation will fail with the following error: Unable to configure replication: A general system error occurred: Invalid fault Workaround 1: Use a different type of datastore, such as vSAN, VMFS or NFS.

Workaround 2: Upgrade to vSphere 6.7 or vSphere 7.0.

Replications change state to Not Active if you try to configure a replication to use both the network encryption and network traffic isolation features If you try to configure a replication to use both the network encryption and network traffic isolation features, the replication changes state to Not Active. For example, if you try to use network traffic isolation on the replication of encrypted virtual machines, where network encryption is not optional. Workaround: Until a future vSphere Replication release to enable the full use of both features, you can only partially combine network encryption and traffic isolation. For example, if you go to the settings of the VMkernel network adapters on the source host and switch off the vSphere Replication tags, the replication state changes to OK, and only traffic isolation of the outgoing traffic from the source site is disabled.

If the source VM for a replication runs on ESXi 6.7 or 6.7 Update 1, an initial or full synchronization might stop progress before completion The synchronization of replications for which the source VM is running on ESXi 6.7 or 6.7 Update 1 remains in progress, but the checksum bytes value in the replication details information does not progress. Operations such as powering off, taking a snapshot, reverting to a snapshot, and migrations fail with a timeout or Task in progress errors. Workaround: 1. In the ESXi Advanced settings, disable the checksum for vSphere Replication by setting HBR.ChecksumUseChecksumInfo = 0 . 2. Migrate all VMs and power off the ones that cannot be migrated on the ESXi host. 3. Place the host in maintenance mode. 4. Reboot the ESXi host. With these steps, you disable the checksum part of the sync process and all of the allocated blocks are sent to the remote site, regardless of whether they are different or not. Also, you cannot use seeds.

Generation of self-signed certificates of the vSphere Replication Appliance fails if a domain name starts with a number Generation of self-signed certificates of the vSphere Replication Appliance might fail if a domain name starts with a number, such as 888xxx. Workaround: To generate a Certificate Authority certificate for fresh deployments, follow the steps in VMware knowledge base article 2080395.

If the source VM for a replication runs on ESXi 6.7 or 6.7 Update 1, replication synchronization seems to be in progress, but the replication instance never completes successfully In ESXi 6.7 and 6.7 Update 1, it is possible that more demand log chunks be scheduled for parallel transfer than the actual number that can be transmitted. If you are replicating a VM that is running on such a host and this coincides with a slow target host or temporary network errors, this might result in replication failure with DiskQueue is full errors. Workaround: Move all the VMs to another ESXi host. Edit the value of the HBR.DemandlogTransferMaxNetwork ESXi Advanced setting to 63 instead of the default 64. Place the ESXi host in maintenance mode. Reboot the ESXi host.

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.

The Site Recovery UI becomes unusable showing a constant stream of 403 - OK error message The Site Recovery UI shows no data and an error 403 - OK. Workaround: 1. Log out from Site Recovery UI and log in again. 2. Disable the browser's 'Restore last session' checkbox. For Chrome disable the 'Continue where you left off' option.

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 .

file in the vSphere Replication Management server at the source site contains the following error message: . 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.

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.

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