VMware vCenter Site Recovery Manager 4.0 Release Notes

Site Recovery Manager 4.0 | 05-October-2009 | Build 192921

(Updated 19-May-2010)

VMware vCenter Site Recovery Manager 4.0 includes new features, enhancements, and defect fixes.

These release notes contain the following sections:


VMware vCenter Site Recovery Manager is a business continuity and disaster recovery solution that helps you plan, test, and execute a scheduled migration or emergency failover of vCenter inventory from one site to another. SRM provides the following features:

Disaster Recovery Management
  • Discover and display virtual machines protected by storage replication using integrations certified by storage vendors.
  • Create and manage recovery plans directly from vCenter Server.
  • Extend recovery plans with custom scripts.
  • Monitor availability of remote site and alert users of possible site failures.
  • Store, view and export results of test and failover execution from vCenter Server.
  • Control access to recovery plans with granular role-based access controls.
Non-Disruptive Testing
  • Use storage snapshot capabilities to perform recovery tests without losing replicated data.
  • Connect virtual machines to an existing isolated network for testing purposes.
  • Automate execution of recovery plans.
  • Customize execution of recovery plans for testing scenarios.
  • Automate cleanup of testing environments after completing failover tests.
Automated Failover
  • Initiate recovery plan execution from vCenter Server with a single button.
  • Automate promotion of replicated datastores for use in recovery scenarios with adapters created by leading storage vendors for their replication platforms.
  • Execute user-defined scripts and halts during recovery.
  • Reconfigure virtual machines' IP addresses to match network configuration at failover site.
  • Manage and monitor execution of recovery plans within vCenter Server.

New in This Release

This release of Site Recovery Manager introduces several new features:

  • Full compatibility with vCenter 4.
  • Full support for NFS-based arrays.
  • Support for shared recovery sites.
    Enables many-to-one pairings of protected sites with a recovery site. For more information, see the technical note Installing, Configuring, and Using Shared Recovery Site Support, which is available at http://www.vmware.com/support/pubs/srm_pubs.html.
  • Resilience in the face of vCenter unavailability during a test recovery.
    Placeholder virtual machines can be quickly repaired after the protected site vCenter becomes available again.
  • New repair-mode installation features.
    You can run the SRM installer in repair mode if you need to change configuration parameters such as vCenter credentials, database connection information or credentials, and certificate details.
  • Graphical interface to advanced settings.
    Eliminates most requirements to edit the XML configuration file
  • Support for DB2 as an SRM database server.
  • New licensing options.
  • Improved scalability.
    A single protection group can now include up to 1000 virtual machines.
  • Full Compatibility With DPM (Distributed Power Management)
    SRM recovery plans can now power-on or power-off a host that is in standby mode.
  • New Option to dr-ip-customizer Utility
    The dr-ip-customizer utility now logs less verbose diagnostic output by default. To force dr-ip-customizer to log the same level of diagnostic output that it produced in earlier releases, use the -verbose option.
  • Change in Certificate Validation
    When you select certificate authentication, the SRM installation validates the certificate you supply before continuing. Certificates signed with an MD5 key are no longer allowed.
  • Support for Protecting Fault-Tolerant Virtual Machines.
    SRM can now protect virtual machines that have been configured for fault-tolerant operation. When recovered, these virtual machines lose their fault tolerance, and must be manually reconfigured after recovery to restore fault tolerance.
  • Improved context-sensitive Help.
  • PDF documents available on release media
    Current versions of the PDF documents for this release are available in the docs folder at the root of the SRM 4.0 CD. Updated versions of these documents may be available at http://www.vmware.com/support/pubs/srm_pubs.html.


A new installation of SRM 4.0 is incompatible with earlier SRM databases.
If you perform a new installation of SRM 4.0 and specify database connection information for an existing SRM 1.0 or 1.0 Update 1 database, the installation will fail and the database will be corrupted. To reuse an existing SRM 1.0 or 1.0 Update 1 database, you must perform an upgrade installation. For more information, see Upgrading from a Previous Release

