VMware vCenter Site Recovery Manager 4.1 Release Notes
Site Recovery Manager 4.1 | 13-July-2010 | Build 267817
VMware vCenter Site Recovery Manager 4.1 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.
- 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.
- 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 and fixes:
- Full compatibility with vCenter 4.1.
- Support for IP customization of Windows 7 and Windows Server 2008 R2.
- Test recovery times have been improved for ESX 4.0.1 hosts that use iSCSI arrays.
- Full compatibility with vCenter Solution Licensing.
- New configuration file options: change guest operating system shutdown retry timeout when customizing IP address during recovery, and change datastore discovery timeout during recovery (see Configuration Notes).
- Full support for networks backed by a VMware vNetwork Distributed Switch (vDS) at the protected and recovery sites.
- Fixes for several problems identified in previous releases. For more information, see VMware Knowledge Base Articles 1019890, 1021827, 1021491, 1021829, 1017882, 1021919, and 1021920.
SRM 4.1 server software can be installed only on 64-bit host platforms. The SRM 4.1 server is incompatible with 32-bit hosts. The SRM 4.1 client plug-in remains compatible with 32-bit hosts. Regardless of the database server you are using, you must install a 32-bit database client (ODBC driver) on the SRM server host. The SRM server is not compatible with 64-bit database clients.
SRM 4.1 is designed for compatibility with vCenter 4.1. SRM 4.1 is incompatible with vCenter 4.0 and earlier releases.
SRM 4.1 can be installed as a new release or as an update to SRM 4.0.
You cannot install SRM 4.1 as an update to SRM 1.x releases.
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.1 in one of two ways:
- As a new installation on a 64-bit server host. This installation can either create a new SRM database or update an existing SRM 4.0database.
- As an update of an existing SRM 4.0 installation on a 64-bit server host, which also updates an existing SRM 4.0 database to the SRM 4.1 schema.
- 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.
Note: If the SRM host is unable to contact vCenter during SRM installation, the installer will retry the connection for up to 30 minutes. Canceling the installation during the retry period can have unpredictable results. If you cannot correct the problems with the connection between SRM and vCenter, you should allow the retry timeout to expire so that the installer can terminate gracefully and roll back.
Creating a New Installation of SRM 4.1
To create a new installation of SRM 4.1, follow the instructions in the Administration Guide for vCenter Site Recovery Manager.
Updating a 64-Bit SRM 4.0 Server Host to SRM 4.1
Follow this procedure to ensure a successful update:
- Back up the SRM databases at the protected and recovery sites.
- Update to vCenter 4.1 at the protected site. Follow the instructions in the vSphere Update Guide. This update has the following additional requirements:
- 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.
- Do not change the IP address or hostname of the vCenter Server. The hostnames of the local and remote vCenter Servers are stored in the SRM database. If either of those hostnames changes, the SRM database will be invalidated.
- If the SRM installation you are updating specified a non-default port for vCenter, make sure that the vCenter 4.1 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.1 installation does not use that port, you must uninstall and reinstall SRM so that you can specify the correct vCenter port.
- At the protected site, update your existing SRM server release to SRM 4.1. Follow the instructions in the Administration Guide for vCenter Site Recovery Manager. Be sure to use a copy of the original database. Errors or a cancellation during the upgrade process can corrupt the SRM database. 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 update installation re-uses the existing installation folder (typically C:\Program Files\VMware\VMware Site Recovery Manager).
- Update to vCenter 4.1 at the recovery site. This update has the same requirements listed in Step 2.
- Update to the SRM server to SRM 4.1 at the recovery site.
- When the SRM server updates are complete, install the vSphere 4.1 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.1 servers.
- 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 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 update, run the Configure Array Managers wizard and click Rescan Arrays, as described in the Help topic "Rescan Arrays to Detect Configuration Changes".
- 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.
Migrating SRM to a New Server Host
SRM 4.1 supports only 64-bit server host platforms. If you need to migrate an existing SRM server from a 32-bit host to a 64-bit host, taking these additional steps will help you preserve your server configuration during the migration.
- Back up the SRM databases at the protected and recovery sites.
- Make a backup copy of the SRM configuration from the 32-bit host. The default location of this file is: C:\Program Files\VMware\VMware Site Recovery Manager\config\vmware-dr.xml.
- Create a new installation of SRM 4.1 on the 64-bit platform. Follow the instructions in the Administration Guide for vCenter Site Recovery Manager. This installation has the following additional requirements:
- If you are re-using the existing SRM 4.0 database, you must use a copy of the original database. Errors or a cancellation during the upgrade process can corrupt the SRM database.
- If you are re-using the existing SRM 4.0 database, you must specify the hostname and port of the local and remote vCenter hosts exactly the way you specified them in the previous (SRM 4.0) installation. For example, if the hostnames were specified as fully-qualified domain names, you must enter the same fully-qualified domain names during the installation of SRM 4.1. The hostname and port of the local and remote vCenter Servers are stored in the SRM database. If either of those hostnames or ports changes, the SRM database will be invalidated.
- If the new installation fails for any reason but succeeds on a re-try, you will not be prompted to install the SRAs. If you are re-using the existing SRM 4.0 database, you must install SRAs for the same arrays that were used by the previous SRM server host (the one from which you have migrated) before you connect to SRM. You may need to download new versions of these SRAs if the old ones are not compatible with the new host platform.
- Using the new installation of SRM 4.1, open a vSphere Client and connect to the vCenter server at the protected site. Log in as a vSphere administrator.
- On the vSphere Client Home page, click the Site Recovery icon. If you have used the Advanced Settings dialogs in SRM 4.0 to modify advances settings for your SRM installation, you can migrate those changes to the new installation by following the steps in Migrating Changes to Advanced Settings below. If you plan on taking these steps, do so before you proceed to step 6.
- Configure the protected and recovery sites, as described in the Administration Guide for vCenter Site Recovery Manager. You will need to re-create the site pair, and re-configure the array managers, supplying any authentication information they require.
Migrating Changes to Advanced Settings
SRM 4.0 introduced Advanced Settings dialogs that enable you to view or change many custom settings for the SRM service. If you have used those dialogs to make changes to advanced settings, you can take the following steps to migrate those changes to the new installation. If you have not made any changes to advanced settings, or do not want to preserve the ones you made, you do not need to take these steps.
- Right-click Site Recovery in the vSphere Client navigation pane and click Advanced Settings.
In the navigation pane of the Advanced Settings window, click a setting category. Open the vmware-dr.xml file you
created in Step 1 in a text editor that supports searches. Search for that category name (for example, localSiteStatus) in the file.
- If you do not find that category name in the saved vmware-dr.xml, proceed to the next category in Advanced Settings.
If you find that category name in the saved vmware-dr.xml file, examine the contents of the XML element to discover the values that
had been set on the 32-bit host. For example, if the search finds a category named localSiteStatus in vmware-dr.xml, you can extract the values
from each element and use them to update the values in the Advanced Settings > localSiteStatus page:
<localSiteStatus>To update the 64-bit installation of SRM with these values, make the following changes on the Advanced Settings > localSiteStatus page:
- Set the the localSiteStatus.checkInterval field to 60.
- Set the the localSiteStatus.eventFrequency field to 600.
- Set the the localSiteStatus.logLevel field to "warning".
- Set the the localSiteStatus.maxCpuUsage field to 70.
- Set the the localSiteStatus.minDiskSpace field to 100.
- Set the the localSiteStatus.minMemory field to 32.
- Set the the localSiteStatus.logLevel field to "warning".
- Repeat this procedure for each of the Advanced Settings pages for which you find a category match in the saved vmware-dr.xml
Known issues in the following categories have been identified in this release of Site Recovery Manager:
- Roles and Permissions
- SRM Service Failure
- vSphere Client and SRM Plug-in
- Site Pairing
- Protection Group
- Recovery Plan
- Test Recovery
- Issues Limited to Specific Versions of ESX and vCenter
- Miscellaneous Issues
- 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.
- Cancellation or Other Error During Installation Corrupts Existing SRM Database
If you are installing SRM 4.1 and updating your existing SRM 4.0 database, an error or cancellation during the installation process corrupts the database you are using. Be sure to use a copy of your SRM 4.0 database whenever you are performing this kind of installation.
- "Failed to Start Service" Error After Canceling Installation While Starting the SRM Service
If you are installing SRM 4.1 and cancel the installation during the "Starting the SRM Service" step, a "Failed to Start Service" message appears. To recover, click the Cancel button on the "Failed to Start Service" page.
- Internal Error After Canceling Installation While Installing DB Credentials
If you are installing SRM 4.1 and using an existing database, canceling the installation while the message "Installing DB credentials" is displayed causes the installer to fail with the message "Internal error -1". After this failure, you cannot re-start the installation and use the existing database. To recover, re-start the installation using a backup copy of the database.
- 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:
- Change directory to C:\Program Files\VMware\VMware vCenter Site Recovery Manager\config.
- 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.
- Open a Windows command shell and change directory to C:\Program Files\VMware\VMware vCenter Site Recovery Manager\bin.
In the command shell, type
srm-config -cmd updateext -cfg ../config/vmware-dr.xml -extcfg ../config/extension.xml
- Restart the SRM service on the SRM server host.
- Issues With Update Installation When Existing Installation Uses Non-Default Folder or Ports
If you update an existing SRM server installation that uses a non-default folder or non-default ports, the updated 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
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
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
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."
- 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
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 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
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.
- 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
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
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
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.
- 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
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"
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..."
- Restart the SRM Service.
- Close the vSphere Client for the recovery site.
- Break the connection and configure connection from the protected Summary page.
- Start the vSphere Client and log in to the recovery site.
- 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
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
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.
- 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
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
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.
- 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
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.
- Cannot Pair Recovery Site With a New Protected Site
A topic entitled Configuring and Executing Failback in the Site Recovery Manager Administration Guide states that you can "... establish a new recovery site...and then promote the old recovery site to a protected site" after an event that has rendered the original protected site unusable. You cannot pair one member of an existing SRM site pair with a new member. If the original protected site cannot be restored, you must reinstall SRM and create a new SRM database at both sites, then create a new site pair.
- Failure to Power Down Virtual Machine
at Protected Site Causes Spurious Report of Recovery
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.
- ESX 3.0.3: Limitations on Guest Customization When SRM Server Host Platform is Windows 2008 R2
When the SRM server is installed on a host running Windows 2008 R2 (64-bit), IP customization is not supported for virtual machines recovered on an ESX 3.0.3 host.
Workaround: Use a later release of ESX as the recovery host, or install the SRM server on a different version of Windows.
- 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.
- Expired SRM Evaluation License Not Listed or Listed as 'Unlicensed' In Manage vSphere Licenses Window
When your SRM evaluation license expires, vSphere considers SRM to be unlicensed, rather than using an expired evaluation license. To correct this problem, install a valid SRM license key.
- 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
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
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
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
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 : 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
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.
- A missing operating system internal file in the following folder:
- Configurable Customization Shutdown Retry Timeout
When SRM requests a graceful shutdown of a recovered virtual machine as part of IP customization, it retries the request if necessary every ten seconds until the request succeeds or ten minutes have elapsed since the initial request, and then it forces the recovered virtual machine to shut down. You can configure the amount of time that SRM continues to retry before forcing a shutdown by adding a new element, CustRetryShutdownTimeout, to the SRM configuration file. The default location of this file is: C:\Program Files\VMware\VMware Site Recovery Manager\config\vmware-dr.xml. The contents of this element is an integer that specifies the number of seconds that the retries continue before the shutdown is forced. This example reduces the retry period to five minutes.
- Configurable Datastore Discovery Timeout
When SRM requests an ESX host to rescan for new datastores, SRM waits for 30 seconds and then assumes that all new datastores have been discovered. You can configure a longer or shorter waiting period by adding a new element, hostVmfsRefreshTimeout, to the SRM configuration file. The default location of this file is: C:\Program Files\VMware\VMware Site Recovery Manager\config\vmware-dr.xml. The contents of this element is an integer that specifies the number of seconds that SRM waits for new datastores to be discovered. This example increases the wait to 60 seconds.
- RDM Descriptors Must be Placed on a Replicated Datastore
When protecting 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.