Using PowerCLI to Change SRM Recovery Settings

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

Site Recovery Manager (SRM) 5.8 is Available!

I am pleased to say that Site Recovery Manager 5.8 is now available!

This was a really exciting release to be working on as there are a ton of new features, including (but not limited to):

  • Integration into the vSphere Web Client
  • Protect up to 5,000 VMs and concurrently recover 2,000 VMs (compared to limits of 1,000 VMs at GA of SRM 5.5) [KB 2081158]
  • New integration options using vCenter Orchestrator plug-in for Site Recovery Manager enabling new capabilities including:
    • Provision VMs with vCloud Automation Center and DR protect automatically with SRM
    • Create SRM protection groups
    • Create inventory mappings
    • and more!
  • Dramatically simpler IP customization at scale with subnet-level IP customization rules
  • Performance improvements to storage failover operations, up to 75% faster in larger environments
  • Streamlined deployment using new support for vPostgreSQL that provides optional embedded database option during SRM installation.
  • Improved support for Integrated Windows Authentication when using remote Microsoft SQL Server instances as the Site Recovery Manager database
  • Compatibility with vSphere Storage I/O Control

As you can see from the list of changes there has been a lot of hard work put into this release by many people!

If you are wondering SRM 5.8 supports the same set of SRAs as SRM 5.5 so no need to wait for an update from your storage vendor. Check out the drivers and tools tabs for the SRAs and the vCenter Orchestrator plugin.

VMworld 2014

Well VMworld 2014 has arrived. There were some really interesting announcements (looking forward to the demo for Project Fargo). This is my third VMworld and as usual it will be filled with customer and partner meetings as well as whatever sessions I can squeeze in. I know I could always catch the session recordings after the conference but I do like the live participation.

This year I will also be presenting on Site Recovery Manager and vCloud Automation Center integration. My sessions on Tuesday and Thursday (register online or see tweets about the session #BCO1893) and there’s currently over 800 people registered to attend so I expect it will be fairly busy.

Building More PowerCLI Custom Functions for SRM, Step by Step Walkthrough

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!

Design Crazy?

One of the perks of traveling for business is the time I get to catch up on some reading while flying between locations. Last week I had the chance to travel to Missouri to visit some customers and was able to reread a couple of books I’ve found interesting. The one I want to write about now is an interesting look at Apple’s approach to selecting, designing, and bringing products to market. The book, Design Crazy, is very short and a quick read, it is really a large collection of quotes from people involved in the work arranged around certain themes and events.

Here are a few of the items I highlighted while reading:

“The competitors, like Commodore and Kaypro, were all doing speeds and feeds, whereas Steve always wanted things like “What is the significance in the world? How might this change things?” – Steve Hayden

 

“He was thinking about the problem very holistically, saying, “Can we unify this experience?” – Don Lindsay

 

“The challenge in delivering simplicity is, marketing wants to bring more functionality to bear, engineering wants to bring more options to bear—and all of that just adds to confusion and clutter.” – Don Lindsay

 

“Jony’s funny. He’s an artist, which made him very different from the engineers. We would have arguments about stuff, but the best products come when there’s creative tension.” – Jon Rubinstein

 

“The compromises Apple took on design were legendary: you didn’t have copy/paste, you didn’t have multi-tasking, you didn’t have apps. Apple said, “We just want to have a cool phone.” They focused on making people love the product. And that’s the distinction at the end of the day. Everybody else was focusing on being smart. Apple focused on being loved.” – Horace Dediu

 

“There had always been products that had been beautifully designed. But they were high-end, and very few people actually owned them. Apple was the first company that took high design and made it mainstream. It taught the world taste.” – Phil Libin

The author, Max Chafkin, uses selection and organization of the quotes to share the story rather than trying to clumsily imposing a more explicit narrative on top.