If you use certificate-based authentication, your existing certificates will no longer work with SRM 4.0 in most cases. In addition, users of certificate-based authentication cannot upgrade directly from SRM 1.0 to SRM 4.0. They must first upgrade to SRM 1.0 Update 1. Users of credentials-based authentication are not subject to this restriction. For more information, see Upgrading from a Previous Release.

SRM 4.0 servers are not compatible with earlier SRM and vCenter releases. SRM 4.0 is compatible with vCenter 4.0. You cannot pair sites that are running different versions of SRM. If you update one member of a site pair to SRM 4.0, you must update the other member of the pair before attempting any SRM operations.

You must use an SRM 4.0 client plug-in to connect to an SRM 4.0 server. Connections from an SRM 4.0 client plug-in to an earlier SRM server release may appear to succeed in some cases, but will produce unpredictable results. If the older SRM server has any protection groups defined, the connection will fail.

The Site Recovery Manager Compatibility Matrixes guide lists all compatible versions of VMware vSphere components, and also lists supported supported databases and guest operating systems. Compatible storage arrays and SRAs are listed in Site Recovery Manager Storage Partners.

Installation Notes for This Release

You can install SRM 4.0 in one of two ways:

  • As a new installation, which creates a new SRM database.
  • As an update installation, which also updates an existing SRM 1.0 or 1.0 Update 1 database to the SRM 4.0 schema.
Additional information about installing SRM is available in the following documents:
  • Getting Started with Site Recovery Manager provides a high-level architectural overview and workflow.
  • The Administration Guide includes step-by-step guidance on installing and configuring SRM. This guide contains information about all requirements and procedures to set up SRM and also addresses prerequisites and scaling limits.
  • The Site Recovery Manager Evaluation Guide provides a conceptual overview as well as step-by-step workflows describing planning for using SRM, setting up protected and recovery sites, testing failover, the failover and failback process, alarms and status monitoring, and a discussion of roles and privileges.

Updating from a Previous Release

Because this release of SRM is not compatible with the releases of vCenter that supported previous SRM releases, you must update vCenter before you update SRM. If you update the protected site first, recovery plans remain runnable from the recovery site during and after the protected site update, although any recovery steps that require communication with the protected site will fail. (The recovery scenario in this case is equivalent to one where the protected site is inaccessible.) While the recovery site is being updated, no recoveries are possible. After the update process is complete and the two sites are paired, recovery plans are runnable again. All SRM artifacts such as protection groups and recovery plans are preserved during the update process.

Note: The SRM installer does not permit you to change database connection information during an update or use an existing SRM database with a new installation of SRM. If the database version used by the existing SRM installation is not supported by SRM 4.0, or if you decide to host the SRM database on a new server, you must follow the instructions provided by your database vendor to migrate the SRM database to the new version or server. The migration must not change the existing database client type, DSN, username, and password. After the migration is complete, verify the connection information by reconnecting to the database with the existing SRM server. If the connection succeeds, proceed with the SRM upgrade.

