VMware vSphere Replication 5.1.3.x Release Notes
VMware vSphere Replication 184.108.40.206a | 07 APR 2016
VMware vSphere Replication 220.127.116.11 | 15 OCT 2015 | Build 3002922
VMware vSphere Replication 5.1.3 | 04 DEC 2014 | Build 2318240
Last updated: 07 APR 2016
Check for additions and updates to these release notes.
For information about the vSphere Replication 18.104.22.168a patch release, see vSphere Replication 22.214.171.124a Patch Release (KB 2144958).
For information about the vSphere Replication 126.96.36.199 patch release, see Site Recovery Manager 188.8.131.52 Express Patch Release (KB 2112012).
What's in the Release Notes
These release notes cover the following topics:
What's New in vSphere Replication 5.1.3
VMware vSphere Replication 5.1.3 adds the following improvements.
- Support for the following databases:
- SQL Server 2014
- Oracle 12C
- Bug fixes described in Resolved Issues.
VMware vSphere Replication 5.1.3 is available in the following languages:
- Simplified Chinese
Installation and Upgrade
See Installing vSphere Replication for information on installing vSphere Replication.
When updating vSphere Replication to version 5.1.3, see http://kb.vmware.com/kb/2037630 for the patch update sequence for vSphere 5.1 and its compatible VMware products. To upgrade vSphere Replication to 5.1.3, you must first upgrade its vCenter Server to at least version 5.1. See the interoperability matrix for further information on supported versions.
See Upgrading vSphere Replication for information on upgrading the appliance. vSphere Replication supports the following upgrade paths:
- vSphere Replication 5.1.1 to vSphere Replication 5.1.3
- vSphere Replication 184.108.40.206 to vSphere Replication 5.1.3
- vSphere Replication 5.1.0 to vSphere Replication 5.1.3
- Site Recovery Manager 5.0.1/vSphere Replication 1.0.1 to vSphere Replication 5.1.3.
- Site Recovery Manager 5.0.2/vSphere Replication 1.0.2 to vSphere Replication 5.1.3.
- Site Recovery Manager 5.0.3/vSphere Replication 1.0.3 to vSphere Replication 5.1.3. See Upgrade vSphere Replication in Site Recovery Manager Installation and Configuration.
The upgrade URL for upgrading the vSphere Replication appliance to version 5.1.3 via the virtual appliance management interface (VAMI) is:
IMPORTANT: Do not select the option in Update > Settings in the VAMI to automatically update vSphere Replication. If you select automatic updates, VAMI updates vSphere Replication to the latest 5.x version, which might be incompatible with vCenter Server 5.1.x. Leave the update setting set to No automatic updates.
You do not need to wait for a full synchronization to complete when you update vSphere Replication. When you update vCenter Server and vSphere Replication at the primary site, the source host continues to send replication data to the secondary site. When you update the secondary site, synchronization stops temporarily while the vSphere Replication server is updated and then resumes automatically.
Operational Limits for vSphere Replication
The operational limits of vSphere Replication 5.1.3 are the same as for vSphere Replication 5.1. See http://kb.vmware.com/kb/2034768.
Open Source Components
The copyright statements and licenses applicable to the open source software components distributed in vSphere Replication 5.1.3 are available at the vSphere Downloads site. You can also download the source files for any GPL, LGPL, or other similar licenses that require the source code or modifications to source code to be made available for the most recent generally available release of vSphere Replication.
Caveats and Limitations
vSphere Replication has certain operational limits. To ensure successful virtual machine replication, you must verify that your virtual infrastructure respects certain limits before you start the replication.
- vSphere Replication appliance and vSphere Replication server appliances are subject to Novell Security Advisory CVE-2008-5161
Novell Security Advisory CVE-2008-5161 relates to the SUSE Linux Enterprise Server (SLES) SP1, the operating system for the vSphere Replication appliance and vSphere Replication server appliances. Novell states in the advisory document at http://support.novell.com/security/cve/CVE-2008-5161.html that the security risks are low. If necessary, to further mitigate the security risks, you can follow the Novell advisory to modify your SSH configurations. For the vSphere Replication appliance and vSphere Replication server appliances, you can retain just the AES ciphers by adding the following directive in the sshd_config and ssh_config files:
Disable RC4 and all other CBC ciphers, including arcfour256, arcfour, aes128-cbc, and aes256-cbc.
- If you use the vCenter Server Appliance, updating the vCenter Server Appliance might make the vSphere Web Client inaccessible. See vCenter Server 5.1.0a Release Notes for details.
Workaround: Reboot the vCenter Server appliance.
- Updating vSphere Replication might lead to a timeout exception when logging into the vSphere Web Client for the first time after the update to vSphere Replication 220.127.116.11. See Known Issues in the vSphere Web Client release notes for details.
Workaround: Log out of the vSphere Web Client after the update, clear the cache of your browser, and log in again.
- You can only deploy one vSphere Replication appliance on a vCenter Server instance. Deploying more than one vSphere Replication appliance is not prohibited, but might lead to unexpected results.
- Each vSphere Replication management server can manage a maximum of 500 replicated virtual machines.
- vSphere Replication supports a maximum disk size of 2032GB.
- vSphere Replication does not support upgrading the VMware Tools package in the vSphere Replication appliance.
- The vSphere Replication appliance does not need the rpcbind service, so it is disabled in this release.
The following issues have been fixed in this release.
- NEW A vulnerability in the glibc library allows remote code execution
Your vSphere Replication appliance might be impacted by a vulnerability in the glibc that allows remote code execution.
This issue is fixed.
- Recovery fails when there is an inactive datastore at the secondary site. This datastore can be any datastore other than where the virtual machine is failing over and the server throws exception:
This problem has been fixed and the server no longer throws the exception.
- If the datastore and datacenter names contain unexpected characters such as "&" then recovery fails.
This problem has been fixed and recovery is successful.
- Upgraded OpenSSL Library
The OpenSSL library has been upgraded from 0.9.8 to 0.9.8zb and from 1.0.0 to 1.0.0n. See the OpenSSL security advisory at https://www.openssl.org/news/secadv_20140806.txt for information about the issues that these updates resolve.
- If multiple hosts access a datastore, vSphere Replication shows the datastore multiple times in the vSphere Web Client when configuring replication for a virtual machine.
This issue is fixed.
- Replication fails due to error "Unable to determine the controller type for disk '[datastore name] VM Name/VM Name.vmdk'. Disk file not found."
vSphere Replication ignores the controller type of virtual RDM disk and returns a static value. This error no longer occurs.
- vSphere Replication cannot create an image for a replication instance because another image already exists.
VRMS does not receive a response from the vSphere Replication server and assumes that the operation has failed. Subsequent attempts to create a test image fail because the image is already present in the vSphere Replication server database. The server incorrectly reports as
NullPointerException as the image is not present in the VRMS database. vSphere Replication throws
This problem has been fixed in this release.
- Newly added remote site does not appear on local site when paired at remote site in the same session.
This issue is fixed.
- vSphere Replication reports "Datastore is not accessible" for datastores at a host added to vCenter Server inventory while registering vSphere Replication server.
vSphere Replication selects all supported hosts from vCenter inventory and enables them as part of vSphere Replication registration. If you add a host to vCenter while vSphere Replication is still being registered, vSphere Replication does not select this host and it cannot access datastores on the recovery site.
This problem has been fixed.
- EULA content in the OVF deploy wizard displays corrupted characters on Internet Explorer 8 and 9 when you deploy vSphere Replication on localized operating systems.
Workaround: This no longer occurs.
- Recovering a virtual machine with vSphere Replication 5.1 fails to power on the recovered virtual machine.
If a replicated virtual machine is attached to a distributed virtual switch and you attempt to perform a recovery in an automated DRS cluster, the recovery operation succeeds but the resulting virtual machine cannot be powered on.
This has been fixed.
- Recovery does not start.
In rare cases, recovery might not start after you complete the Recovery wizard. Clicking Finish closes the wizard, but no recovery task begins.
This problem has been fixed.
- Deploying the vSphere Replication results in an invalid target datastore error.
Deploying the vSphere Replication by using OVF Tool or the vSphere Web Client results in an error if the target datastore is in a folder. The error message is
Invalid target datastore specified (vim.Datastore:datastore).
This error has been fixed.
- vSphere Replication recovery fails with
Error creating test bubble image for group ... The detailed exception is
Error while getting host mounts for datastore:<managed-object-id>... or
The object has already been deleted or has not been completely created.
If you run a test recovery or a planned recovery and the recovery plan fails with the specific exception, the LUN used for storing replication data has been temporarily disconnected from ESXi. When reconnected, replication continues as normal and no replication data is lost. The exception occurs during these scenarios:
- vSphere Replication cannot locate the LUN as the LUN has changed its internal ID.
- The target datastore internal ID changes when the host containing the target datastore is removed from vCenter inventory and later added.
This exception no longer occurs.
- Synchronize virtual machine operation fails with vSphere Replication generic error: The requested instance with Id=<...> was not found on the remote site.
Although the operation reports failure, the virtual machine state is successfully synchronized to the target site. This error can occur when you request a synchronize operation.
This error no longer occurs.
- 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 an hour or more 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.
This delay has been fixed.
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.
- 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 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.
- If you change the vCenter Server certificate, then log into vSphere Replication, you might see CannotVerifyCredentialsFault.
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:
Workaround: Power off and power on the vSphere Replication appliance.
- 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 error:
VRM Server generic error. Check the documentation for any troubleshooting information.
The detailed exception is: HMS can not set disk UUID for disks of VM : MoRef:
type = VirtualMachine, value = , serverGuid = null'.
- While generating support logs, the VAMI displays a syntax error and exception.
If you use the VAMI to generate a vSphere Replication support bundle, you might see the following error:
Uncaught Exception: ... syntax error.
Workaround: Open the VAMI in a new browser window and click Generate.
- Configuring replication with vSphere Replication fails if the virtual machine contains two disks on different datastores.
See KB 2012610
- 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.