One of the updated capabilities in the new Site Recovery Manager 5.8 release is the ability to change some recovery settings like the recovery priority and script callouts via the SRM API. With the release of PowerCLI 5.8 R1 these capabilities are also exposed for scripting via the SRM API!

To make it easier to script against the API in PowerCLI I’ve been working on some helper SRM functions and have updated them to support some of the new capabilities.

Here’s a short example using PowerCLI to update the recovery priority of a VM and add a new post recovery call-out.

And here’s some code to perform something similar to what was done in the video using the custom SRM functions [at 2014-11-17].

# Load the custom functions
. ./SrmFunctions.ps1
. ./Examples/ReportConfiguration.ps1

# Connect to protected site VC & SRM
$creds = Get-Credential
$vca = Connect-VIServer vc-w12-01a.corp.local -Credential $creds
$srma = Connect-SrmServer -Server $vca -Credential $creds -RemoteCredential $creds

# Output Current SRM Configuration Report
Get-SrmConfigReport

# get recovery plan
$rp = Get-RecoveryPlan "Anaheim"

# get protected VM
$pvm = $rp | Get-ProtectedVM | Select -First 1

# view recovery settings
$rs = $pvm | Get-RecoverySettings -RecoveryPlan $rp

# update recovery priority
$rs.RecoveryPriority = "highest"

# create new command callout
$srmCmd = New-SrmCommand -Command '/bin/bash /root/failover.sh' -Description 'Run standard linux failover script' -RunInRecoveredVm

# add command as post recovery command callout
Add-PostRecoverySrmCommand -RecoverySettings $rs -SrmCommand $srmCmd

# update the recovery settings on the SRM server
Set-RecoverySettings -ProtectedVm $pvm -RecoveryPlan $rp -RecoverySettings $rs

# validate recovery settings (view in report)
Get-SrmConfigReportProtectedVm

One of my colleagues Ken Werneburg recently wrote a great blog post about executing an SRM failover via PowerCLI. Ken does a great job of explaining some of the caveats around this feature and how you would actually make the call using PowerCLI. Looking at the code provided I thought it would be a good candidate for encapsulating in a custom function. I wrote recently about using custom functions to simplify using the SRM API from PowerCLI and I think this use case would be a great example.

In Ken’s example he is coding against the raw API from PowerCLI and you have to deal with code like this:

$RPmoref = … # Set the recovery plan we want to use

# define the recovery plan mode we want to use ('1' is a test)
$RPmode = New-Object VMware.VimAutomation.Srm.Views.SrmRecoveryPlanRecoveryMode
$RPmode.Value__ = 1

# start the test
$RPmoref.Start($RPmode)

While this is not too hard to follow it does require that the user to create recovery mode objects using “magic” numbers in the code. Using custom functions we can hide that away and deliver something much nicer. What I would like us to get to is something like:

Start-RecoveryPlan -RecoveryPlan $Plan -RecoveryMode Test

Or even:

Get-RecoveryPlan -Name 'Failover Site A' | Start-RecoveryPlan

So, how do we get there?

First let’s determine how we want to be able to call the functions and specify the parameters we will accept. Here’s my first crack at this:

<#
.SYNOPSIS
Start a Recovery Plan action like test, recovery, cleanup, etc.

.PARAMETER RecoveryPlan
The recovery plan to start

.PARAMETER RecoveryMode
The recovery mode to invoke on the plan. May be one of "test" (the default), "recovery", "cleanup", and "reprotect"
#>
Function Start-RecoveryPlan () {
    Param(
        [Parameter (Mandatory=$true, ValueFromPipeline=$true)] $RecoveryPlan,
        [VMware.VimAutomation.Srm.Views.SrmRecoveryPlanRecoveryMode] $RecoveryMode = 'Test'
    )

    #TODO
}

<#
.SYNOPSIS
Stop a running Recovery Plan action.

.PARAMETER RecoveryPlan
The recovery plan to stop
#>
Function Stop-RecoveryPlan () {
    Param(
        [Parameter (Mandatory=$true, ValueFromPipeline=$true)] $RecoveryPlan
    )

    #TODO
}