Follow this procedure to ensure a successful update:

  1. If you are using certificate-based authentication, you must complete the following steps before you begin the update process:
    • If you are still running SRM 1.0, install SRM 1.0 Update 1 before proceeding with the update to SRM 4.0. If you are using certificate-based authentication, you cannot update directly from SRM 1.0 to SRM 4.0.
    • Obtain a new certificate that complies with the new certificate content rules, which are detailed in the SRM Administration Guide. Because of a change in vCenter authentication protocols, the Subject Alternative Name field of the certificate must now be the fully-qualified domain name of the SRM server. In previous releases, this field used the fully qualified domain name of the vCenter server. (If you have installed SRM on the vCenter server, then you do not need to acquire a new certificate.)
    • Install the new certificates on the SRM server hosts at the protected and recovery sites. If you intend to continue using SRM 1.0 Update 1 after you install the new certificates, you must install them in a location that does not overwrite the existing certificates.
  2. Back up the SRM databases at the protected and recovery sites.
  3. Update to vCenter 4.0 at the protected site. Follow the instructions in the vSphere Update Guide. It is especially important to back up the vCenter database, since it includes records to which the SRM database holds references. If vCenter inventory, including objects such as folders and resource pools, changes after the SRM database has been backed up, discrepancies between the SRM and vCenter databases can cause problems after the update is complete.
    Note: If the SRM installation you are upgrading specified a non-default port for vCenter, make sure that the vCenter 4.0 server is available at that port. The SRM update installation always uses the vCenter port that the previous SRM installation used. If your vCenter 4.0 installation does not use that port, you must uninstall and reinstall SRM so that you can specify the correct vCenter port.
  4. At the protected site, upgrade your existing SRM server release to SRM 4.0. Follow the instructions in the Administration Guide for vCenter Site Recovery Manager. Note that, while a new installation of this release of SRM installs by default into a different folder: C:\Program Files\VMware\VMware vCenter Site Recovery Manager, an upgrade installation re-uses the existing installation folder (typically C:\Program Files\VMware\VMware Site Recovery Manager).
    Note: If you are using certificate-based authentication, you must follow the upgrade with a repair mode installation, as described in the SRM Administration Guide. An upgrade always uses the existing certificate. You must run the repair mode installation to specify the location of the new certificate. (Because information from the old certificate is used in various ways at the protected and recovery sites, you cannot simply put the new certificate in the same location as the old certificate and run the upgrade installation.)
  5. Upgrade to vCenter 4.0 at the recovery site.
  6. Upgrade to the SRM server to SRM 4.0 at the recovery site. If you are using certificate-based authentication, follow the upgrade with a repair-mode installation, as described in Step 6.
  7. When the vCenter and SRM server upgrades are complete, install the vSphere 4.0 Client plug-in on the host from which you want to manage SRM, and download the SRM Client plug-in from one of the SRM 4.0 servers.
  8. Pair the protected and recovery sites. After pairing is complete, the protection groups and recovery plans that you had created with the previous installation of SRM and vCenter should be available. Running a test recovery is a good way to validate this. If existing protection groups have been marked invalid and datastore groups can no longer be found after the upgrade, run the Configure Array Managers wizard and click Rescan Arrays, as described in the Help topic "Rescan Arrays to Detect Configuration Changes".
  9. Install new SRM licenses. Follow the instructions in the Administration Guide for vCenter Site Recovery Manager.

Note: If you need to revert to an earlier release of SRM, you must also revert to a compatible release of vCenter.

Known Issues

