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.
The copyright statements and licenses applicable to the open source software components distributed in vSphere Replication 5.1.0 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.
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.
The following known issues have been discovered through rigorous testing and will help you understand some behavior you might encounter 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.
Workaround: See KB 2144289
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.
- vSphere Replication cannot access datastores through hosts with multiple management virtual NICs and posts DatastoreInaccessibleEvent in vCenter Server: vSphere Replication cannot access datastore.
If a host is configured with multiple virtual NICs and you select more than one NIC for management traffic, vSphere Replication registers only the first NIC and uses it to access target datastores. If the vSphere Replication server address is not on the first management network of the host, vSphere Replication does not communicate with the host.
Workaround: Use a host with a single virtual NIC selected for management traffic for datastores at the secondary site. You can also reconfigure the host networking so that the address of the first management virtual NIC is from a network that vSphere Replication can access.
- DB2 Databases require system temporary tablespace with 16K page size
If you use vSphere Replication with a DB2 database, vSphere Replication requires system
temporary table space with at least 16K page size.
If DB2 does not provide system temporary table space with at least 16K page size,
configuring vSphere Replication with an external DB2 database fails.
The virtual appliance management interface (VAMI) shows the following error:
Error applying startup configuration: Please check the provided DB information.
The /opt/vmware/hms/logs/hms-configtool.log file in the vSphere Replication
appliance contains the following error message:
ERROR com.vmware.hms.configtool.App [main] (..hms.configtool.App) |
Error while configuring HMS, exit code DATABASE_ERROR
com.vmware.hms.configtool.ConfigToolException: Database requires further configuration:
Need system temporary tablespace with at least 16384 bytes pagesize.
The problem occurs only when you use a DB2 database.
- 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
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
- Newly added remote site does not appear on local site when paired at remote site in the same session.
If you have two remote sites A and B and you connect site A to site B on the remote site, you can see the connection between the sites at the remote location. If you are still logged into local site A, then either wait 5 minutes to see the connection on the local site or log out and log into the local site to see the remote site connection on the local site.
- 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.
You must manually reconfigure the replication to refresh the new ID.
Workaround: If the primary site is no longer available, contact VMware Support for instructions about adding a special configuration entry in the vSphere Replication appliance database that triggers an automatic fix of the changed internal datastore ID to allow recovery.
If the primary site is still available:
- In the vSphere Replication view, select a site, right-click a virtual machine and select Reconfigure.
- Click Next, and click Browse to change the location of the files on the datastore that has been disconnected and then reconnected, and select the same datastore and folder locations as before.
- Reuse the existing disks and reconfigure the replication of the virtual machine. The vSphere Replication management server picks up the changed datastore identity (managed object ID) in vCenter Server.
- Wait for the initial sync to finish. This sync uses existing disks and checks for data consistency.
- 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.
Workaround: Disconnect and reconnect the host in the vCenter inventory for vSphere Replication to enable it.
- 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.
Workaround: Rerun the failed operation.
- 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: Use Mozilla Firefox or Google Chrome.
- 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.
Workaround: Wait for the registration task to complete. After it finishes, you can use vSphere Replication for incoming replication traffic.
- 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.1 fails to power on the recovered virtual machine.
If a replicated virtual machine is attached to a distributed virtual switch and you attempt to perform a recovery in an automated DRS cluster, the recovery operation succeeds but the resulting virtual machine cannot be powered on.
Workaround: Edit the recovered virtual machine settings to attach it to the correct network.
- 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.
Workaround: Run the recovery again.
- Performing a recovery by using the vSphere Replication interface fails with the error
Processing recovered virtual machine ... configuration file failed ... Http request failed: org.apache.http.conn.HttpHostConnectException: Connection to https://vCenter_Server_hostname refused.
When vCenter Server is installed with a custom port for HTTPS, for example port 444, recovery fails when trying to update the replicated the VMX file.
Workaround: During recovery, temporarily set up port forwarding between port 443 and the custom HTTPS port of vCenter Server.
- 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).
Workaround: Deploy vSphere Replication on a datastore that is not in a folder, or use the vSphere Client instead of the vSphere Web Client to deploy the vSphere Replication OVF.