There are no vSphere Replication 5.5.2 or 5.5.3 releases to correspond with the vCenter Server 5.5u2 and 5.5u3 releases. vSphere Replication 5.5.1.x has been fully tested with and fully supports vCenter Server 5.5u1, 5.5u2, and 5.5u3.
To upgrade vSphere Replication to 5.5.1, you must first upgrade its vCenter Server to at least version 5.5. See the interoperability matrix for further information on supported versions. Once you have upgraded vCenter Server, see Upgrading vSphere Replication to upgrade vSphere Replication.
NEW IMPORTANT: vSphere Update Manager 5.5u3 is not supported. To upgrade vSphere Replication you must use either the downloadable ISO, or the virtual appliance management interface (VAMI) of the vSphere Replication appliance.
The operational limits of vSphere Replication 5.5.1 are the same as for vSphere Replication 5.1. See http://kb.vmware.com/kb/2034768.
The copyright statements and licenses applicable to the open source software components distributed in vSphere Replication 5.5.1 are available at the vSphere Replication Community.
To ensure successful virtual machine replication, you must verify that your virtual infrastructure respects certain limits before you start the replication.
The following issues have been fixed in this release.
The following known issues have been discovered through rigorous testing and will help you understand some behavior you might encounter in this release.
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: The permissions that are assigned to custom roles are not removed. Clone the predefined VRM roles and create your custom roles before upgrading the vSphere Replication appliance, or changing its certificate or IP address.
Updated vSphere Replication actions in vSphere Web Client are not available after upgrade
If you upgrade from vCenter Server version 5.1.x to version 5.5, and if you log in to the updated vSphere Web Client before you upgrade the vSphere Replication appliance to version 5.5.x, after the upgrade of the appliance replication actions through the vSphere Replication plug-in are not available.
Workaround: Restart the vSphere Web Client.
- If vCenter Server runs on Windows, restart the VMware vSphere Web Client service.
- If vCenter Server runs on Linux, establish an SSH connection to the vCenter Server system, log in as the root user, and run the following command:
service vsphere-client restart.
- X-vMotion of a virtual SAN virtual machine from a High Availability (HA) cluster might result in an alarm.
When you perform a X-vMotion of a virtual SAN virtual machine from HA cluster to a different cluster and to a different storage, the virtual machine reports an alarm similar to vSphere HA virtual machine failover failed.
- Replication fails between two vCenter Servers with different SSO containing non-ASCII characters.
If you have two vCenter Servers registered with different SSO, vSphere Replication fails to authenticate the username and password containing non-ASCII characters.
Workaround: Create a username and password in ASCII characters to authenticate or register the two vCenter Servers to the same SSO, then configure the replication.
- Connection status between two sites does not change to disconnected after you change the vSphere Replication certificate for one of the sites.
If you have two remote sites A and B and the status of the connection is Connected, if you change the certificate of the vSphere Replication appliance at site B, the connection status might not change to Disconnected. When invoking replication operations, vSphere Replication notifies you about the certificate problem.
Workaround: Log out and log in to the vSphere Web Client. Reconnect sites A and B.
- In rare cases, vSphere Replication displays a stale replication instance when the replicated virtual machine is deleted from the source site.
Attempting to stop the replication displays an error:
Unable to compute permissions. See the log for more details.
- If vFlash is enabled for a virtual machine on the source site, vSphere Replication disables it after recovery.
During replication, vSphere Replication does not check for or reserve vFlash resources on the target site and cannot guarantee that vFlash resources will be available for the virtual machine at the target site. If vFlash is configured, but vFlash resources are not available, the virtual machine fails to power on at the target site. To avoid this issue, vSphere Replication disables vFlash for the virtual machine during recovery.
Workaround: Manually re-enable vFlash for the virtual machine after the recovery.
- VRMS stops during recovery, replication operations fail, and no virtual machine is registered in the target vCenter Server.
Replication operations stall or fail with error:
VRM Server was unable to complete the operation.
Replica files are available in the target location ready to be registered as a virtual machine in vCenter Server without any vSphere Replication temporary files. If VRMS stops immediately after the vSphere Replication server prepares the virtual machine image from the replica files, VRMS might not update the database and the VR server is no longer aware of the recovered replication.
Management operations on the replication involving the vSphere Replication server immediately fail and block sync operations.
1. Manually move the replicated virtual machine image, the .vmx and .vmdk files, into another datastore folder.
2. Stop the replication in the vSphere Replication appliance.
3. Manually register the .vmx file of the replica image as a virtual machine in the target vCenter Server.
If you do not manually move the replicated virtual machine .vmx and .vmdk files, VRMS deletes the .vmdk files as it does not detect vSphere Replication server part of failover for the replication has already been performed.
- Certain vSphere Replication errors require reboot of the appliance.
You might encounter the following issues with vSphere Replication procceses:
vSphere Replication warns you with an alarm for CPU usage.
In vCenter Server -> Manage -> vSphere Replication -> Replication servers, the vSphere Replication server is listed with a disconnected status. Certain VRMS operations stall.
The VRMS logs contain error:
OutOfMemoryError: Java heap space
Workaround: Reboot the vSphere Replication appliance or restart VRMS service:
/etc/init.d/hms restart. Restart the disconnected vSphere Replication servers.
- Recovery wizard fails with error:
The source virtual machine has no instance available for recovery.
In vCenter Server -> Manage -> vSphere Replication -> Replication servers, the vSphere Replication server is listed with a disconnected status. The recovery wizard does not display the appropriate error message for the described situation, but message about the replica instance is not available.
Workaround: Resolve the connectivity between VRMS and the vSphere Replication server and try the recovery operation again.
- Replication status does not change from Configuring to Error and blocks recovery attempts.
If the primary site vSphere Replication Management Server (VRMS) becomes unavailable and cannot be restored while replication reconfiguration operation is in progress, the replication never shows an error state and recovery can not be initiated.
Workaround: Manually override the configuration state of the replication from Inprogress to Error in VRMS using the MOB interface and VRMS database. Contact VMware support for assistance.
- 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.
- 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.
- 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.
- Moving multiple replications from one vSphere Replication server to another results in error.
Reconfigure or move operations fail with "SocketTimeoutException: Read timed out" and replications go into the Error state. When the source or target vSphere Replication server and the storage are under heavy load, moving a replication can take more than a few minutes and result in the timeout error.
Workaround: Reconfigure the replication on the new vSphere Replication server.
- 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 is not available in an attempt to reconfigure replication if the connection to the target site is broken.
If you connected two sites and configured replication for a virtual machine between them, then changed the certificate of one of the vSphere Replication appliances with a new self-signed certificate, the connection between the sites must be repaired.
Workaround: Click reconnect at the target site and verify that the sites are connected before attempting the operation.
- Set of disks does not match error replication state after reconfiguring replication after adding a hard disk.
When you add a new disk to a replicated virtual machine and reconfigure replication to include the new disk for replication, the replication goes into full sync state as expected. In rare cases, the UI might show a disk mismatch error for the virtual machine while the full sync is in progress even though there is no error. After the full sync completes and an instance is created for the virtual machine, the error clears.
- During recovery, the popup for credentials to the source site does not display if sites have been paired from a different session.
When you use a different browser to pair sites and configure replication between them, then launch the Recover wizard from a different browser, instead of prompting you for credentials to connect to the site, vSphere Replication says the source site is unavailable.
Workaround: Log out of the vSphere Web Client and log in again. The credentials prompt appears.
- Replication stalls when you revert to a snapshot during a paused replication.
When you configure replication for a virtual machine and pause the replication, take a snapshot, then resume the replication and revert to the snapshot, instead of going into the paused state, the replication status in the UI does not change and makes no progress.
Workaround: Pause and then resume the replication.
- Replication goes into an error state when the virtual machine disk is greater than 2 TB and the target ESX host is a lower version than 5.5.
When you configure a replication for a virtual machine which has a disk that is larger than 2 TB, and the target ESX host that has access to the replica datastore is downgraded to a lower version, the replication goes into the Error state and you see an NFC error.
Workaround: None. When the source virtual machine has a disk that is larger than 2 TB, you must use ESX 5.5 version on the target site.
- 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.
- vSphere Replication VAMI is not accessible on Internet Explorer 8 and Chrome on Windows XP64 and Windows Server 2003. You see the error message described in Microsoft KB 968730.
Workaround: Use Firefox to access the VAMI. If Firefox is not an option, install the Microsoft hotfix on Windows XP and Windows Server 2003.
- ESXi host is limited when accessing particular disks.
A virtual machine with a disk larger than 62TB that has replication enabled blocks the power on functionality of that virtual machine.
vSphere Replication does not support replicating disks larger than 62TB. If you attempt to enable replication on a virtual machine with such a disk, the virtual machine will not perform any replication operation and will not power on.
- vSphere Replication returns error for VMK_STALE_FILEHANDLE.
If a vSphere Replication persistent state file is on an NFS volume and you remove that volume on the NFS server in such a way that the ESXi Server gets a stale file handle, vSphere Replication attempts to access the persistent state file forever and makes no progress.
Workaround: Commonly, the virtual machine is located on the same volume as the persistent state file and will also be inaccessible. If the virtual machine is not located on the removed NFS volume and is still accessible, unconfigure and reconfigure replication so that a new persistent state file is generated on new storage. Reconfiguring replication will result in a full sync.
- If you change the vCenter Server certificate, then log into vSphere Replication, you might see vSphere Replication Management Server is not accessible.
If you change the vCenter Server certificate you lose connectivity to vSphere Replication and when you try to log in to vSphere Replication you see this error:
vSphere Replication Management Server is not accessible.
Workaround: Power off and power on the vSphere Replication appliance.
- 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 replcation 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
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'.
- Configuring replication with vSphere Replication fails if the virtual machine contains two disks on different datastores.
See KB 2012610
- vSphere Replication server registration might take a long time depending on the number of hosts in the vCenter Server inventory.
If the vCenter Server inventory contains a few hundred or more hosts, the Register VR server task takes 10 to 20 minutes to complete, as vSphere Replication updates each host's SSL thumbprint registry. The vCenter Server Events pane displays Host is configured for vSphere Replication for each host as the vSphere Replication server registration task progresses.
Workaround: Wait for the registration task to complete. After it finishes, you can use vSphere Replication for incoming replication traffic. See also vSphere Replication Server Registration Takes Several Minutes.
- Recovering a virtual machine using the "Recover with latest available data" option is possible when the source virtual machine is powered on.
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. However, the network cards of the recovered virtual machine are disconnected when it powers on. 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.
Workaround: Ensure that the source virtual machine is powered off before you connect the recovered virtual to the network.
- Recovering a virtual machine with vSphere Replication 5.5 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.
- vSphere Replication service is inaccessible after vCenter Server certificate changes.
If the vCenter Server certificate changes during the upgrade to vCenter Server 5.5, vSphere Replication becomes inaccessible.
Workaround: See vSphere Replication is Inaccessible After Changing vCenter Server Certificate.
- 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.
If you are running vSphere Replication 5.5.x, upgrade to vSphere Replication 188.8.131.52. See Upgrading vSphere Replication in vSphere Replication Administration for instructions about updating vSphere Replication 5.5.x.
You can upgrade vSphere Replication by using a downloadable ISO image, or the virtual appliance management interface (VAMI) of the vSphere Replication appliances.