Known issues in the following categories have been identified in this release of Site Recovery Manager:

  • Problems Using Oracle 10g Driver on Win64 Platforms
    A problem with the Oracle 10g driver can cause SRM installation to fail and log the error "TNS: could not resolve the connect identifier specified" when installing SRM on a Win64 platform. On Win64 platforms, 32-bit applications like SRM are installed by default into a path the begins with C:\Program Files (x86)\..., but because of Oracle bug number 3807408, the Oracle 10g driver does not work with applications that are installed in a folder whose path contains parentheses.
    Workaround:When you install SRM on a 64-bit Windows Server, do not accept the default installation path beginning with C:\Program Files (x86)\... Choose a different installation folder, one that does not include parentheses in its pathnames, instead.
  • Use Existing Database Option Fails for a New Installation
    If you create a new installation of SRM 4.0 and specify database connection information for an existing SRM 1.0 or 1.0 Update 1 database, the installer prompts you to choose between using the existing database or creating a new one. If you choose to use the existing database, the installation will fail and the database will be corrupted.
  • VMware vCenter Site Recovery Manager Extension Page Always Shows IP Address of Local Host Instead of Hostname
    If you are using certificate-based authentication, you must also supply the hostname as a fully-qualified domain name in this screen, exactly as it appears in the Subject Alternative Name of your SRM certificate. Accepting the IP address as shown allows installation to complete but causes site pairing to fail with the message "Local and remote servers are using different certificate trust methods".
    Workaround: To recover from this kind of installation error, take the following steps at each SRM site where the IP address was used instead of the hostname:
    1. Change directory to C:\Program Files\VMware\VMware vCenter Site Recovery Manager\config.
    2. Modify the extension.xml file to replace each occurrence of the SRM server's IP address with the fully-qualified domain name of the SRM server host.
    3. Open a Windows command shell and change directory to C:\Program Files\VMware\VMware vCenter Site Recovery Manager\bin.
    4. In the command shell, type
      srm-config -cmd updateext -cfg ../config/vmware-dr.xml -extcfg ../config/extension.xml
    5. Restart the SRM service on the SRM server host.
  • Issues With Upgrade Installation When Existing Installation Uses Non-Default Folder or Ports
    If you upgrade an existing SRM server installation that uses a non-default folder or non-default ports, the upgraded server might exhibit various problems, including existing protection groups becoming invalid.
  • Uninstall Removes Stored Array Manager Credentials
    Uninstalling SRM Server software removes the array manager credentials that are stored on the host. If you reinstall SRM on that host, you must configure the array managers again.
  • Repair-Mode Installation Fails if SRM Server Log File is Open
    If you run the installer in repair mode while any SRM server log file is open, the installation fails.
    Workaround:Close the log file and retry the installation.
  • Installer Drop-Down Does Not Refresh to show a Newly-Created DSN
    When you create a new DSN during installation, the newly-created DSN is not visible in the list of available DSNs.
    Workaround:Cancel and restart the installation.
  • Site Recovery Manager Icon Does Not Appear on vSphere Client Home Page
    If you download the SRM 4.0 plug-in to a vSphere Client in which an older SRM plug-in is installed, the Site Recovery Manager icon may not display on the vSPhere Client home page.
    Workaround: Close and reopen the vSphere Client.
  • vSphere Client Shows "Object reference not set to an instance of an object" if the SRM Server Has Not Been Updated
    If you connect to an updated vCenter server from a client where the SRM 1.0 or 1.0 Update 1 plug-in is installed, the vSphere client displays an error message "Object reference not set to an instance of an object".
  • Installer Fails to Unregister SRM vCenter Extension if Canceled at Extension Registration Point
    When you are installing the SRM server, if you click Cancel while the installer is registering the SRM extension to vCenter, the registration is not removed when the installation is rolled back.
  • Recovering Overwritten Versions of vmware-dr.xml and Other Configuration Files
    An update or repair of SRM overwrites vmware-dr.xml and other configuration files, including certGenUtil.xml and extension.xml. If you have made any changes to these files, you can recover them from the backup files created by the update (for example, vmware-dr.xml.BAK).
  • Length and Character Set Requirements for Passwords.
    SRM PKCS#12 certificate passwords cannot contain more than 31 characters, and must consist entirely of ASCII characters.
  • SRM Service Does Not Start After Reinstallation in a Different Directory.
    If you uninstall SRM and then reinstall it in a different directory on the same host but re-use the database connection created by the previous installation, the SRM service fails to start.
  • Non ASCII Characters are Not Supported in Some Fields
    SRM supports entry of non-ASCII characters in most fields during installation. If you enter a non-ASCII character into a field that does not support it, the installer warns you and requires you to re-type the entry in an acceptable character set.
  • Enabling and Disabling the SRM Plug-in
    The vSphere Client fails to display the SRM user interface if the SRM plug-in is disabled and then enabled.
    Workaround: Close and reopen the vSphere Client after you enable the SRM plug-in.
  • SRM Server Installation Fails and Reports the Error: "Failed to Register Extension"
    During the SRM Server installation, the installation fails and reports the error message: "failed to register extension." SRM reports this error if vCenter Server has license issues. For example, if the vCenter Server isn't licensed, or it lost connection to its license server, registration of the extension fails during installation.
  • Installation fails if DSN has trailing space
    During SRM installation, if you specify a DSN that has a trailing space character (for example, "SRM DB "), the installation fails.
  • A Non-Specific Error Message Displays if the SRM Server is Down During SRM Plug-in Installation
    If the SRM Server is down or unreachable when you try to install the SRM plug-in in the vSphere Client, the vSphere Client displays the message "The remote server returned an error: (503) Server Unavailable."
