You can use VMware Site Recovery Manager to protect your VMs and the apps that run on them. When SRM errors occur, follow these steps to easily resolve them.
VMware Site Recovery Manager enables IT administrators to create a reliable recovery plan for their VMs. As is the case with any software, there are situations in which an IT admin might unexpectedly receive error messages. Some of VMware SRM's more common errors include the inability to recover a datastore or a denial of permissions for certain operations. You can easily resolve such errors with a few simple workarounds.
1. Unable to recover datastore
Two main things can cause this error message: If two instances of the same datastore exist at the same disaster recovery (DR) site or if two datastores contain the same data, even if they have different names. You can correct this problem by rescanning the host bus adapter on the DR site, which should cause one of the datastores to disappear.
This problem can also occur when the storage array can't discover the snapshot for the failed-over logical unit number. You can fix this problem by configuring SRM to perform a second rescan. SRM 4.0 and SRM 5.0.1 both give you this option, and you can find it under Advanced Settings in the SanProvider version 4.x or StorageProvider 5.0.1 section.
2. Operation isn't supported on the object
VMware SRM copies over data to a secondary site using vSphere Replication to protect VMs and the applications that run on them. Occasionally, when you attempt to create a protection group or to protect an individual VM, you might receive the following error message:
Unable to create placeholder virtual machine at the recovery site: Recovery virtual machine could not be created: The operation is not supported on the object.
VMware fixed this particular issue in version 4.1.2 of SRM, but you can still find it in SRM version 4.0. The problem comes from an issue with the Video Card RAM Size setting on the affected VM. In most cases, you can fix this problem by editing the Video Card RAM Size setting. If the Auto Detect Video Setting option is enabled, then the actual Total Video RAM Size should be set to 4 MB.
The vSphere client might require you to invoke Edit Settings twice before it allows you to modify the Video Card RAM Size settings. This comes from a limitation to keep you from modifying multiple settings simultaneously.
3. Incompatible device backing specified for device 0
Another common error in VMware SRM is the Incompatible device backing specified for device 0 error. This occurs when SRM attempts to map an invalid or unavailable disk to a VM. Several conditions can trigger this error, but it often occurs when an admin has configured a VM template to use either a virtual floppy drive or a virtual CD-ROM drive.
One common problem with new SRM deployments is the inability to create protection groups.
In this situation, the first step is to convert the template into a VM. After doing so, remove the virtual floppy disk or virtual CD-ROM disk. When you finish, convert the VM back into a template. You should now be able to deploy the template.
4. Permission to perform this operation was denied
One common problem with new SRM deployments is the inability to create protection groups. When this happens, you receive a message that states:
Error -- Unable to create placeholder virtual machine at the recovery site: Permission to perform this operation was denied.
This error message often originates from a permission problem caused by the method of SRM installation.
One major limitation to VMware SRM is that the VMware SRM user must be the same user who installed SRM. As a result, you should create a dedicated account with administrative permissions and use that account for installation, rather than a generic administrator account or your own personal account.
If you must reset permissions, follow this process:
Restart the vCenter Server service on the protected site and on the recovery site.
Restart the SRM service on both sites.
Log in as a local administrator, and connect to vCenter Server on both sites.
Ensure that the user who installed SRM has administrative permissions on both sites.
Break the connection between the two sites, and then reestablish the pairing while logged in as the user who installed SRM.
5. A specified parameter was incorrect
You might also get an indication that the RemoteSite.name parameter is incorrect. This problem tends to occur when the name of a paired site changes unexpectedly. This can happen if you manually change the name using the SRM-Config utility, or it can happen because of a fresh SRM installation.
The only way to fix this issue is to set the name of the remote site so it matches the name stored in the local site's database. To do this, first, determine the remote site name as it exists in the database. You can accomplish this by logging in to the local site using the SRM plugin. The UI's main page should list the paired site's name.
Once you know the name used for the remote site in the local site's database, you must update the remote site to use that name. Use a command prompt window on the remote SRM server. Begin the process by navigating to SRM's bin directory, usually located at C:\Program Files\VMware\VMware vCenter Site Recovery Manager.
Next, run the following command:
SRM-CONFIG –CMD –UPDATEVC –CFG ..\config\vmware-dr.xml –SITENAME "<your original site name>"
When you finish, just restart the SRM service, and then recreate the site pairings.
Next Steps
Decide whether VMware SRM is right for your data center
Learn to use vSphere Replication for disaster recovery