A couple of things to note here. First we can directly use the SrmRecoveryPlanRecoveryMode type when defining the parameter. The PowerCLI team have made this an enum type so we get some nice behavior out of the box in terms of type casting. The second thing to note is that we are going to default to a ‘Test’ operation. I am doing this as I don’t want to get into the scenario where we default to a recovery and someone initiates a disruptive failover instead of a test or cleanup, simply because of a scripting error.

Now we have the outline of the functions let’s try and fill them in a little. First we’ll look at the Start-RecoveryPlan function. For this we want to be able to take in the recovery plan and mode parameters and call the SRM API with that information, maybe with a bit of error checking in there as well. If we take the example from Ken’s blog and put it into our function we should get something like:

Function Start-RecoveryPlan () {
    Param(
        [Parameter (Mandatory=$true, ValueFromPipeline=$true)] $RecoveryPlan,
        [VMware.VimAutomation.Srm.Views.SrmRecoveryPlanRecoveryMode] $RecoveryMode = 'Test'
    )

    # Validate with informative error messages
    $rpinfo = $RecoveryPlan.GetInfo()

    if ($rpinfo.State -eq 'Protecting') {
        throw "This recovery plan action needs to be initiated from the other SRM instance"
    }

    $RecoveryPlan.Start($RecoveryMode)
}

The only real change we have made is to avoid tripping ourselves up by running the recovery plan from the protected site. The API expects the plan to be run from the recovery site so we add a check to ensure the recovery plan state is not in the 'Protecting' state which is the default state a plan is in when seen from the protected site API.

Given that executing a recovery plan could be a disruptive event it makes sense to prompt the user for confirmation before executing the failover. We can do this by annotating our cmdlet with SupportsShouldProcess=$True and checking the value of $pscmdlet.ShouldProcess in our function.

So for one final time let’s put it together for our Start-RecoveryPlan function:

Function Start-RecoveryPlan () {
    [cmdletbinding(SupportsShouldProcess=$True,ConfirmImpact="High")]
    Param(
        [Parameter (Mandatory=$true, ValueFromPipeline=$true)] $RecoveryPlan,
        [VMware.VimAutomation.Srm.Views.SrmRecoveryPlanRecoveryMode] $RecoveryMode = 'Test'
    )

    # Validate with informative error messages
    $rpinfo = $RecoveryPlan.GetInfo()

    # Prompt the user to confirm they want to execute the action
    if ($pscmdlet.ShouldProcess($rpinfo.Name, $RecoveryMode)) {
        if ($rpinfo.State -eq 'Protecting') {
            throw "This recovery plan action needs to be initiated from the other SRM instance"
        }

        $RecoveryPlan.Start($RecoveryMode)
    }
}

We can do similar updates for the corresponding Stop-RecoveryPlan function as well. When we put them together with some of the custom functions we have defined earlier it makes it fairly easy to put together very concise scripts like this:

# First let's connect to VC and both SRM servers
$localvc = …
$un = …
$pw = …
Connect-VIServer -Server $localvc -User $un -Password $pw
Connect-SrmServer -User $un -Password $pw -RemoteUser $un -RemotePassword $pw

#Then let's find a recovery plan and execute a failover

Get-RecoveryPlan -Name '_Manchester Site Failover' | Start-RecoveryPlan -RecoveryMode Failover

As always a picture (or in this case a video) can say a thousand words…

I’ve also shared these functions in my SRM Cmdlets github repository to make it easier to illustrate how you can develop this. As always I’ll reiterate that I am pretty new to PowerShell so if you have any feedback, especially on the scripting style say, please let me know!

One of the important benefits of the new PowerCLI release is that it exposes SRM’s public API in a relatively easy to consume manner. Having said that calling SRM API methods directly via PowerCLI is not exactly idiomatic. Here’s the example from the PowerCLI user guide on how to protect a VM.

