Best practices, tips and tools for VMware virtual recovery and backup
A comprehensive collection of articles, videos and more, hand-picked by our editors
VMware Site Recovery Manager (SRM) is a disaster recovery product that uses vSphere replication to protect virtual...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
machines and the applications that are running on them. As is the case with any software, there are situations in which an administrator might unexpectedly receive error messages. This article discusses five of the most common VMware SRM error messages and their solutions.
Error: Unable to Recover Datastore
There are two main things that can cause this error message. First, the error can occur if two instances of the same datastore exist at the same disaster recovery site. The error can also occur even if the datastores themselves have different names so long as they contain the same data. You can correct this problem by rescanning the host bus adapter on the disaster recovery site, which should cause one of the datastores to disappear.
Another way this problem can occur is when the storage array is unable to discover the snapshot for the failed over LUN. The fix for this problem is to configure SRM to perform a second rescan. This option exists in SRM 4.0 and in SRM 5.0.1, and can be found under Advanced Settings in the SanProvider (version 4.x) or the StorageProvider (5.0.1) section.
Error: Operation Not Supported on the Object
Occasionally, when you attempt to create a protection group or when you attempt to protect an individual virtual machine, 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
This particular issue was fixed in version 4.1.2 of SRM, but is very common with SRM version 4.0. The problem is related to an issue with the Video Card RAM Size setting on the affected virtual machine. In most cases, you can fix this problem by editing the Video Card RAM-size settings. If the Auto Detect Video Setting option is enabled, then the actual Total Video RAM Size should be set to 4 MB.
It is also worth noting that the vSphere client might require you to invoke the Edit Settings twice before you will be allowed to modify the Video Card RAM Size settings. This is due to a limitation that keeps you from modifying multiple settings simultaneously.
Error: Incompatible Device Backing Specified for Device 0
Another common error in VMware SRM is the Incompatible Device Backing Specified for Device 0 error. This error occurs when SRM attempts to map an invalid or unavailable disk to a virtual machine. There are several conditions that can trigger this error, but it is often related to a virtual machine template that has been configured to use either a virtual floppy drive or a virtual CD-ROM drive.
In this type of situation, the first step to fixing the problem is to convert the template into a virtual machine. After doing so, remove the virtual floppy disk or virtual CD-ROM disk. When you are done, convert the virtual machine back into a template. You should now be able to deploy the template without receiving the error.
Error: Permission to Perform this Operation was Denied
One of the more common problems with new SRM deployments is the inability to create protection groups. When this happens, you might see a message that states, “Error -- Unable to create placeholder virtual machine at the recovery site: Permission to perform this operation was denied.” Often this error message is the result of a permission problem caused by the way SRM was installed.
One of the big limitations to VMware SRM is that the user of VMware SRM must be the same as the user who installed SRM. Therefore, it is better to create a dedicated account (that has administrative permissions) and use that account for installation than to use a generic administrator account or your own personal account.
If you need to reset the permissions, follow this process:
- Restart the VirtualCenter 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 the vCenter Server on both sites
- Be sure that the user who installed SRM has administrative permissions within both sites
- Break the connection between the two sites and then reestablish the pairing while logged-in as the user who installed SRM
Error: A Specified Parameter Was Not Correct. RemoteSite.name
Another fairly common error is an indication that the RemoteSite.name parameter is not correct. This problem tends to occur when the name of a paired site changes unexpectedly. This can be due to the name being manually changed using the SRM-Config utility or it can be due to 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 that is stored in the local site’s database. To do this, first determine the remote site name as it exists in the database. The easiest way to accomplish this is to log into the local site using the SRM plugin. The paired site’s name will be listed on the user interface’s main page.
Once you know the name that was used for the remote site then you need to update the remote site to use that name. This must be done from a Command Prompt window on the remote SRM server. Begin the process by navigating to SRM’s BIN directory.
It is usually located at C:\Program Files\VMware\VMware vCenter Site Recovery Manager.
Next, you must run the following command:
SRM-CONFIG –CMD –UPDATEVC –CFG ..\config\vmware-dr.xml –SITENAME “<your original site name>”
When you are done, just restart the SRM service and then recreate the site pairings.
About the author: Brien M. Posey, MCSE, has received Microsoft’s MVP award for Exchange Server, Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and has been responsible for the Department of Information Management at Fort Knox. You can visit Brien's personal website at www.brienposey.com.