Customizing VMware Site Recovery Manager recovery plans with VMware PowerCLI scripts

Using VMware PowerCLI scripts with VMware Site Recovery Manager can help you create a more robust, customized recovery plan. We show you how.

In this quick tip, I'm going to show how you can use VMware PowerCLI scripts as part of your VMware Site Recovery...

Manager (SRM) recovery plan. This quick tip is taken from my soon-to-be-released book on VMware SRM 4.0.

Although you can use classic style batch (.bat) files to carry out command steps in SRM, Microsoft.bat files are not an especially powerful advanced programming interface (API) for manipulating and modifying the vSphere platform. If you want to make more subtle scripts we really need a more robust scripting engine. Fortunately, VMware has for some time embraced the Microsoft PowerShell environment, supplementing it with cmdlets that are specific to managing the VMware virtual environment.

Begin by downloading and installing Microsoft PowerShell to the SRM server at the recovery site, then download and install the VMware PowerCLI tools.

Once you have the PowerCLI environment set up inside the recovery site SRM server, you can start to create .PS scripts. It's worth opening PowerCLI to configure your security settings, and to confirm that you can log in with PowerCLI to the vCenter at the recovery site.

One of the common questions asked on the SRM forums is how to reduce the amount of RAM used by the VMs during the recovery process. This is a common issue because people sometimes have less powerful ESX hosts in the recovery site. They might have less physical memory than the production ESX hosts in the protected site, for example. Using PowerCLI, we can automate the process of reducing a virtual machine's (VM's) RAM allocation by running .PS scripts before the power-on event.

There are a couple of ways of doing this by using PowerCLI. You could have a .PS script for each and every VM and reduce its memory. Below is a sample PS script that would do just that for my VM called ctx01. This script uses the set-vm cmdlet to reduce the recovery VM's memory allocation to 1024MB. The –confirm:$false commands prevents the script from waiting for a human operator to confirm the change:

Example 1
connect-viserver vc4nj.corp.com --user corp\administrator --password vmware Set-VM ctx01 -MemoryMB "1024" -Confirm:$FALSE Disconnect-VIServer –Server vc4nj.corp.com -Confirm:$FALSE

Of course a .PS script for each and every VM would be very administratively intensive, so you might prefer to search for VMs based on their names and make changes that affect many VMs simultaneously. For example, in the .PS script below, the get-vm cmdlet is used to find every VM which starts with the text "ctx" and then "pipelines" this to the set-vm command. This would modify the memory allocation of my VMs ctx01, ctx02 and so on.

Example 2:
connect-viserver vc4nj.corp.com --user corp\administrator --password vmware get-vm ctx* | Set-VM -MemoryMB "1024" -Confirm:$FALSE Disconnect-VIServer –Server vc4nj.corp.com -Confirm:$FALSE

A more sophisticated script would not set a flat amount of memory, but instead check the amount of memory assigned to the VM and then reduce it by a certain factor.

For example, perhaps I wanted to reduce the amount of memory assigned to all the recovered VMs by a factor of a half. The script below finds the current amount of memory assigned to the VM, and then reduces it by 50%. For each VM found with the ctx* string in its name it finds the amount of memory assigned and then uses the set-vm cmdlet to set it correctly.

Example 3:
connect-viserver vc4nj.corp.com --user corp\administrator --password vmware Foreach ($VM  in Get-VM ctx*){ $NewMemAmount = $VM.MemoryMB / 2 Set-VM $VM-MemoryMB $NewMemAmount -Confirm:$FALSE}  Disconnect-VIServer –Server vc4nj.corp.com -Confirm:$FALSE

In my case I decided to use this final method as the way of controlling the amount of memory assigned to the CTX VMs. I would like to thank Al Renouf from the United Kingdom, as he helped write this last example. In case you don't know who Al is, he is very handy with PowerShell and his Virtu-Al blog is well worth a read:

The next part is getting these PS files to be called by SRM. I prefer not to call the .PS script directly but instead I create a .cmd/.bat file, which will call the script at the appropriate time. This helps reduce the amount of text held within the command script step. By using variables in the .cmd/.bat file we can reuse it to call any number of .PS files held on the SRM Server.