Roles and Permissions
  • Recovery Virtual Machine Administrator Role has Inadequate Privileges to Protect a Template
    You must manually add the following privileges to this role:
    • VirtualMachine.Provisioning.Mark As Template
    • VirtualMachine.Provisioning.Mark As Virtual Machine
  • Recovery Plan Administrator Must Have Read Permission for All Recovery Plans
    A user who has administrator permission for any recovery plan must be granted read permission for all recovery plans. Assigning read permission for all recovery plans enables the user to access hidden metadata that must be read when an administrator role accesses a specific recovery plan
  • SRM Role Assignments and vCenter
    When you assign a role to an SRM inventory object such as a protection group or recovery plan, that role assignment is not visible in the vCenter Administration Roles pane. You can see it by viewing the properties of the SRM object.
SRM Service Failure
  • SRM Service Fails to Start if SRA is Corrupted or Not Found
    The SRM service will fail to start if an SRA it has been configured to use is uninstalled, becomes corrupted, or is reinstalled in a different directory.
    Workaround: Before you uninstall an SRA, remove any Array Managers that use it. (This may require deleting Recovery Plans, Protection Groups, or both). If you have uninstalled an SRA without following this procedure, you must reinstall it, restart SRM, and then use the correct procedure to uninstall it.
  • SRM Service Fails to Start if vCenter is not Running
    The SRM service will not start unless the vCenter that it extends is running.
    Workaround: Ensure that vCenter is running before trying to start SRM.
vSphere Client and SRM Plug-in
  • Remote vCenter Login Credentials Must Include Domain Name When a Domain Account is Specified
    If you specify a Windows Domain account when the SRM client prompts you for vCenter credentials, you must include the domain name in the user name (for example, DOMAIN\user).
  • Display Refresh Issues When Using Multiple vSphere Clients
    If you are using more than one vSphere Client to manage SRM, changes initiated by one client may not be reflected in the displays of the the other clients.
  • Certificate Warnings when Connecting to SRM
    The SRM plug-in may report a certificate problem warning about a host name mismatch when you connect to a local or remote SRM server. Unless there are other problems with the certificate, you can accept it for this connection.
  • vSphere Client Does Not Display Current Information if the SRM Service Fails
    If the SRM service fails and then reconnects to the SRM Server, the vSphere Client does not display current information for Site Recovery.
    Workaround: Restart the SRM Service and then restart the vSphere Client.
  • vSphere Client Must Be Restarted if it Loses Connection with SRM
    Site connection is not updated if the local SRM server loses connectivity with the remote SRM server.
    Workaround: Restart the vSphere Client after the recovery SRM Server restarts.
  • Unauthorized operations can sometimes be selected
    Some operations for which the user does not have privileges appear to be available in the user interface and can be selected. If they are selected, the operation fails due to an authorization failure.
  • SRM Plug-in is Still Present After the vSphere Client is Uninstalled
    The SRM plug-in is not uninstalled when the vSphere Client is uninstalled. After reinstalling the vSphere Client, the SRM plug-in is still present.
    Workaround: Using the vSphere Client, uninstall the SRM plug-in before uninstalling the vSphere Client.
