VMware vCenter Site Recovery Manager 5.0.2 Release Notes
VMware vCenter Site Recovery Manager 5.0.2 | 20 DEC 2012 | Build 919478
Last updated: 21 OCT 2013
Check for additions and updates to these release notes.
What's in the Release Notes
These release notes cover the following topics:
VMware vCenter Site Recovery Manager 5.0.2 offers the following improvements:
- The vSphere Replication management server accepts MD5 certificates. See Caveats and Limitations.
- Upgraded OpenSSL 0.9.8m to 0.9.8t for improved security. This addresses the security advisory that was issued for OpenSSL in January 2012.
- Auto-generated certificates use RSA keys of 2048 bits.
- Bug fixes described in Resolved Issues.
VMware vCenter Site Recovery Manager 5.0.2 is available in the following languages:
- Simplified Chinese
SRM Compatibility Matrix
For the current interoperability and product compatibility information, please see the Compatibility Matrixes for VMware vCenter Site Recovery Manager.
Compatible Storage Arrays and Storage Replication Adapters
For the current list of supported compatible storage arrays and SRAs, please see the VMware Compatibility Guide.
VMware VSA Support
Virtual machines that reside on the vSphere Storage Appliance (VSA) can be
protected by SRM 5.0.2 using vSphere Replication. VSA does not require a Storage Replication Adapter (SRA) to work with SRM 5.0.2.
Installation and Upgrade
SRM 5.0.2 can run with ESXi Server 4.0 and 4.1 and with Virtual Infrastructure 3.5 only if you use array-based replication. If you use vSphere Replication, either alone or in conjunction with array-based replication, you must upgrade ESXi Server hosts to version 5.0, 5.0 update 1, or 5.0 update 2 as part of the upgrade process.
To install SRM 5.0.2 without upgrading from a previous version, see Installing and Updating Site Recovery
Manager in the Site Recovery Manager Administration Guide.
Upgrade SRM 5.0 or 5.0.1 to SRM 5.0.2
You can perform an in-place upgrade of SRM 5.0 or 5.0.1 to SRM 5.0.2. VMware recommends in-place upgrades rather than fresh installations as this preserves all history reports, recovery plans, protection groups and customizations of recovery plans. You must perform the upgrade procedure on both the protected site and on the recovery site.
- Log into the machine on which you are running SRM Server on the protected site.
- Back up the SRM database using the tools that your database software provides.
- Download and run
- Click Yes when prompted for confirmation that you want to upgrade SRM.
- Click Next to install SRM 5.0.2 using the settings from the previous SRM installation.
- Click Yes to confirm that you have backed up the SRM database.
- Click Finish when the installation completes.
- Repeat the upgrade process on the recovery site.
After you have upgraded SRM Server, you must reinstall the SRM client plug-in.
- Uninstall the SRM 5.0 or 5.0.1 client plug-in.
- Log into a vSphere Client instance and connect to the vCenter Server to which SRM Server is connected.
- Select Plug-ins > Manage Plug-ins.
- Click Download and Install to install the SRM 5.0.2 client plug-in.
- When the plug-in installation completes, log into SRM and verify that the configuration from the previous version has been retained.
- Repeat the process for all vSphere Client instances that you use to connect to SRM Server.
NOTE: Microsoft has issued a security update that results in Windows refusing certificates with RSA keys of less than 1024 bits. See http://support.microsoft.com/kb/2661254. This standard will increase to 2048-bits at the end of 2013. As a consequence, SRM 5.0.2 auto-generates certificates with RSA keys of 2048-bits. SRM 5.0 and 5.0.1 auto-generate certificates with RSA keys of 512-bits. When upgrading from SRM 5.0 or 5.0.1 to 5.0.2, SRM retains the certificate from the previous installation. Consequently, if you install the Microsoft security update you must upgrade the SRM certificates to use RSA keys of at least 1024-bits, or preferably 2048-bits.
- If you used auto-generated certificates with SRM 5.0 or 5.0.1, after you have upgraded to SRM 5.0.2, you can upgrade the certificate by running the SRM 5.0.2 installer again in Modify mode, selecting the option to generate a new 2048-bit certificate.
- If you used certificates that are signed by a certification authority in SRM 5.0 or 5.0.1, you must upgrade and import the certificate manually, making sure that they use RSA keys of at least 1024-bits, or preferably 2048-bits.
Upgrade vSphere Replication 1.0 or 1.0.1 to vSphere Replication 1.0.2
SRM 5.0 included vSphere Replication 1.0. SRM 5.0.1 included vSphere Replication 1.0.1. SRM 5.0.2 includes vSphere Replication 1.0.2. Upgrading SRM 5.0 or 5.0.1 to SRM 5.0.2 does not automatically upgrade vSphere Replication 1.0 or 1.0.1 to vSphere Replication 1.0.2. vSphere Replication 1.0.2 is functionally identical to vSphere Replication 1.0 and 1.0.1, with the addition of bug fixes. You can use vSphere Update Manager to update the VRM server and VR servers. Alternatively, you can use the virtual appliance management interface (VAMI) for the VRM server and VR servers to perform the update.
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 is incompatible with SRM and vCenter Server 5.0.x. Leave the update setting set to No automatic updates.
To update the VRM servers using the VAMI:
- Upgrade SRM Server and client to SRM 5.0.2.
- Go to the VRM server configuration interface at https://VRM_server_address:8080.
- Log into the VRM server configuration interface as root.
- Click the Update tab.
- Click Settings.
- Select Use Specified Repository and paste the update URL into the Repository URL text box:
- Click Status.
- Click Check Updates. The update checker shows that version 126.96.36.199 is available.
NOTE: You cannot use VRM server 188.8.131.52 with SRM 5.0.2.
- Click Install Updates and click OK.
- When the update finishes, select the VRM tab, click Configuration, and click Restart to restart the VRM server.
- Repeat the process for the VRM server on the recovery site.
To update the VR servers using the VAMI:
- Upgrade the VRM server.
- Go to the VR server configuration interface at https://VR_address:5480.
- Log into the VR server configuration interface as root.
- Click the Update tab.
- Click Settings.
- Select Use Specified Repository and paste the update URL into the Repository URL text box:
- Click Status.
- Click Check Updates. The update checker shows that version 1.0.2 is available.
- Click Install Updates and click OK.
- When the update finishes, select the System tab, click Information, and click Reboot to restart the VR server.
- Repeat the process for all VR servers on both the protected and recovery sites.
Upgrade SRM 4.1.2 to SRM 5.0.2
You can perform an in-place upgrade of SRM 4.1.2 to SRM 5.0.2. VMware recommends in-place upgrades rather than fresh installations as this preserves all history reports, recovery plans, protection groups and customizations of recovery plans. To upgrade the SRM client to 5.0.2, you must first uninstall the SRM 4.1.2 client.
NOTE: Upgrading from SRM 4.1 or SRM 4.1.1 to SRM 5.0.2 is not supported.
To upgrade from SRM 4.1.2 to SRM 5.0.2, follow the procedure for upgrading from SRM 4.1 or 4.1.1 to SRM 5.0 in Upgrading SRM in the Site Recovery Manager Administration Guide. See also the SRM 5 Upgrade Process blog.
Open Source Components
The copyright statements and licenses applicable to the open source software components distributed in vCenter Site Recovery Manager 5.0.2 are available at the SRM 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 vCenter Site Recovery Manager.
Caveats and Limitations
vCenter Server 5.0u2 supports Windows Server 2012 as a host operating system. SRM 5.0.2 does not support Windows Server 2012 as a host operating system for SRM Server.
Interoperability with Storage vMotion and Storage DRS
Due to some specific and limited cases where recoverability can be compromised during storage movement, Site Recovery Manager 5.0.2 is not supported for use with Storage vMotion (SVmotion) and is not supported for use with the Storage Distributed Resource Scheduler (SDRS) including the use of datastore clusters. If you use SVMotion to move a protected virtual machine from a datastore that is in a protection group to a datastore that is not protected, you must manually reconfigure the protection of that virtual machine.
Network address translation (NAT) is not supported with SRM
When configuring vSphere Replication, you must configure the vSphere Replication Server (VR server) with an IP address that is visible to both the protected vSphere Replication management server (VRM server) and the recovery VRM server.
Interoperability with vCloud Director
Site Recovery Manager 5.0.2 offers limited support for vCloud Director environments. Using SRM to protect virtual machines within vCloud resource pools (virtual machines deployed to an Organization) is not supported. Using SRM to protect the management structure of vCD is supported. For information about how to use SRM to protect the vCD Server instances, vCenter Server instances, and databases that provide the management infrastructure for vCloud Director, see VMware vCloud Director Infrastructure Resiliency Case Study.
Re-protect and automated failback not supported with vSphere Replication
Re-Protect and Automated Failback is only supported with array-replicated virtual machines. Virtual machines configured with vSphere Replication cannot be failed back automatically to the original site using existing recovery plans.
Certain vSphere features and RDM not supported with vSphere Replication
You cannot use vSphere Replication in conjunction with vSphere Fault Tolerance, virtual machine templates, linked clones, or with physical raw disk mapping (RDM).
Interoperability with vSphere Replication
vSphere Replication supports a maximum disk size of 2032GB.
Protection and recovery of virtual machines with memory state snapshots
When protecting virtual machines with memory state snapshots, the ESX hosts at the protection and recovery sites must have compatible CPUs, as defined in the VMware knowledge base articles VMotion CPU Compatibility Requirements for Intel Processors and VMotion CPU Compatibility Requirements for AMD Processors. The hosts must also have the same BIOS features enabled. If the BIOS configurations of the servers do not match, they show a compatibility error message even if they are otherwise identical. The two most common features to check are Non-Execute Memory Protection (NX / XD) and Virtualization Technology (VT / AMD-V). For more limitations to the protection and recovery of virtual machines with snapshots, see Limitations to Protection and Recovery of Virtual Machines in the Site Recovery Manager Administration Guide.
Maximum number of recovery plans per SRM Server instance
You can create the following maximum numbers of recovery plans per SRM Server instance:
- Array-based replication: 150 recovery plans
- vSphere Replication: 250 recovery plans
For the number of recovery plans that you can run concurrently and for other operational limits of SRM, see the Site Recovery Manager Administration Guide.
Using MD5 certificates with vSphere Replication management server
SRM 5.0.2 and vSphere Replication 1.0.2 allow you to configure the vSphere Replication management server to use MD5 certificates. However, due to the vulnerability of the MD5 certificate signature algorithm to attacks, if possible you should use at least SHA-1 as the certificate signature algorithm. You can use MD5 certificates with SRM 5.0.2 and vSphere Replication 1.0.2, but you should start to transition your infrastructure to use at least SHA-1 as the certificate signature algorithm as soon as possible.
The following issues have been fixed in SRM 5.0.2.
- NIC property settings are not applied during guest OS customization
If you run a test or a real recovery and configure NIC properties when there are 2 adapters for given MAC address, the NIC properties in the recovered virtual machine are not updated. This problem mostly occurrs if the NIC with the given MAC address has an antivirus miniport adapter as well as a physical adapter. This has been fixed.
- vCenter Service Status shows a red alert for the VR Management Service
After successfully registering a vSphere Replication management server (VRM server) with vCenter Server, the Home > vCenter Service Status view shows a red alert for the VR Management Service with an error message stating that vCenter Server cannot obtain the health information from the VRM server. This has been fixed.
- Test recoveries sometimes fail while configuring storage
A race condition can cause test recoveries to fail while SRM configures storage. The test plan shows that the recovery is interrupted, but you cannot cancel or remove the test plan. This problem can occur in cases with multiple shared raw disk mapping (RDM) devices, as described in KB 2020532. This has been fixed.
- SRM fails while removing a protection group that contains multiple datastores
If you delete several protection groups one after another SRM sometimes fails. After you restart SRM, SRM fails again at the same place. The logs show the message
Panic: Assert Failed: "1 == count" @ path/datastoreGroupData.cpp:398. This has been fixed.
- SRM fails during recovery while preparing virtual machines for migration on the protected site
If a protected virtual machine is on a datastore that is shared between multiple hosts, and if those hosts are in different datacenters, SRM can fail during a recovery at the step Prepare Protected Site VMs for Migration. The logs show the message
SRM Panic: Assert Failed: "ok" @ path/deactivateStorage.cpp:1170. This has been fixed.
- SRM waits indefinitely for a connnection to a recovered virtual machine to run a post-power-on script in the guest OS
Previously, if SRM could not connect to a recovered virtual machine to attempt to run a script in the guest OS of the virtual machine after it powers on, SRM would wait indefinitely. SRM no longer waits indefinitely for a connection to a recovered virtual machine. The request times out after a default period of 20 seconds. If this timeout period causes test recoveries to fail with the error
Operation timed out: 20 seconds, you can increase the timeout period.
- Open the file
C:\Program Files\VMware\VMware Site Recovery Manager\config\vmware-dr.xml in a text editor.
- Add a
vixOpenVmTimeout node, with a new timeout period in seconds.
- Restart the SRM service.
- Repeat the configuration on the SRM Server on the other site.
- Cannot modify an SRM installation if an IPv6 address was used for the SRM Server during initial installation.
If you used an IPv6 address when you installed the SRM Server and subsequently attempt to modify the installation by running the SRM installer in Modify mode, the modification fails with the error
VMware vCenter Site Recovery Manager Setup Error. This 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.
- Large Disks Perform Full Sync Unnecessarily
When disks larger than 256GB are protected using vSphere Replication (VR), any operation that causes an internal restart of the virtual disk device causes the disk to complete a full sync. Internal restarts occur any time:
- A virtual machine is restarted
- A virtual machine is vMotioned
- A virtual machine is reconfigured
- A snapshot is taken of a virtual machine
- Replication is paused and resumed
The full sync is initiated by ESX, and any resolution to this problem would involve an update to ESX. These syncs involve additional I/O to both the protected and recovery site disks, which often takes longer than the Recovery Point Objective (RPO), resulting in a missed RPO target. This problem is present in ESXi Server 5.0, but has been fixed in ESXi Server 5.0 update 1.
Workaround: Upgrade ESXi Server to version 5.0 update 1.
- Setting LVM.enableResignature to 1 remains set after a test failover
SRM does not support ESX environments in which the
LVM.enableResignature flag is set to 0. During a test failover or an actual failover, SRM automatically sets
LVM.enableResignature to 1 if the flag is not already set. SRM sets this flag to resignature snapshot volumes and mounts them on ESX hosts for recovery. After the operation is completed, the flag remains set to 1. For information, see KB 2010051.
- Cannot reconfigure vSphere Replication on a virtual machine after receiving
Error committing the transaction during configuration
If you receive the message
Error committing the transaction during the configuration of replication on a virtual machine, any attempt to reconfigure replication on the virtual machine fails. This problem occurs because vSphere Replication does not clean up the configuration data properly after the configuration attempt. Consequently, the replication of the virtual machine appears configured to vSphere Replication when it is not.
Workaround: To clean up the configuration data correctly, disable replication of the virtual machine at the command line.
- Log in to the ESXi console.
- Run a command to look up the ID of the virtual machine in the ESXi host.
# vim-cmd vmsvc/getallvms | grep virtual_machine_name
The virtual machine ID is the number in the first column.
- Run a command to disable replication for the virtual machine with the ID that you found in the previous step.
# vim-cmd hbrsvc/vmreplica.disable virtual_machine_ID
- Forced failover checkbox remains selected after you revert to planned migration
If you run a recovery plan with the forced failover option selected, and then revert back to planned migration by selecting Planned Migration, the forced failover checkbox remains selected and grayed out in the Run Recovery Plan wizard. This problem only affects the user interface and SRM performs the correct behavior.
Workaround: Close and reopen the Run Recovery Plan wizard after unselecting the forced failover option.
- Recovery or migration operations can fail if placeholder datastores are not visible to all hosts in a protected cluster
During recovery and migration, placeholder virtual machines are replaced with recovered virtual machines. If you have a cluster with multiple hosts on the recovery site, all the placeholder datastores must be available to all the hosts in the cluster, otherwise swapping virtual machines can fail. SRM does not prevent you from selecting placeholder datastores that are not available to all the hosts in the cluster. If placeholder datastores are not visible to all the hosts, the recovery plan fails with the error
Error - Unable to access file [datastore]" Unable to access file [datastore] Failed to unregister protected VMs. Hosts must have access to the datastores that contain both the placeholder virtual machines and the recovered virtual machines.
Workaround: Manually check that the datastores for both the placeholder virtual machines and the recovered virtual machines are visible to all the hosts in a protected cluster.
- VRM server and VR server versions are not updated in virtual machine summary after upgrade
If you upgrade an exising installation of the vSphere Replication Manager Server (VRM server) appliance from version 1.0 to version 1.0.1, the version numbers of the VRM server and VR server are not updated in the virtual machine Summary tab. When you select the VRM server or a VR server in the vCenter Server Inventory, the Summary tab still displays version 184.108.40.206, even though the VRM server has been updated to 1.0.1. If you perform a new installation of VRM server version 1.0.1, the Summary tab displays the correct version number.
Workaround: Check the version number in the VRM server virtual appliance management interface:
- Log into https://VRM_server_IP_address:8080.
- Select the Update tab.
- Click Status.
The version number is 220.127.116.11.
Alternatively, you can see the correct version number in the console for the VRM server or VR server in the vSphere Client.
- Use of unsupported databases with vSphere Replication management server is possible
You can configure the vSphere Replication management server (VRM server) to use databases that are not supported and VRM server configuration will succeed without any warnings about database support. However, using an unsupported database can lead to unpredictable behavior. The following databases are fully tested and supported for use with VRM server:
- SQL Server 2005 SP4 64-bit
- SQL Server 2008 R2 SP1 64-bit
- SQL Server 2008 R2 64-bit
- Some SRAs handle certain timezones incorrectly during failover
Test and real failovers can stop with the error
Failed to create snapshots of replica devices for group 'protection-group-999' using array pair 'array-pair-999': Vmacore::SystemException "The parameter is incorrect. " (87). This error is due to a mishandling of the time zone returned by the storage array to the SRA. All timestamps earlier than January 1 1970 will experience this problem. For details and a workaround, see KB 2018597.
- During upgrade from SRM 4.1.2 to SRM 5.0.2
srm-migration importConfig command fails due to datastore object IDs changing
The SRM 5.0.2 upgrade process completes without error, vCenter Server restarts, and the hosts, guests, and storage all come online in the same state as when the vCenter Server service was stopped. However, during SRM migration the Protection Group imports fail with the following error:
Skipping VM protection for all VMs in group (group) due to an error: One or more datastores are either already protected in a different group or not currently replicated.
The datastore Object IDs listed in the SRM
exportConfig.xml file are different to the same datastore Object IDs that are shown in the MOB browser. This problem is related to the problem described in KB 2007404.
Workaround: Edit the
exportConfig.xml to use the datastore Object IDs from the MOB browser and rerun the
srm-migration importConfig command.
- Events Not Properly Displayed for Korean Operating Systems
When the vSphere Client starts, it determines the locale on which it is running, and then chooses the set of messages to display based on the locale. When the vSphere Client is installed on a Korean operating system, the client requests messages from the ko folder from the vCenter Server installation because the vCenter Server and the vSphere Client are localized for Korean. While the vCenter Server and vSphere Client are localized for Korean, SRM is not. Therefore, XXX messages are displayed, instead of SRM Server messages. To resolve this problem, create copy of the en folder which is in C:\Program Files\VMware\Infrastructure\VirtualCenter Server\extensions\com.vmware.vcDr\locale\. Rename the folder from en to ko and restart the vCenter Server and SRM services.
- Duplicate volumes appear in the Devices tab in the Array Managers view in the SRM UI
This problem occurs when the target number of a LUN is the same as the source number of another LUN. This is a UI problem, and it does not affect test or real recoveries.
- A recovery or test workflow fails for a virtual machine with the following message: Error - Unexpected error '3008' when communicating with ESX or guest VM: Cannot connect to the virtual machine.
Under rare circumstances this error might occur when you configure IP customization or an in-guest callout for the virtual machine and the recovery site cluster is in fully-automated DRS mode. An unexpected vMotion might cause a temporary communication failure with the virtual machine, resulting in the customization script error.
Workaround: Rerun the recovery plan. If the error persists, configure the recovery site cluster DRS to manual mode and rerun the recovery plan.
- 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 on manually updating the VRMS database with the new datastore managed object id. If the primary site is still available:
- Run a cleanup operation on the recovery plan that failed.
- In the Virtual Machines tab of the vSphere Replication view, right-click a virtual machine and select Configure Replication.
- 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.