Step 1: Create a redirect.bat file
I first came across the redirect.bat whilst reading Carter Shaklin's PowerCLI blog which discussed using .PS scripts with vCenter Alarms.

With help from Virtu-AL's website, I was able to come up with a .bat file that would call my .PS1 scripts. The script loads up the Microsoft Powershell environment, together with the PowerShell console file (.psc1), which allows VMware's PowerCLI to function. The variable at the end (%1) allows for any .PS1 file to be called with a single redirect.bat file.

@echo off
C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe -psc "C:\Program Files\VMware\Infrastructure\vSphere PowerCLI\vim.psc1" "& '%1'"

Step 2: Copy the redirect.bat and powercli.ps script to the recovery SRM Server
The next stage is to copy your redirect.bat and .PS file(s) to location on the Recovery SRM server. It doesn't really matter where you place them, as long as you type the path to the script correctly when you add a command to the recovery plan, it should execute without an error.

In this case, ctx01-ram.ps1, ctx-bulk-ram.ps1 and ctx-ram-half.ps1 represent each of the different examples discussed previously.

Step 3: Add a command to the recovery plan

  1. In the recovery plan, on the Recovery Steps tab, select Recovery High Priority Virtual Machines
  2. Click the Add Command Step button

    Click to enlarge.

  3. Type the full path to the command interpreter (cmd.exe) the redirect.bat file and the .PS file you would like to execute.

Note: In this case, because the dialog box is small and the path to all the files is long, the text has "wrapped." It should read: c:\windows\system32\cmd.exe /c c:\redirect.bat c:\ctx-ram-half.ps1

This will appear in the plan like so:

Click to enlarge.

The location of the .PS script is important. It must be called before the recovery of the high, normal or low VMs. If not, the .PS script will make changes to the placeholder .vmx files rather than the genuine VM .vmx files. Remember, during the "Prepare Storage" stage, the placeholder .vmx files are unregistered from vCenter, and the genuine VM .vmx files take their place. Therefore any changes made to a placeholder.vmx file will simply be ignored and replaced.

You may feel uncomfortable with SRM running these scripts automatically. Another options is to put message steps in the recovery plan and run these commands manually.

Additionally, you may wish to review how to authenticate your PowerShell .PS files to your vCenter. In my case, to keep things simple, I have the username and password as plain text in the .PS file. There are methods of authentication within PowerShell where this is not necessary. (Carter Shanklin's blog discusses using the ability to store encrypted credentials for the local system account such that a username or password need not appear in the .PS file.)

(Warning: Finally, think about the consequences of using PowerCLI to modify VMs for failback. These changes would be replicated back to the protected site should you decide to failback to the protected site. Remember, you are making changes to the VMX file in the case of the memory allocation of VMs. As part of the failback process you may "flip" the replication direction to make changes accrued in the recovery site replicate back to the protected site. To stop this, you would need a PS script that undid the changes made by the recovery plan.)

As you can see, when coupled with VMware SRM PowerCLI can offer all manner of customizations to apply to your VMs and your vSphere4 platform when your recovery plans execute. And it doesn't stop there. In PowerCLI Update 1 a new cmdlet exists called invoke-vmscript. This allows you to call PowerShell and other scripts from within the guest OS of the recovered VMs. But that's the subject of the next tip!


Mike Laverick (VCP) has been involved with the VMware community since 2003. Laverick is a VMware forum moderator and member of the London VMware User Group Steering Committee. Laverick is the owner and author of the virtualization website and blog RTFM Education, where he publishes free guides and utilities aimed at VMware ESX/VirtualCenter users, and has recently joined SearchVMware.com as an Editor at Large. In 2009, Laverick received the VMware vExpert award and helped found the Irish and Scottish VMware user groups. Laverick has had books published on VMware Virtual Infrastructure 3, VMware vSphere4 and VMware Site Recovery Manager.


Dig Deeper on VMware Resources