Site Pairing
  • Invalid ESX Server Certificate Causes Errors During Customization
    Server certificates created by the default ESX installation may appear invalid to SRM and cause errors indicating problems with the server certificate to be logged during customization.
    Workaround: If you cannot install an acceptable certificate on the ESX host, you can disable certificate checking by setting the value of the <disableNFCServerCertificateChecks> parameter in vmware-dr.xml to true. This forces all ESX server certificates to be accepted, and therefore creates a security risk that could potentially compromise the user name and password for any ESX server involved in customization.
  • SRM Reports Errors When Breaking Site Connection
    After attempting to break the protected and recovery site connection, SRM reports the errors: "Unable to break the connection with remote site because it is currently user by other users" and "The request refers to an object that no longer exists or has never existed." These errors appear if the recovery user permissions are changed to "No Access" when the vSphere client is connected to the protected site.
    Workaround: Do not change user permissions to "No Access" from the recovery site while protected site vSphere Client is connected to remote site with this user. If you receive these errors, restart the protected site's SRM service and the vSphere Client.
  • Accepting Thumbprints for Secondary Servers During Site Pairing Reports "Incompatible Authentication Method" Error
    During site pairing, SRM suggests to accept thumbprints for the secondary server. Thumbprint certificate validation during pairing is not a valid option if SRM and vCenter authentication is using trusted certificates.
  • vSphere Client Displays "Loading..." in the SRM Tab if the SRM Server is Unavailable
    If the SRM Server is not installed or available, the "Connect To VMware SRM Server" button displays and the SRM tab displays "Loading..." for the status of each SRM component.
    Workaround: Start the SRM service if it is not running.
  • Configure Array Managers Display is Not Refreshed After Connecting the Protected and Recovery Sites
    After reconnecting the protected and recovery sites, the Configure Array Managers summary information in the vSphere Client is not refreshed and the information is out of sync.
    Workaround: Restart vSphere Client then launch Site Recovery Manager.
  • Protected Sites Shows "Unable to Connect" After Successful Connection
    After successful connection between protected and recovery sites, the protected site reports "Unable to Connect" and eventually reports the error: "Low Resources on Pair..."
    1. Restart the SRM Service.
    2. Close the vSphere Client for the recovery site.
    3. Break the connection and configure connection from the protected Summary page.
    4. Start the vSphere Client and log in to the recovery site.
    5. Select Site Recovery and configure the connection from the remote site.
  • During Site Connection, an SSL Exception error reports: "The host certificate chain is not complete"
    When trying to connect protected and recovery sites, a SSL Exception error reports: "The host certificate chain is not complete." This error occurs if the certificate on the protected site is changed before pairing with the recovery site.
    Workaround: Restart the SRM service on the protected site before pairing with the recovery site.
  • Error Message Displays While Breaking Recovery Site Connection
    Breaking the connection from the protected site to the recovery site displays the error: "Object reference not set to an instance of an object" after the sites are disconnected.
    Workaround: Acknowledge the error message.
  • Cannot Break Connection After the vSphere Client Process is Terminated Abnormally
    You cannot break the connection with the recovery site from the protected site if the vpxClient.exe process is not running. The error message: "Unable to break the connection with the remote site because it is currently used by other users" is reported. Workaround: Restart both SRM Servers then break the connection between the recovery site and the protected site.
  • Inventory Mappings Information is Incorrect
    After breaking and reconnecting site pairing, the vSphere Client at the protection site might not display correct information in Inventory Mappings.
    Workaround: Refresh the Inventory Mappings to display the actual mappings. Click the Refresh button from the Inventory Mappings tab.
  • Pairing Site to Itself Doesn't Fail in the Correct Step
    If you select Site Recovery > Configure and enter the local vCenter Server IP address, SRM continues to the next connection step and asks for user credentials. The connection should fail when the local vCenter Server's IP address is entered.
    Workaround: Do not attempt to pair with the local vCenter Server.
  • When Pairing Sites, Use Trusted Certificates
    When pairing sites and the certificates of the recovery-site vCenter Server and SRM Server are not trusted by the protection-site SRM server, yellow warning triangles, rather than green check boxes, appear to the left of the Certificate Validation steps. The yellow warning triangles warn the user that the given certificates did not pass the validation requirements that the certificates be signed by a trusted Certificate Authority (CA) and have a DNS value matching the address of the server. During the pairing, the user indicated that the certificates should be accepted based on their SHA-1 thumb-prints. It is a serious security violation to accept certificates based on their thumb-prints without verifying that the thumb-prints are correct.
    Workaround: Ensure that both vCenter Servers and both SRM Servers use trusted certificates.
