Reporting on Site Recovery Manager Failover via PowerCLI

Here’s another fun one! So we’ve automated some Site Recovery Manager failovers with PowerCLI. Say we run a weekly test for a given recovery plan. But now we want to know how it worked. Maybe generate a table report, maybe email it out, whatever. Take a look at the following: I’m assuming you’ve already done […]]> Here’s another fun one!

So we’ve automated some Site Recovery Manager failovers with PowerCLI. Say we run a weekly test for a given recovery plan. But now we want to know how it worked. Maybe generate a table report, maybe email it out, whatever.

Take a look at the following:

I’m assuming you’ve already done the Connect-VIServer and $SrmConnection to the appropriate systems. What next? Well as before the $SrmAPI mapping again gives us an entry point to the actual SRM API itself.

$PlanMoref = $SrmApi.Recovery.Listplans()[1].moref 

This is in essence retrieving the managed object reference ID for the recovery plan returned by “Listplans”. You will need to know which recovery plan you want to report on, but that is easily determined by running the Listplans method without any reference, i.e. simply running:

$SrmApi.Recovery.Listplans

Once you know that you know which plan you want to run the report on and you know whether to pass a [0] or a [1] or whatever to the $PlanMoref variable you are creating.

Once that is done we want to pull out the managed object reference to the *history* of the recovery plan execution. So we execute the GetHistory method against the $PlanMoref variable we have created, and assign it to the new variable $HistoryMoref .

$HistoryMoref = $SrmApi.Recovery.GetHistory($PlanMoref)

This then attaches us to the history of the particular recovery plan we want, and gives us a nice variable name to use for the next step:

$HistoryMoRef.GetRecoveryResult(1)

This, now, is the heart of the matter. It is retrieving the data from the latest run of the recovery plan we attached to earlier. The “1″ listed here indicates the most recent execution of the recovery plan. If we indicated “2″ it would not retrieve the second most recent, but the last *two* executions, and so forth. So to retrieve the details of the last run of our recovery plan, we need to know: a) The plan as listed by ListPlans , b) the Moref of the plan as listed by Listplans()[planid].moref , c) to attach to the history using the plan’s GetHistory($PlanMoref) , and that we d) access the output by running GetRecoveryResult against all the prior input.

Make sense? Fundamentally it can be reduced to the 4 or fewer lines, as per my example at the top. What you do *with* that output is up to you! If you check out the sample scripts for generating reports against the SRM API, or really reference any PowerCLI materials you’ll doubtless come up with some great ideas for generating tables, reports, emails, whatever is appropriate.

One last thing though – we’ve generated a test run automatically, and now run a report against the result. What’s next? Run a cleanup, as per my previous blog about automating execution.

via VMware Blogs http://bit.ly/1o9RokJ