The Lazy Admin’s Guide to Site Recovery Manager and PowerCLI

Most administrators know that PowerCLI is intuitive and easy to use in most cases, and we’ve covered a great deal of topics on the Altaro VM Blog when it comes to PowerCLI. However, we’ve only covered the traditional vSphere datacenter operations and some of the newer Infrastructure as Code capabilities that exist on the market today. There are many other modules for VMware Products like Horizon View, NSX, vROPS and Site Recovery Manager (SRM) as well. I figured we could cover SRM in today’s post. Site Recovery Manager is VMware’s offering for disaster recovery orchestration. SRM is like the brain while the muscles are vSphere Replication and Array-based replication.

First a question, why/when would you use Site Recovery Manager? It really comes down to a few points.

1. You would use SRM if you need basic replication capabilities
2. Your backup/DR provider has no replication capabilities in box such as Altaro’s WAN Optimized Replication

To many, it makes sense to have the backup/DR provider software take care of the replication and DR, but if your provider lacks those capabilities or you want to de-couple DR from the backup/recovery process for some reason SRM may be an option.

As you can see in the image below SRM is designed to replicate VMs from one site to another

While there is an HTML5 management UI you can use to manage the solution, what if you managed the solution with PowerCLI? What if you wanted to be LAZY and automate everything? I chose to cover this module in particular because it differs from the core ones as it only provides cmdlets to connect and disconnect SRM servers. After that everything is done via the exposed API with PowerShell methods and properties. It is a more complicated approach but remains a great exercise to improve your skills and understanding of PowerCLI, and once you’ve learned it, you can take the Lazy-Admin approach and use your automation skills to do the work for you!

Let’s start with some resources and documentation!

NOTE: If you need more preliminary info on PowerCLI in general, we have a great eBook on the topic here.

SRM Help and Documentation

API developer’s guide

You can find the official documentation about the SRM SDK in the API developer’s guide for SRM which I recommend you save somewhere if you plan on working with SRM in PowerCLI. It is a great source of information as it presents the data structure clearly with extended information about each object and what can be done with it.

For some reason, when I checked at the time of this writing VMware seems to have locked down access to some of the documentation so you might need to request access to it.

Community sample code

Because this module is harder to use due to the fact that everything is done with the API, VMware offers the possibility to download community-made SRM cmdlets. This allows people to download cmdlets to get started without having to go down the SRM module rabbit-hole of writing your own functions for everything. You will find the cmdlets and documentation here.

While this is a great addition to those who don’t want to bother with it, we are here to learn how SRM works with PowerCLI! So, let’s get to it!

Connecting to Site Recovery Manager with PowerCLI

Permissions

Unless the user has the role ‘Administrator’ applied, the account you will use to connect to SRM needs to have the Administration > Access Control > Global Permissions rights on both vCenter servers. If you want to be more restrictive or if you want a dedicated user for this purpose, you can assign one of the built-in SRM roles.

Connection

Since SRM 6.0, the platform service controller (PSC) and vCenter servers are associated with the local and remote SRM instances. Meaning you can easily connect to SRM if your session is connected to vCenter without having to specify its address or name. Note that we are describing the most common way to connect to SRM, but your mileage may vary according to your environment and needs. I’ve also included a home-made PowerShell function below that will help with SRM connection as well.

Standard method

• Connect to the vCenter server in the protected site (makes for better scripts opportunities).
• Store your SRM credentials in a variable for faster connection.

$Creds = Get-Credential

• Connect to the protected and remote SRM instances. You need to specify credentials (as shown above) as it doesn’t pick up your session credentials

Home-made function

Below is a small function that makes connecting to SRM slightly quicker and easier. You only have one set of credentials to specify and the user field is already populated with your current session username. You can already have a taste of how the SRM module works by looking at how the remote site is connected using the LoginRemoteSite method of the extensiondata property.

Function Connect-SRMPair {
param(
     [PSCredential]$Credentials = (Get-Credential $env:username)
)
Write-host "Connecting to local SRM server.." -ForegroundColor DarkCyan
if (Connect-SrmServer -Credential $Credentials) {
    Write-host "Connecting to remote SRM server.." -ForegroundColor DarkCyan
    $DefaultSrmServers.extensiondata.LoginRemoteSite($Credentials.username,$Credentials.GetNetworkCredential().password,$null)
}
}

$DefaultSrmServers

Just like when you connect to vCenter, once you established a connection with your SRM instance, a new global variable called $Global:DefaultSrmServers is created and is the starting point for interacting with SRM. All the properties, sub-properties, and methods associated with SRM are stored in the extensiondata property of the $DefaultSrmServers variable. Let’s run a Get-Member command on it to see what’s in it:

$DefaultSrmServers.extensiondata | Get-Member

Notice that the property is of type SrmServiceInstance and contains a number of properties and methods that we will describe to make it easier to understand.

Properties

You can maybe already tell where this is going by looking at the last three properties of the Get-Member screenshot:

