VMware vCenter Site Recovery Manager 5.0.3 Release Notes
VMware vCenter Site Recovery Manager 5.0.3 | 17 OCT 2013 | Build 1344912
Last updated: 18 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.3 provides the following improvements:
VMware vCenter Site Recovery Manager 5.0.3 is available in the following languages:
- Simplified Chinese
SRM Compatibility Matrix
For the current interoperability and product compatibility information, please see the Compatibility Matrices for VMware vCenter Site Recovery Manager 5.0.
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.3 using vSphere Replication. VSA does not require a Storage Replication Adapter (SRA) to work with SRM 5.0.3.
Installation and Upgrade
SRM 5.0.3 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.x as part of the upgrade process.
To install SRM 5.0.3 without upgrading from a previous version, see Installing and Updating Site Recovery
Manager in the Site Recovery Manager Administration Guide.
Upgrade SRM 5.0.x to SRM 5.0.3
You can perform an in-place upgrade of SRM 5.0, 5.0.1, or 5.0.2 to SRM 5.0.3. 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.3 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 client plug-in from the previous version.
- 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.3 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 and later 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.3, 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.3, you can upgrade the certificate by running the SRM 5.0.3 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.x to vSphere Replication 1.0.3
The SRM 5.0. to 5.0.2 releases include vSphere Replication 1.0 to 1.0.2. SRM 5.0.3 includes vSphere Replication 1.0.3. Upgrading SRM 5.0, 5.0.1, or 5.0.2 to SRM 5.0.3 does not automatically upgrade vSphere Replication 1.0, 1.0.1, or 1.0.2 to vSphere Replication 1.0.3. vSphere Replication 1.0.3 is functionally identical to vSphere Replication 1.0.2, 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 by using the VAMI:
- Upgrade SRM Server and client to SRM 5.0.3.
- 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 220.127.116.11 is available.
- 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.3 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.3
You can perform an in-place upgrade of SRM 4.1.2 to SRM 5.0.3. 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.3, 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.3 is not supported.
To upgrade from SRM 4.1.2 to SRM 5.0.3, 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.3 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
ESXi Server 5.0 does not support guest operating system customization of virtual machines that run Windows 8 or Windows Server 2012
Support for guest operating system customization of Windows 8 and Windows Server 2012 virtual machines is available with ESXi Server 5.0 u2 and later. If you run ESXi Server 5.0.x on the protected site and ESXi Server 5.0 on the recovery site, test recoveries and real recoveries fail because the ESXi Server 5.0 on the recovery site cannot complete the the Windows 8 or Windows Server 2012 boot process. The virtual machine on the recovery site does not display the Windows login screen. SRM displays an error message in the recovery steps to state that VM Tools is timing out during power on, before the IP customization step.
Workaround: Upgrade ESXi Server on the recovery site to version 5.0 u2 or later.
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.3 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 for the SRM Server or vSphere Replication Server
When configuring SRM, you must configure SRM Server with an IP address that is visible to the corresponding SRM Server with which it will be paired. See NAT is not a supported configuration in SRM.
Interoperability with vCloud Director
Site Recovery Manager 5.0.3 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
In SRM 5.0.x, reprotect and automated failback are only supported with array-based replication. Virtual machines that you protect by using vSphere Replication cannot be recovered automatically to the original site by using existing recovery plans.
Certain vSphere features and RDM not supported with vSphere Replication
You cannot use vSphere Replication 1.0.x in conjunction with vSphere Fault Tolerance, virtual machine templates, linked clones, or with physical raw disk mapping (RDM).
Interoperability with vSphere Replication
vSphere Replication 1.0.x 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 5.0.x, see the Site Recovery Manager Administration Guide.
Using MD5 certificates with vSphere Replication management server
SRM 5.0.3 and vSphere Replication 1.0.3 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 SHA1 as the certificate signature algorithm. You can use MD5 certificates with SRM 5.0.3 and vSphere Replication 1.0.3, but you should start to transition your infrastructure to use at least SHA1 as the certificate signature algorithm as soon as possible.
The signature algorithm of the default vCenter Server certificates is SHA256RSA. Windows Server 2003 does not support SHA256RSA. To install SRM 5.0.3 on Windows Server 2003, you must perform one of the following actions:
- Install one of the following hot fixes from Microsoft:
- Upgrade the host operating system for SRM Server to Windows Server 2008 or later.
- Make sure that you use SHA1RSA for your vCenter Server certificates. If you do not use SHA1RSA for the vCenter Server certificates, you must upgrade the certificates, or upgrade vCenter Server and SRM to version 5.5.
The following issues have been fixed in SRM 5.0.3.
- Modifying or repairing an SRM Server installation requires user Administrator or disabling of UAC.
If you are a member of the Administrators group but you are not an administrator, you must disable Windows User Account Control (UAC) before you attempt to modify or repair an SRM Server installation from the Windows control panel. If you have installed SRM Server on a Windows Server 2012 host, you disable UAC by modifying the registry. This has been fixed.
- Running a planned migration causes the SRM service to stop unexpectedly if host is disconnected.
If an ESXi host is disconnected from vCenter Server and you run planned migration, the SRM service can stop unexpectedly at the
Set volume as read-only step of the recovery plan. This has been fixed.
- Timeouts occur with the error to "Cannot find replicated datastore due to timeout of HBA rescan operation".
This has been fixed to improve detection of the error and the error message for timeouts during host rescan operations.
- 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 UI problem has been fixed.
- Recovering a Windows Server 2012 Domain Controller (DC) virtual machine breaks the DC safeguard mechanism.
Recovery of a Windows Server 2012 DC virtual machine is possible by using either array-based replication or vSphere Replication. However, performing a recovery operation on such a virtual machine might lead to a breakdown of the Windows Server 2012 DC SafeGuard Mechanism. This has been fixed.
- IP Customization fails during a recovery or test recovery.
When running a recovery or test recovery of a recovery plan, IP customization fails for some or all virtual machines, for either of the following reasons:
- On some Windows virtual machines that have altered paths for temporary folders, IP customization looks in the wrong place for the result logs. See KB 2021083 for details. This has been fixed.
- If an intermediate result log was inaccessible while performing IP Customization on Windows virtual machines, the customization completes successfully but reports the error
Error - Cannot complete customization, possibly due to a scripting runtime error or invalid script parameters (Error code: -1). IP settings may have been partially applied. This has been fixed. IP customization now correctly reports success.
- Rescans of datastores on recovery site fail due to storage devices not being ready.
SRAs can send responses to SRM before a promoted storage device on the recovery site has become available to the ESXi hosts. When SRM receives a response from an SRA, it performs a rescan of the storage devices. If the storage devices are not fully available yet, ESXi Server does not detect them and SRM does not find the replicated devices when it performs rescans. Datastores are not created and recovered virtual machines cannot be found.
Workaround: If you experience problems with unavailable datastores, SRM 5.0.3 provides a new setting to allow you to delay the start of rescans after an SRA promotes a storage device.
- Right-click an SRM site and select Advanced Settings.
- Click storageProvider.
- Set the
storageProvider.hostRescanDelaySec parameter to delay the start of storage rescans by a number of seconds. A value from 20 to 180 is reasonable.
- Restart the SRM service.
NOTE: In previous releases, you might have used the
storageProvider.hostRescanRepeatCnt parameter to introduce a delay in recoveries. Use the new
storageProvider.hostRescanDelaySec parameter instead.
- Custom recovery steps do not stop virtual machines from powering on before IP customization.
If you insert a custom recovery step after the "create writable storage snapshot" step in a test recovery or after the "change recovery site storage to writable" step in a real recovery, and if you have configured the virtual machine for IP customization, the recovery plan does not wait for the custom recovery step to complete before powering on the virtual machine. This has been fixed.
- SRM fails to mount VMFS volumes with the error
When SRM gets information from vCenter Server, SRM shows that the volume that contains a virtual machine is not mounted. However, at the same time, ESXi Server mounts the volume successfully. SRM tries to mount the volume based on previous information from vCenter Server and shows that the volume is in an invalid state, and says that it is already mounted. This has been fixed.
- Failed recovery results in repeated SRM Server failures.
After a recovery plan fails to make progress, users might choose to re-run the recovery plan. In rare cases, rerunning the recovery plan causes the SRM server to stop unexpectedly. After restarting the SRM Server, the recovery plan continues to cause the server to stop unexpectedly. The logs show that a virtual machine that was being modified just before the SRM Server stopped, with the log entry IP customization succeeded for VM VM Name. This has been fixed.
- SRM Service stops after checking the license manager during protection of a virtual machine.
When you configure protection on a virtual machine, SRM Server stops unexpectedly. The logs contain the error
Panic: Assert Failed: "found == _reservations.get<by::vm>().end() (There is already a Reservation for VM [vim.VirtualMachine:virtual_machine])". This has been fixed.
- Pairing SRM Servers fails when using custom certificates with VCVA.
Pairing SRM Servers when using custom certificates for SRM Server and the vCenter Server virtual appliance fails with the error:
Permission to perform this operation was denied. This has been fixed.
- Cannot install SRM 5.0.2 on Windows Server 2012.
It was not possible to install SRM Server 5.0.2 on Windows Server 2012. This has been fixed and SRM 5.0.3 supports Windows Server 2012 as the host operating system for SRM Server.
- SRM cannot protect virtual machines that have one or more RDM disks if the virtual machines are part of a vApp.
If a virtual machine is part of a vApp and if the virtual machine uses RDM disks, configuring protection results in the error
Device Not found: Hard Disk X in the protection status. In this error,
Hard Disk X is the RDM disk connected to the virtual machine. This has been fixed.
- SRM Server stops unexpectedly during test cleanup.
Under rare circumstances, SRM Server stops unexpectedly during test cleanup with the error
Panic: Assert Failed: .../srm/src/replication/providers/storageProvider/data/groupPostFailoverInfoData.cpp:108. This has been fixed.
- SRM stops unexpectedly when a localized Windows guest operating system sends a messsage to SRM Server.
This issue occurs when SRM Server is running on a Windows operating system in the JP, KO, or CN locales, and vCenter Server is running in the EN locale. For example, when a post-power on script runs a command that returns an error in Japanese characters, vCenter Server does not translate that message into the proper encoding. SRM receives a invalid exception and stops unexpectedly. This has been fixed.
- DR IP Customizer Tool stops unexpectedly in Windows 2003 guest operating systems, without sending a notification.
DR IP Customizer Tool stops unexpectedly on Windows 2003 guest operating systems. No notification is sent, but the SRM logs show the error
C:\WINDOWS\TEMP\vmware-SYSTEM\netshIPv6.vbs(279, 4) Microsoft VBScript runtime error: Object doesn't support this property or method: 'GUID'. This issue is caused by an unhandled error while attempting to access a nonexistent GUID property. This has been fixed.
- Guest OS Quiescing option is unavailable for virtual machines running Windows Server 2012.
When configuring vSphere Replication on a virtual machine with a Windows Server 2012 guest operating system, the option to enable guest OS quiescing is unavailable. This has been fixed.
- vSphere Replication removes disk files for non-replicated virtual machines from the target site if a file has the same name as replicated disk file.
If, immediately before clicking the Finish button in the Configure Replication wizard, a disk with the same name as a replicated disk appears in the target datastore location, the Configure Replication task fails, because vSphere Replication does not expect to find the the disk there and wrongly removes the disk that was not created by this task. This has been fixed.
- Test failover, planned migration, or disaster recovery fails with the error
Error creating ... image ... NullPointerException".
VRMS might fail to receive response from the VR server at a particular stage of the disaster recovery workflow. The disaster recovery operation fails. Attempts to re-run the operation always fail with the error
Error creating ... image ... NullPointerException". This has been fixed and attempts to rerun the operation succeed.
- Reconfiguring replication to include a disk that was previously excluded, and using a replication seed for this disk, results in vSphere Replication erroneously removing the replication seed.
If you have a replication with an excluded disk and later reconfigure the replication to include that disk, and then you manually copy a disk file to use as a replication seed, vSphere Replication removes the copied .vmdk file, ignoring the fact that it was an initial copy that was not created by vSphere Replication. This requires you to copy the .vmdk file to the target site again. This has been fixed.
- With vSphere Replication, test virtual machines are deleted if RevertSwap fails during test cleanup.
If RevertSwap fails during test cleanup, test virtual machines that vSphere Replication creates on the secondary site is deleted. This also removes the parent disks, which then requires a full sync to be performed before you can perform a real recovery. This has been fixed so that vSphere Replication unregisters rather than deletes the test virtual machine, which does not delete the disks.
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 or later.
- 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 18.104.22.168, 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 22.214.171.124.
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.3
srm-migration importConfig command fails due to datastore object IDs changing
The SRM 5.0.3 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.
- 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.
- Reprotect fails after removing a disconnected host on the protected site.
If you remove a disconnected host from the protected site after a recovery operation, and run reprotect, the reprotect operation might fail with the error
Internal error: std::exception 'class Vmacore::Exception".
Workaround: Rerun Reprotect with the Force Cleanup option selected.
- SRM panics at startup and at random times.
Due to an issue in vCenter Server, SRM Server can stop unexpectedly with the error
panic 'Default' opID=7b0e972e] Duplicate key 'key-vim.host.ScsiDisk-020002000050002ac0000f0c70565620202020' in linkable vim.host.ScsiDisk referenced by field scsiLun (wsdl name scsiLun). This is caused by the vCenter Server error that is described in http://kb.vmware.com/kb/2033163.
Workaround: Remove the hosts from vCenter Server inventory and then add them again.
- First attempt to log into the SRM interface fails after installation on Windows Server 2012.
If you install SRM Server on Windows Server 2012, the first attempt to log into the SRM interface fails with error messages that the remote server is taking too long to respond. This issue only occurs on the first attempt to log into SRM after installing it on Windows Server 2012.
Workaround: Close and reopen the vSphere Client, then log into SRM again.