# Connect to the vCenter Server system that the SRM server is registered with.
 Connect-VIServer -Server vc3.example.com -User 'MyAdministratorUser' -Password 'MyPassword'

 # Establish a connection to the local SRM server by providing credentials to the remote SRM site.
 $srm = Connect-SrmServer -RemoteUser 'MyRemoteUser' -RemotePassword 'MyRemotePassword'

 # List all protection groups associated with the SRM server.
 $srmApi = $srm.ExtensionData
 $protectionGroups = $srmApi.Protection.ListProtectionGroups()

 # Associate the TestVM virtual machine with the ProtGroup1 protection group and enable the protection for that virtual machine.
 $vmToAdd = Get-VM "TestVM"
 $targetProtectionGroup = $protectionGroups | where {$_.GetInfo().Name -eq "ProtGroup1" }
 $targetProtectionGroup.AssociateVms(@($vmToAdd.ExtensionData.MoRef)) # VR specific call

 # Enable protection for that virtual machine
 $protectionSpec = New-Object VMware.VimAutomation.Srm.Views.SrmProtectionGroupVmProtectionSpec
 $protectionSpec.Vm = $vmToAdd.ExtensionData.MoRef
 $protectTask = $targetProtectionGroup.ProtectVms($protectionSpec)
 while(-not $protectTask.IsComplete()) { sleep -Seconds 1 }

While the code is reasonably straightforward to follow along it doesn’t follow the PowerShell style and we can certainly try and simplify it.

What I am going to show is how you can create custom functions that make it easier to hide this complexity when you are trying to get stuff done. For example how about we replace all that API wrangling with a couple of custom functions? Something like this perhaps:

# Connect to the vCenter Server system that the SRM server is registered with.
 Connect-VIServer -Server vc3.example.com -User 'MyAdministratorUser' -Password 'MyPassword'

 # Establish a connection to the local SRM server by providing credentials to the remote SRM site.
 Connect-SrmServer -RemoteUser 'MyRemoteUser' -RemotePassword 'MyRemotePassword'

 # Find the protection group
 $pg = Get-ProtectionGroup -Name 'ProtGroup1'

 # Protect the Virtual Machine
 Get-VM -Name 'TestVM' | Protect-VM -ProtectionGroup $pg

In this example we’ve reduced 11 lines of API heavy code into 4 fairly simple lines by creating a couple of custom functions Get-ProtectionGroup and Protect-VM. These custom functions enable us to hide the complexity of calling the API directly. Here’s a quick video demonstrating this in action.

But we don’t have to stop there! SRM’s API exposes a lot of operations so there is plenty to automate. Let’s say you wanted a list of Virtual Machines that are included in a recovery plan, with custom functions this could be as easy as chaining together cmdlets to retrieve the recovery plan, find any associated protection groups and then the retrieve the VMs associated with those groups, e.g.:

Get-RecoveryPlan -Name 'Failover Site A' | Get-ProtectionGroup | Get-ProtectedVm

…much simpler than having to call into the SRM API directly!

I’ve got very limited experience with PowerCLI but it wasn’t too difficult for me to knock up a few PowerCLI functions to do this. I’ve shared my SRM custom functions on Github (for illustrative purposes) and it has certainly proven useful for me. Hopefully there are some PowerCLI gurus out there and the community who can fix all the obvious mistakes I’ve no doubt made and share something better with the community!

Please share your feedback and let me know what kind of SRM operations you’d like to be able to automate and why.

One of the things I really enjoy about being a Product Manager for VMware’s Site Recovery Manager is listening to people tell their stories. It’s always great to hear how customers have increased capacity to cope with disasters through the improved recovery orchestration and non-disruptive testing SRM offers them. As well as listening to customers celebrate their successes, being a Product Manager is about digging deep into the customers experience to understand the sources of any frustrations and identify areas where we can further improve.

One area I know that is of interest to SRM customers is increasing the automation around SRM itself. For example: being able to query SRM to see what is being protected (and what isn’t); kicking off recovery plan tests; and automatically protecting virtual machines with SRM during provisioning. Knowing this I was really pleased to hear that the PowerCLI team were working on some SRM cmdlets and, with PowerCLI 5.5 R2, that team has delivered!

My colleague Ken Werneburg wrote up a good overview of the cmdlets with some useful links and during the recent #vBrownBag Alan Renouf gave a great intro as well as a live demo (see video below).