• Protection: Management of everything related to the protection groups, VMs, datastores…
• Recovery: Management of everything related to recovery plans.
• Storage: Reserved to run devices discovery in Array-Based Replication (ABR) environments.

Those are really the three properties in the $DefaultSrmServers variable. The properties of virtual machines, protection groups, etc will come as output of the various methods.

Below is an extract of the API developer’s guide we mentioned earlier that shows a tree view of the SRM methods where you find the same three properties pointing to all the methods they offer. For instance, if you run the DiscoverDevice method on the SrmStorage object, you will get a DiscoverDevicesTask object on which you can run the GetDiscoverDevicesTaskFailures and the IsDiscoverDevicesTaskComplete methods.

How to use SRM with PowerCLI

Now that we know more about the structure of the SRM module, we can start working with it and retrieve information about the environment. We will use a fairly easy example to demonstrate how it works and we will do it step by step. The objective is to return the VM objects protected by a specific protection group.

You can then explore the module according to your operational needs.

1 – List all protection groups

You can quickly find in the chart where you have to go to list the protection groups. You can confirm this by running Get-Member (alias gm) on $DefaultSrmServers.extensiondata.Protection to inspect it.

If you look at the definition field of the Get-Member output you will see that no argument is needed, which is usually the case with List commands.

• Let’s run that command to see what we get. We start by storing the output in a variable so we can easily work with it later.

$PG = $DefaultSrmServers.extensiondata.Protection.ListProtectionGroups()

As you can see at first glance we only get the MoRef IDs of the protection groups.

• Explore the first protection group with Get-Member.

NOTE: When exploring in PowerShell or testing in general, I usually do it on one object to start with and then move on to the whole list.

$PG[0] | Get-Member

Just like the chart showed us earlier, we find here a number of methods that offer to retrieve information about the protection group. In this example, we want to display the name of the protection group.

• Invoke the method GetInfo on the protection group object.

$PG[0].GetInfo()

Type “san” stands for Array-based replication (ABR).

• Run the method on all protection groups.

$PG.GetInfo()

We can now list our protection groups which is a good start. In the next step, we will list the VMs of a protection group based on its name.

2 – List the VMs in a protection group based on its name

In the previous example, we demonstrated how to obtain the name of a protection group. We will now use this information to filter one protection group that we want to inspect.

• Filter the protection group based on its name and store it in a variable.

Note that it supports wildcards with the -Like­ or -Match operators.

$TestPG02 = $PG | where {$_.GetInfo().name -eq "Test-PG-02"}

• Use the ListProtectedVMs method on the protection group and store it in a variable.

As specified in the API guide, the ListAssociatedVms that you see in Get-Member is only for vSphere replication, it does not apply to array-based replication (ABR).

$PG02VMs = $TestPG02.ListProtectedVms()

There is a small gotcha here. You get some interesting information about the protected VM. However, the output is slightly disappointing as SRM works with IDs so not “human understandable” data. The VM property contains a virtual machine managed object with the bare minimum in terms of properties, not even the name.

Again we are working with the first record for cleaner output.

• Convert this managed object to an inventory object (VM) by using the Get-VIObjectByVIView

$VM = Get-VIObjectByVIView $PG02VMs[0].vm

We now have a proper VM object. We can even compare the object types to see the difference

Obviously you can now run the command against all VMs in the protection group to get the VMs list.

3 – Automate the process in a function

We proved that we can obtain VM objects based on the protection group they belong to. However, it was a rather cumbersome operation that you don’t want to have to do every time. Which means it is a perfect opportunity to write a function and have a nice and parameterized cmdlet.

There is not much else to explain here as we demonstrated every command so I will just put the function below for you to inspect.

Note 1: I used the verb Get because List is not a valid verb for some reason.

Note 2: This function assumes that you have an active session with an SRM instance.

Note 3: This function only takes one protection group for the sake of the example. Working with multiple protection groups would require returning one object per protection group with their respective lists of VMs as a property of type array.

Function Get-ProtectedVMs {
param(
    [string]$ProtectionGroupName
)
# Checking if connected to an SRM instance.
if (!$DefaultSrmServers.IsConnected) {Write-Warning "Not connected to SRM instance"; break}
# Retrieving the protection group object by name.
$PG = $DefaultSrmServers.extensiondata.Protection.ListProtectionGroups() | Where {$_.GetInfo().name -eq $ProtectionGroupName}
# Retrieving the list of VMs as managed objects.
$PGVMs = $PG.ListProtectedVms()
# Converting managed objects to inventory objects and returns output.
Get-VIObjectByVIView $PGVMs.VM
}

Example output below!

Wrap-Up

Again, working with SRM in an automated fashion will allow you to use it more quickly and effectively in the future. While what we covered above was very example-driven, you can use these same steps in your own environment to begin working with SRM and PowerShell.

Also, if you’re interested in learning more about working with PowerCLI and VMware, check out our free eBook on the subject!

Read more and download the free eBook

Also if you have any questions, comments, or feedback, do let us know in the comments section below!

Thanks for reading!