My recovery site is only using x number of hosts to start VM’s but it should be using y number.
When I experienced this, it was due to the host that was not starting VM’s not having access to the storage array. This was due to it not having a VMkernel port that LHN required. I have seen this with other vendor where there was no security between the ESX host in questions and the storage array. There are no error messages associated with this situation so make sure you test for it. I have seen a similar error where the single host at the recovery site didn’t have an IP entered for the iSCSI array.

Priority Levels in Recovery Plan don’t reflect my changes.
You have made changes in the Protection Group to the priority level of some of your protected VM’s. But when you refresh the Recovery Steps you see your VM’s with the original priority and not the new that you changed in the Protection Group. This is correct behavior. It may be improved in the future. It is due to the difference in security permissions on both sides. It would be possible from someone on the Protected side to make changes that affect VM’s on the recovery side. This may or may not be appropriate. Until there is a good solution, just right click on the VM in question and use the Move Up or Move Down options to change its execution order priority.

Error:Expected virtual machine file path ….. vm-vmname/vm-vmname.vmx cannot be found
This can occur during test or recovery and it means quite simply the VM reference in the error is not in the replicated SAN datastore where it is expected. This most often occurs when you add another VM to the protected datastore and before it has time to replicate start a test recovery. The solution is to wait until the replication catches up and try the test again.

Database access issues
Use Windows Authentication if the DB server is local to the SRM server, and SQL Authentication if the DB server is remote to the SRM server.

How can I tell the SRM version from the log files?
The first line of the SRM log files will hold the release info. The version=1.0.0 tells the version and build=build-97878 tells the build.

Installation logs
You can create an installation log using the command line parameters of /s /V”lve installlog.txt”. The command line will look like:

VMware-srm-1.0.0=.exe /s /V”lve installlog.txt” .

How do I change the log level?
You can easily change the log level by editing a configuration file. However, to have that change read by SRM you will need to restart the SRM service. The file name is vmware-dr.xml and is found by default in C:\Program Files\VMware\VMware Site Recovery Manager\config . Remember that when you restart the service that you will interrupt anyone working with SRM.

Look for the line that looks like:
C:\Documents and Settings\All Users\Application Data\VMware\VMware Site Recovery Manager\Logs

Below it you will find a line that looks like:
<level>verbose</level>

You can change the verbose to trivia, which will generate more entries, or to info, which generates less. In the RC builds it didn’t seem to make much of a difference what the setting was.

No available Customization specifications found.
You can create customizations using the View \ Edit Customization command in the VI client. This is how you can change a network setting in a recovery. This is like sysprep, and you are required to fill in all of the necessary information, but only the network info will be used. You will need to create your customization specification on the recovery site. Remember that you can export and import customizations so if necessary it doesn’t take much to move them between your protected and recovery sites.

Net::SSLeay::load_error_strings
This comes from the Perl module for OpenSSL, which is required by some SRA’s (such as NetApp) and means that perl is not installed on the recovery SRM server.

Is there a limitation of DR failover LUNs for some iSCSI arrays and some Hosts?
There is a hard limit of 64 iSCSI arrays per host. However, when using SRM there is a limit of approximately 23 recovery LUNs on the recovery side only. For more information about this please visit http://kb.vmware.com/kb/1005867 . This is not specific to SRM but to any DR setup you might test.

A general system error occurred – unable to get configuration information for the recovery VM
This error will occur when a VM has been added to a protected datastore, and is part of a recovery plan, but during test fail over it has not be replicated so it is not available to the recovery side. This can happen during a non – test failover as well. This can happen with LHN but the error message is more obvious of the problem.

Failed to launch SAN integration scripts
If you are using SRDF and get the error below when configuring your array you have a path issue. The error is “Failed to launch SAN integration scripts to execute discoverArrays command.” The issue is a missing path to the SYMCLI folder in the path. The solution is to add the path to the SYMCLI bin folder to the System variables PATH environment. The default path is C:\Program Files\EMC\SYMCLI\bin and you will need to restart the SRM server service after the PATH change. This exact error is from an issue with SRDF it may occur with other SRA’s from other or the same vendor.

No visible LUN’s during configuration of the array
This will occur if there is NO VM’s in the protected datastore. Add a VM to the protected datastore and the LUN will be visible in the array configuration.

Null parameter name:key error 
If you are adding a protection group and you get a error with a value of null parameter name:key in it, the solution at this time is to restart the SRM service on both the protected and recovery sites.

Missing testbubble switch on recovery host.
When you are checking your test recovery VM’s for network connectivity you find that while one ESX host worth of VM’s can talk to each other, but on other ESX hosts there is no connectivity. Further checking shows that only one recovery ESX host has the testbubble switch and the other hosts do not have that switch even though the recovery VM’s are configured to use it. Therefore the VM’s configured to use the test bubble switch that doesn’t exist will not be able to communicate.

Review Replicate Datastores window of Array Manager is blank.
When you are configuring your SRA and the last step in it is to show you the replicated LUN’s, but you see nothing you have a problem. Using the Rescan button doesn’t cause the LUN(s) to be displayed. To work around this issue, use the following steps:

1. In the VI Client,
2. Goto the ESX host configuration area
3. Now select Storage
4. In the upper right area select the Refresh option.
5. Now return to the SRM Array Manager configuration,
6. Select Rescan,
7. Than select Back,
8. Now select Next
9. You should now see your LUN information displayed.