Known issues are resolved in this release of Site Recovery Manager:
Site Recovery Manager 4.1 Test Failover Fails.
When performing a test failover with VMware vCenter Site Recovery Manager 4.1, you might have experienced these symptoms:
Test failover failed to complete during the Preparing Storage phase
You were unable to perform a test failover
Site Recovery Manager logs contained the error:
Error: Maximum number of access records for this volume reached
This issue occurred because of the limits imposed on LUN access control lists by some storage arrays. SRM would add all iSCSI initiators to the target LUN access control list, which could exceed the limit of 16 records that some storage arrays apply. SRM now filters out iSCSI initiators that are not configured for static and dynamic discovery of iSCSI targets. This fix reduces the impact of the issue documented in KB 1030356. However, if you do need to access the same LUN from more than 16 hosts, or if you configure many iSCSI initiators on the recovery site, you might still encounter this issue.
Recovery Fails When NFS Datastores are Mounted on Two Hosts with Different IP Addresses
This issue occurred when more than one NFS datastore with different URLs were mounted on the same volume. vCenter Server cannot detect NFS datastores that are mounted from the same volume using different IP addresses, which resulted in two datastores being created after recovery, each with one host mount. Site Recovery Manager now checks whether there are two or more NFS datastores mounted from the same volume with different URLs. If there are two or more such datastores, SRM marks them as invalid and excludes them from the calculation of the LUN group. SRM displays a warning that two or more NFS datastores mounted on the same volume have a URL conflict and lists the URLs of the invalid datastores.
Rolling Back the Uninstallation of the SRM Service Fails.
Previously, if uninstalling SRM failed or if you canceled the uninstallation of SRM by clicking the Cancel button in the uninstallation wizard during the uninstallation process, the uninstaller did not restore SRM to its initial state. Attempting to restart the SRM service after an uninstallation failure or after canceling the uninstallation, or attempting to uninstall SRM a second time, resulted in an error. The operations to cancel uninstallation or to roll back an uninstallation that fails have been disabled. The uninstaller does not roll back to the initial state if it encounters a problem, but it now unregisters SRM from the system and allows you to reinstall SRM.
Timeout During Network Customization of SUSE Linux 10 Virtual Machines.
Previously, when performing a Recovery Plan test or a Failover in SRM using IP Customization for SUSE Linux virtual machines, after IP customization of SUSE Linux 10 virtual machines, the IP address was not updated. This issue would occur when an IP address in a SUSE Linux virtual machine is configured for a particular MAC address, instead of for an Ethernet device. IP customization specifies an IP address for an interface, which previously could be overridden by the more specific MAC-based configuration. This resulted in the SUSE Linux virtual machine continuing to use the old IP address. This has been fixed. This fix resolves the issue described in KB 1036310.
Recovery Plan OS Heartbeat or IP Customization Timeout Settings Greater than 2000 Seconds Wait Forever.
In a recovery plan, the maximum timeout for network IP address customization and OS heartbeat was limited to 2000 seconds, as a longer timeout duration would make SRM wait forever. This problem has been fixed, and now you can set these timeouts to up to 3600 seconds.
Running the vCenter Site Recovery Manager dns_update script fails with the error "\VMware\VMware was unexpected at this time".
This issue would occur when the PATH system environment variable on the SRM server recovery site includes parentheses (for example, on 64 bit operating systems). The parentheses caused the Windows command line shell to misinterpret scripts. This has been fixed. This fix resolves the issue described in KB 1036097.
Creating a Protection Group or Protecting a Virtual Machine Fails with the Error: Operation Not Supported on the Object.
This issue would occur during the creation and reconfiguration of the shadow (placeholder) virtual machine. vSphere allows you to set the RAM size value of the video card manually. You can then subsequently enable auto-detect so that ESX Server detects the video card RAM size. When SRM creates the change specification for placeholder virtual machines, it first sets all parameters to the default, then inspects the parameters in the protected virtual machine change specification and sets those parameters accordingly. In the placeholder virtual machine, SRM would set the non-default video card RAM size and also enable auto-detect. This causes a conflict when the host agent applies the settings to the virtual machine that it creates during a recovery, so the host agent returns an error. SRM now ignores the video card parameters in the change specification of the placeholder virtual machine. This fix resolves the issue described in KB 1020796.
vCenter Server Session Does Not End when the vSphere Client Closes if the Remote Site is Unavailable.
Previously, if you closed the vSphere Client and the remote site was unavailable, the vCenter Server session would not end. The vSphere Client would end the local SRM session before the SRM client plug-in logged out of the local SRM server. This has been fixed.
Unclear Error Message when Installation Fails Because the SRM User Account Does Not Have Administrator Privileges
Prevously, if the installation failed because the SRM user performing the installation did not have the Administrator role in vCenter Server, the installer displayed the error Internal error: unexpected error code: -1. The error message now states The specified user does not have administrative privileges. Please use a different user name.
SRM Server Fails to Start the SRM Service if a Datastore Name is Invalid.
If a primary or secondary SRM server could not obtain a valid datastore name from the ESX Server, it would fail to start the SRM service with the message Panic: Assert Failed: "!dsName.empty()". SRM now checks whether datastore names are valid, and throws the following exception if they are not:
A general system error occurred: Name for datastore used by VM is empty. The VM is considered invalid and will not be protected.
SRM Stops Responding During Failover when the Storage Array on the Protected Site is Offline.
Previously, the Shutdown Protected Virtual Machines phase was implemented synchronously. As a result, if the storage array of a protected site was offline and SRM did not receive confirmation of the synchronous call, the SRM failover process would stop responding. SRM now shuts down each protected guest operating system asynchronously. If an asynchronous shutdown request fails, SRM logs the failed attempt, and then re-sends the asynchronous request. If the request continues to fail until a timeout period expires, SRM performs a hard power-off on the protected guest operating system, and continues to the next phase of the recovery plan.
SRM Uninstaller Does Not Remove Old SRM License Asset Data from the User Interface.
Previously, if you uninstalled an evaluation version of SRM then installed a licensed version or a later version of SRM, the uninstaller would not remove the old license asset information from the user interface, and two versions of the license assets would appear. This has been fixed.
Customization Specification Does Not Configure the Gateway for Red Hat Enterprise Linux 5.x.
Previously, image customization of Red Hat Enterprise Linux 5.x virtual machines did not configure the gateway properly. Consequently, if users assigned a new gateway to the recovering RHEL 5.x virtual machine during customization, the new gateway entry was appended to the /etc/sysconfig/network-scripts/route-ethX file. The RHEL network service would pick up the first entry in that file, namely the old gateway setting on the protection site, and would not pick up the gateway changes specified by the user during customization. This issue has been fixed, and the new gateway entry now overwrites the old one.
Applying the Update
You can apply this update to SRM 4.1.0, 4.1.1, and 4.0.3 servers. After applying this update, you must update each vSphere client that is using an older SRM client plug-in.
Download the update and save it on a volume that is accessible to all of the applicable SRM server hosts. The update file name is VMware-srm-4.1.2-484598.exe.
To apply the update to an SRM server host, log in to the host as a member of the Administrators group.
Run the update file. The update installation stops the SRM service, installs the updated files, and restarts the SRM service.
Update the SRM plug-ins on client hosts. For each host whose vSphere client has downloaded, installed, and enabled the SRM 4.1 plug-in:
Close any open instances of the vSphere Client.
Use the Windows Add or Remove Programs tool to uninstall the VMware Site Recovery Manager plug-in
Connect to the SRM server that you updated in Step 3.
Follow the procedure in Chapter 2 of the Administration Guide to install and enable the new plug-in.
Removing the Update
To remove this update:
Use the Windows Add or Remove Programs tool to uninstall VMware vCenter Site Recovery Manager.
Install VMware vCenter Site Recovery Manager 4.1, 4.1.1, or 4.0.3.