VMware Cloud Community
vmwaredownload
Enthusiast
Enthusiast

SOAP APIs of SRM 5.8 or 6.0 do not work when query the protected virtual machines in test failover case.

Hi,

I am developing a vSphere Web Client plug-in to talk with SRM (VMware vCenter Site Recovery Manager) 5.8 or 6.0 via its SOAP APIs.

One typical user case is that when end user selects a virtual machine under one vCenter, our plug-in will check the corresponding SRM server and list all Protection Groups for user which are protecting the selected virtual machine.

[Environment]

Protected Site: 10.102.7.78

                Protection Group: srm-protection-group-7484 (PG-VSI), type=san, state=READY

                Protected VM: vm-162 (Yuli_CRR_5.8_CG1_OS) / protected-vm-7543

         Protected VM’s datastore: datastore-161 (snap-5824c9ba-Yuli_CRR_5.8_CG1)           

Recovery Site: 10.102.7.79

                Protection Group: srm-protection-group-7389 (PG-VSI), type=san, state=TESTING

                Recovered VM: vm-221 (Yuli_CRR_5.8_CG1_OS) / protected-vm-7426

         Recovered VM’s datastore: datastore-222 (snap-7a7588ae-Yuli_CRR_5.8_CG1)

                Recover Plan: srm-recovery-plan-7500 (RP-VSI)

[Issue]

The issue I encountered is that for a virtual machine (e.g. id is vm-162, name is Yuli_CRR_5.8_CG1_OS) under the protected-site vCenter, our plug-in can find the protection group (e.g. id is srm-protection-group-7484) on the protected-site SRM server if the virtual machine is protected by this protection group. But after doing test fail-over, for the corresponding virtual machine (e.g. id is vm-221, name is Yuli_CRR_5.8_CG1_OS) under the recovery-site vCenter, our plug-in can not find the protection group on the recovery-site SRM server.

Actually, on recovery site, the protection group does exist (e.g. id is srm-protection-group-7389), but the id of its protected virtual machine is vm-162 (instead of vm-221). So vm-221 cannot be found in all protection groups and hence no protection groups will be listed for end user.

[Question]

1. In test fail-over case, why the id of protected virtual machine by protection group srm-protection-group-7389 is vm-162, rather than vm-221? This makes our plug-in not working.

2. Are there any ways to allow our plug-in to know vm-221 does be protected by srm-protection-group-7389? If there are no reasonable approaches, our plug-in will be blocked by this kind of issue.

[More Info]

More details info (e.g. environment, sample code, logs), please check the attached doc.

Thanks in advance,

Eric

0 Kudos
5 Replies
basher
VMware Employee
VMware Employee

Hello,

SRM has notion of protection associated with direction. In this case protection goes from 10.102.7.78 vCenter to 10.102.7.79 vCenter. The direction of protection does not change until the "Reprotect" operation is executed. What does this mean to you.

SRM considers vm-162 the original production VM that needs to be protected. When you execute test, a copy of that VM is being created, but the entity that SRM needs to protect remains vm-162. The protection group remains "rooted" in protected site vCenter (10.102.7.78) and therefore you cannot find this VM (as protected) on the recovery site.

So to both of your questions: during test SRM still considers vm-162 to be the "protected" VM and will always return at the protected site. Once you execute Failover+Reprotect you can expect to see vm-221 as protected VM.

Hope this helps you.

Best regards

Stefan Tsonev

Director - VMware Site Recovery Manager
0 Kudos
Chengzi
Contributor
Contributor

Hi Stefan,

I came from same team with the author of his post. Thanks for your answer. one background info is that above plugin leverages SRM SDK to query SRM info.

When using SRM SDK 5.5, the protected VM would be switched to vm-221 even after only taking 'test failover' operation on the protection group.

So could we say it's a SDK changed behavior in latest SRM version (5.8 and 6.0) so that we only can see vm-162, which is VM ID at primary site, associated with protection group at recovery site after taking 'test failover' operation ?

0 Kudos
vmwaredownload
Enthusiast
Enthusiast

Hi Stefan,

Thanks for your explanation.

Based on Chengzi's reply and question, I would like to introduce more backgrounds.

The plug-in can be used on either protected site or recovery site. For our customer, they'd prefer to use it on recover-site vCenter and SRM, instead of protected-site ones, to minimize the exposure of production environment.

Actually there was a legacy vSphere client plug-in (desktop, C#) which applied the same SRM API calling with SRM 5.5 and worked well in test failover case, that means vm-221 was returned when querying protected vm on protection group of recovery site. This allows our customer to check the status of protection group via selecting vm on recover-site vCenter.

Now I am migrating the desktop plug-in to vSphere Web Client plug-in (web, JAVA). The new version is targeting to talk with SRM 5.8 & 6.0. But the same SRM API calling does not work now, as described in the original post above.

So one question is following Chengzi's, why does this kind of SDK/API behavior changes happen between SRM 5.5 vs SRM 5.8 & 6.0?

Another question is that: to keep user experience consistent (could check status via recover site in test failover case), in this situation of SRM 5.8 & 6.0, are there any alternatives/workarounds for our plug-in to recognize vm-221 which is protected by protection group of recovery site?

0 Kudos
admin
Immortal
Immortal

To add to Stefan's post I would also note that you can get the different identifiers of the VM at the source and destination sites via the API so you can correlate them together.

If you look at the definition of the ListProtectedVms [1] method you will see the following:

  • protectedVm[] – array of SrmProtectionGroupProtectedVm data objects with the following fields:
    • faults – any faults associated with this protected virtual machine
    • needsConfiguration – the protected virtual machine needs to be configured or repaired
    • peerProtectedVm – the protected virtual machine identifier on the remote site
    • peerState – the protection state on the remote site
    • protectedVm – the protected virtual machine identifier on the local site
    • state – the protection state of this particular virtual machine
    • vm – the locally protected virtual machine (this reference is valid after reprotect or revert operations)

As you can each protected VM has two identifiers, the identity of the VM at the protected site and the identity at the recovery site. These are different as each VM identifier is scoped to the VC where it is located, a VM identifier like VM-162 on vCenter A could refer to a completely different VM on vCenter B. You have to use the protectedVm and peerProtectedVm fields within their relevant site.

[1] Page 29 & 30 of https://www.vmware.com/support/developer/srm-api/srm_58_api.pdf

0 Kudos
vmwaredownload
Enthusiast
Enthusiast

Hi Ben,

Thanks for your insights on the details of protected VM. I have noticed the fields protectedVm and peerProtectedVm before, but still cannot recognize the vCenter vm instance with these vm identifiers.

Using my example in original post, when query protected vm from the protection group (srm-protection-group-7389) on recovery site, the returned vm info is listed below:

  • protectedVm
    • faults – ...
    • needsConfiguration – ...
    • peerProtectedVmprotected-vm-7543
    • peerState – READY
    • protectedVmprotected-vm-7426
    • state – TESTING
    • vm – VirtualMachine / vm-162



The field vm is referring to the vCenter vm (vm-162) on protected site. So our plug-in does not know the vCenter vm (vm-221) on recovery site is protected by srm-protection-group-7389.

As for the fields protectedVm and peerProtectedVm, with these identifiers (protected-vm-7426, protected-vm-7543), how to know there is a relationship between vm-221 and srm-protection-group-7389 ?

By comparing, with SRM 5.5, the field vm was referring the vCenter vm (vm-221) on recovery site and it is straightforward for our plug-in to know that vm-221 is protected by srm-protection-group-7389.

0 Kudos