posted

2 Comments

Hello all,

I thought I would start a new series of blog posts, over the next few months, on scripting in the SRM world. This is important to many of you I know as I hear about it a lot.  This first blog is about setting up to do scripting.  We will use a simple script as an example but really this blog is about making scripts work with SRM.  In the next several articles in this series I will use realistic examples that everyone can use like ones connected to IP customization, Oracle, and Apache .

I should point out that I am not a script writing guy.  But I am learning and will have help along the way to make sure you all get great value.  But if you ask me hard script questions, I may have to suggest you look in a different place.

Today we will use a batch file, but our next articles are going to concentrate on PowerShell and PowerCLI.  This is what I see most often, and for me, and many of the customers I meet, it is also the easiest way to get into scripting.  So that is what I will use too!

Lets get started and have a script executed as part of our failover!  This script is to track when VM's start, and if they start.  It will generate a log file of the start up of VMs.

Setup

I suggest you create a folder called scripts on the recovery side SRM server.  This is where the scripts will be held, and they will be executed from the SRM server using the Local Security of that server.  Which means you may have issues if the scripts are on network shares and that is why I strongly reccomand that local folder!

We are going to copy our scripts to that folder.  It is important to understand that you should have a script that SRM executes, to call the actual script.

Calling script

This script is called call.cmd and it contains almost nothing.  See below what mine looks like.  The purpose of this script is to execute the 'real' script.

Callcontent

Test script

This is the script that is going to do some work!  It looks a little more interesting than the call.cmd file.

ImprovedSCript
There is a number of interesting things here.  It is a simple batch file, but it is calling some environment variables that SRM provides during the execution of the recovery plan.  On page 51 of the SRM Admin guide you can learn more about these variables.  I show some here as an example and something cool to play with!  This script will write the date / time and several environment variables to a text file.

It is important to note, that in both scripts, full paths are used.  This is important as it will prevent issues.  Do not forget.

Testing the script

You should now execute the script from the DOS prompt on the SRM server in the scripts folder.  In my experience, I use the DOS prompt as I can see more errors or potential errors that way.  In our case here, we make sure the date / time is in the log file.  Our SRM environment variables will not be in the log but that is ok since we are not doing a recovery.

Adding the script to SRM

Now that we know the script works fine, we need to add it to SRM.  Do we need to execute this script before a VM starts, or after it starts?  Before means pre, and after it starts it is post.

  1. Start on the Recovery Side in the vSphere client,
  2. Once in SRM, select the Recovery Plan you wish to add the script to.
  3. Change to the Virtual Machine tabs, and highlight the VM you wish to make changes to.  See below for what this should look like.

  FRomVMonRP

 Use the Edit button as shown above to edit the VM you wish to add the script to.  You will end up in a dialog like you see below.

Editproperties
Now use the Next button to proceed until you are on the Post Power On screen.  You will need to use the Add Command option to enter your calling script information.  This information is:

c:windowssystem32cmd.exe /C "c:scriptscall.cmd"

See below for what this looks like.

Scriptcommandline
You can have a variety of different commands, or message callouts here but in my example above there is only the calling script.

Once you press the Finish button the script will execute the next time that VM is recovered.

In our example we are executing a script after a VM is running.  This is because we want information about that VM in a log file. But there are other places you can execute a script.  See another blog I wrote about this here.

Execution

You will be able to see a reference to your script in the recovery plan.  You can see it in a screen shot below from during the recovery plan operation.

Scriptexecut
As soon as the VMware Tools notify SRM that the VM has started successfully, the script will be the next thing done – as seen above.

If we look in the test.log file to see what the log looks like after our plan has finished executing, we can see below what it would look like.

Scriptoutput

As well, you can look in the history report to see how things went.  Below is a snippet that covers off our script.

History

Summary

You have learned to use a local folder on the SRM server, where you will have your calling batch file, and your script.  In our case the script was a batch file as well.  It is important in both batch files (or scripts) to always use full path information.  Also always use a calling batch file to start your script.

Conclusion

You have now learned how to execute a script from within SRM.  In our case here today we did a simple batch file that just wrote to a log and in the future we will cover off other types of scripts that do important and useful things.

Further Learning

Developer Community at VMware 

API that scripters can use to impact inside of VM's – called VIX 

PowerCLI – add in for PowerShell that provides access to vSphere

SRM Admin Guide – for the environment variables you can call from within a script.

Can a script stop recovery plan?

Getting started with PowerCLI – this is a great blog to get started with PowerShell and PowerCLI which are likely the tools you will most frequently use with scripting and SRM.  At least in the Windows world.

Thank you for reading and have  great day!

Michael