Using PowerCLI with Site Recovery Manager Shared Recovery Site

The release of the PowerCLI SRM cmdlets have enabled the admin to automate reporting and protection tasks without having to use .NET or java.

Ben Meadowcroft (former PM for SRM) has a github site where he created a lot of functions using PowerCLI, these are very handy to start your SRM automation journey.

One thing that I found while modifying Ben’s scripts was that there were some functions that did not work well in a Shared Recovery Site configuration. To setup a Shared Recovery Site, typically a second pair of SRM servers are installed using the CUSTOM_SETUP=1 option and then a non-default SRM ID is chosen.

The issue I was having is similar to this one in the forums.

First, you cannot use connect-srmserver without specifying which srmserver to connect to.

Second,  SRM is not able to figure out what vCenter it should be talking to because the default SRM ID is not being used.

The listprotectedvms() SRM API function (used on a protection group) returns protectedvms but when you try to do a updateviewdata() in order to get the extended data, that is when SRM gets confused.

This is a protectedvm that is returned from listprotectedvms():

Vm : VMware.Vim.VirtualMachine
ProtectedVm : protected-vm-34415
PeerProtectedVm : protected-vm-34265
State : Ready
PeerState : Shadowing
NeedsConfiguration : False
Faults :
DynamicType :
DynamicProperty :

This is the Vm object (VMware.Vim.VirtualMachine):

Capability :
Config :
Layout :
LayoutEx :
Storage :
EnvironmentBrowser :
ResourcePool :
ParentVApp :
ResourceConfig :
Runtime :
Guest :
Summary :
Datastore :
Network :
Snapshot :
RootSnapshot :
GuestHeartbeatStatus : gray
LinkedView :
Parent :
CustomValue :
OverallStatus : gray
ConfigStatus : gray
ConfigIssue :
EffectiveRole :
Permission :
Name :
DisabledMethod :
RecentTask :
DeclaredAlarmState :
TriggeredAlarmState :
AlarmActionsEnabled : False
Tag :
Value :
AvailableField :
MoRef : VirtualMachine-vm-772
Client : VMware.VimAutomation.Srm.Views.Utils.VimClientDelayedResolveProxy

Typically, you would do an updateviewdata on the vm property (example protectedvm.vm.updateviewdata()) to update this view data for further processing, reports, etc.

At first I thought that this was a big issue, but I realized that the MoRef property of the protectedvm is the MoRef to the VM itself and can be used as part of get-view.

Ex:

 

The same thing can be done if you are using the listprotecteddatastores(), just note that the protecteddatastore return the ‘view’ object directly and not as a property, so you would have to return the get-view itself

I still have to validate all of my functions, but I am glad that I was able to get past this hurdle (even though it took me a year!).