Protection Group
  • Virtual Machine Has Both "Needs Repair" and "Invalid Protection" Status
    The Status line on the Protection Group Summary page lists the number of virtual machines that have a status of Invalid or Needs Repair. Because a virtual machine can have both an Invalid Protection and a Needs Repair status, the total of virtual machines indicated on this line can exceed the number of virtual machines in the protection group. The Repair All button can fix a virtual machine's Needs Repair status, but not its Invalid status.
    Workaround To correct an Invalid protection status, remove the virtual machine from the protection group and reconfigure it so that all of its disks are stored on the same replicated datastore group.
  • Customization Specification Manager Does Not Reflect Changes Made by Batch IP Customization Tool
    If you use the batch IP customization tool to customize IP properties in a recovery group, the Customization Specification Manager window does not reflect those changes even after you refresh the display.
    Workaround Close and re-open the Customization Specification Manager window.
  • vSphere Client Inventory Reports the Error: "The request refers to an object that no longer exists or has never existed"
    After removing a protection group, the vSphere Client Inventory view on the recovery site is not refreshed. Attempting to select an object from the Inventory reports the error: "The request refers to an object that no longer exists or has never existed."
    Workaround: Restart the vSphere Client.
  • Protection Groups Display is Not Refreshed After Connecting the Protected and Recovery Sites
    After reconnecting the protected and recovery sites, the Protection Groups display in the vSphere Client is not refreshed and the information is out of sync.
    Workaround: Restart the vSphere Client.
Recovery Plan
  • Do Not Unregister Protected Virtual Machines Before a Recovery Plan Has Completed.
    If you unregister protected virtual machines at the protected site while a recovery plan is running, their recovered instances might be be removed at the recovery site.
  • Recovery Fails When Recovery Site vCenter and Recovered Virtual Machines are Hosted on the Same ESX Host.
    A recovery plan test might fail during the Reset Disks for Protection Group step if the Recovery Site vCenter Server and one or more recovered virtual machines are hosted on the same ESX host.
    Workaround: Select a different ESX recovery host.
  • Problems Customizing Certain Linux Guest Configurations During Recovery
    Linux guests that are not running an ext2, ext3, or ReiserFS file system may experience customization failures when recovered.
  • SRM Reports the Error: "Cannot execute scripts" When Customizing Windows Virtual Machines During Recovery
    During test recovery or recovery, when Windows guests are customized, occasionally the virtual machines attempt to shut down gracefully and SRM reports the error "Cannot execute scripts." This results in a hard shut down after customization is complete and the virtual machine remains powered off regardless of its recovery plan priority.
    Workaround: Manually power on the Windows virtual machines that report this error.
Test Recovery
  • Failure to connect recovered virtual machine to vDS-backed network.
    When a protected virtual machine is mapped to a recovery site network backed by a VMware vNetwork Distributed Switch (vDS), recovery can fail with the message "Error: Network Device needed by recovered virtual machine couldn't be found at recovery or test time."
  • Failure to Power Down Virtual Machine at Protected Site Causes Spurious Report of Recovery Failure
    If a recovery plan includes a step that powers down one or more virtual machines at the protected site and does not receive confirmation that the requested power-down completed, the recovery plan is reported as failed even though all other steps may have succeeded.
  • A Stop Button Appears After Starting a Recovery Plan Test
    Occasionally, after you start recovery test for the first time, a Stop button appears with the message: "Stop Recovery. Are you sure you want to stop this recovery plan? This process may take several minutes."
    Workaround: Click "No." The test proceeds and completes successfully.
  • Recovery Plan Test Status is "Running Test" After the Test is Canceled
    Canceling a recovery plan test from the task list cancels the recovery plan test, but the vSphere Client displays the status as "Running Test" under Recovery Plans.
  • Converting a Template During a Test Leaves the Virtual Machine Unprotected
    If you test a recovery plan containing a virtual machine template, and during the test you convert the template to a virtual machine and then power it on, the test cleanup steps do not unregister the virtual machine correctly and its protection is lost.
    Workaround: To restore protection, manually power-off and unregister the placeholder virtual machine and then reconfigure protection.
Issues Limited to Specific Versions of ESX and vCenter
  • ESX 3.5: Limitations on Use of VMware Consolidated Backup (VCB)
    Protected Virtual Machines spanning multiple datastores and configured for VCB backup are not supported with ESX 3.5 recovery hosts. Recovery of one of these machines can crash vCenter.
  • vCenter 4.0: vim.fault.InvalidPowerState on powerOn During Recovery Plan Test
    Recovered virtual machines can fail to power on at the recovery site, logging an error of the form vim.fault.InvalidPowerState, when the recovery host is in a cluster.
