Yellow Bricks

by Duncan Epping

srm

SRM: Automatically rename your datastore back

· ·

When doing a failover with SRM your VMFS Datastores get labeled with a “snap-xxxxxxx-name” because they’ve been resignatured. Mike Laverick gave this tip on the VMTN forum which enables you to automatically rename your datastores to it’s original name again:

Edit the vmware-dr.xml file in the C:\Program Files\Site Recovery Manager\Config directory and look for a line that reads:

  • <fixRecoveredDatastoreNames>false</fixRecoveredDatastoreNames>

Change it to:

  • <fixRecoveredDatastoreNames>true</fixRecoveredDatastoreNames>

SRM 1.0 Update 1, patch 3

· ·

I just noticed this SRM update, it’s just a small patch but looking at the problems it corrects it might be beneficial to upgrade!

Site Recovery Manager 1.0 Update 1 Patch 3 Latest Release Version: 1.0.1.2587 | 04/09/09 | 154949

This patch corrects the following problems:

  • a problem that prevents protected virtual machines from following recommended Distributed Resource Scheduler (DRS) settings when recovering to more than one DRS cluster.
  • a problem observed at sites that support more than seven ESX hosts. If you refresh inventory mappings when connected to such a site, the display becomes unresponsive for up to ten minutes.
  • a problem that could prevent SRM from computing LUN consistency groups correctly when one or more of the LUNs in the consistency group did not host any virtual machines.
  • a problem that could cause the client user interface to become unresponsive when creating protection groups with over 300 members several problems that could cause SRM to log an error rmessage vim.fault.AlreadyExists when recomputing datastore groups.
  • a problem that could cause SRM to log an Assert Failed: “ok” @ src/san/consistencyGroupValidator.cpp:64 error when two different datastores match a single replicated device returned by the SRA.
  • a problem that could cause SRM to remove static iSCSI targets with non-test LUNs during test recovery several problems that degrade the performance of inventory mapping.

SRM install log files

· ·

I was rebuilding my lab this evening and ran into some weird problem during the installation. I wanted to debug it but couldn’t find the log files. After a quick search on the VMTN forum I found the following, which creates a log file called “SRMinstall-log.txt”:

VMware-srm-1.0.1-128004.exe /V"/lve SRMinstall-log.txt"

I know it’s a weird looking format, but it actualy works! Of course if you’re using a different version you should change the .exe accordingly. Thanks Lee aka Smoggy.

SRM: Running a script from a Recovery Plan

· ·

I got a question today from one of my customers on how to run a script from an SRM Recovery Plan. They tried everything but never got it working. It’s fairly easy, although you would need to take a couple of things in consideration. And reading the SRM Admin Guide page 52 and 53 wouldn’t harm you as well. But then again we’re talking technical people here, who reads the manual? (Besides Mike Laverick aka Mr RTFM of course. Mike, btw, also recently released the third chapter of his SRM book for free, which is most definitely worth reading!!)

I guess the most important things to remember if you want to run commands/batch files from SRM are:

  • SRM can only execute .exe or .com files, if you need to run a batch file do the following: 
    c:\windows\system32\cmd.exe /c c:\yellow-bricks.bat
  • Scripts must reside on the host where the SRM server is installed.
  • SRM callouts to batch files or commands run as the local administrator of the SRM server host, and not as the user logged into the VI Client.
  • A recovery terminates if a command or script exits with a non‐zero status.
  • If the script call out takes longer than 300 seconds to complete it will be terminated. You can increase this by changing/adding the following line in vmware-dr.xml with the desired value: 
    <calloutCommandLineTimeout>600</calloutCommandLineTimeout>

SRM: Changing the admin email address after installation

· ·

One of my customers asked me how they could change the administrator email address after the installation of SRM. He turned the GUI upside down but couldn’t find it anywhere. Extension.xml is the configuration xml file where you can change the Administrator Email:

<adminEmail>admin@yellow-bricks.com</adminEmail>