Miscellaneous Issues
  • Advanced Setting for Command Line Timeout Does Not Apply to Existing Command Steps
    If you use the Advanced Settings Recovery page to enter a new value for Recovery.calloutCommandLineTimeout, the new value applies only to newly-created command steps.
    Workaround: To apply the new value to existing command steps, specify the new value, and then stop and restart the SRM server at the recovery site.
  • Windows Vista File System Virtualization Can Prevent Log Collector From Writing Output
    Windows Vista File System Virtualization can interfere with applications that write to certain folders. The SRM log collector is one such application. The log collector reports that it has successfully written the logs even though it has been prevented from doing so. For more information about Windows Vista File System Virtualization, see http://support.microsoft.com/kb/927387.
  • Some Arrays May Present Too Many iSCSI Targets
    When using the ESX software iSCSI stack, SRM can manage up to 23 iSCSI targets per host. Arrays that present each LUN as a separate iSCSI target may exceed this limit.
  • Some Arrays Might Require a Second Rescan.
    Some storage arrays might require a second rescan to discover LUNs. HP arrays have been identified as having this requirement. To enable the additional rescan, use the SAN Provider settings page of the Advanced Settings dialog box.
  • Long Timeouts for Misconfigured or Corrupted Virtual Machine.
    If a recovered virtual machine does not power on within the specified timeout period, either because it has been improperly configured or has become corrupted during data replication, the recovery plan will wait considerably longer for that virtual machine to timeout than the interval specified by "Change Network Settings" in the recovery plan. This type of abnormally long timeout typically occurs only when applying a customization specification to the virtual machine."
    Workaround: During a test recovery, verify that the virtual machine image is not corrupted (will boot successfully) and has VMware Tools installed before customizing it.
  • Log Collector Does Not Support non-ASCII Encodings
    The log collector does not support use of non-ASCII encodings when writing log files.
  • Japanese Characters in SRM Log Files Use Shift-JIS Encoding
    To read these log files, use a browser, viewer, or editor that can interpret Shift-JIS.
  • Cannot Specify RDM Devices for Templates
    You cannot specify an RDM device in a virtual machine template.
  • Problems When a LUN in a Consistency Groups is Not Part of a Datastore Group
    If a consistency group contains a LUN that is not used as a datastore or as an RDM device, SRM may not be able to recover that consistency group.
    Workaround Add a virtual machine without an OS that has the LUN mapped as an RDM device.
  • SRM is Incompatible with DRS Clusters That Mix ESX 3.5 and ESX 3.0.x Hosts
    SRM does not support using ESX 3.5 and ESX 3.0.x versions of ESX Server in DRS clusters. Virtual machines fail and report errors during customization and resource pool configuration fails.
    Workaround: Create DRS clusters using ESX hosts of the same version.
  • SRM Alarms Appear in the vSphere Client After SRM is Uninstalled
    SRM Alarm Status (if any) is kept after SRM is uninstalled. If the vCenter Server is not reinstalled and you install SRM again, the previous SRM Alarm Status is applied.
  • The srm-config Tool Exits and Reports the Error: "Error [2]: OSERROR [0x80090016] Failed to open crypto key container for certificate"
    During the SRM certificate replacement process, a Windows API can fail with the error message: "Failed to open crypto key container for certificate." This is caused by one of the following:
    • A missing operating system internal file in the following folder:
      C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys
    • Incorrect permissions of one of the following folders:
      C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto
      C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\S-1-5-18
      C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys

    Workaround: Run the command again or fix the permissions.

Configuration Notes

  • RDM Descriptors Must be Placed on a Replicated Datastore
    In order to protect virtual machines that use raw disk mapping (RDM) devices, ensure that the RDM descriptor files reside on replicated datastores. Placing the RDM descriptor files in the same datastore as the .vmx file that refers to them is highly recommended.