VMware Cloud Community
Ciparelli
Contributor
Contributor

SRM 5.0 with VNX SRA Pre-Synchronise stays at 90%

When i try to run a test with the SRM, the Synchronise stays at 90%.

When i tay to run a recover with SRM, the Pre-Synchronise stays at 90%.

If i run the test without Synchronise, it works OK.

There is no error, and it could be running for 24 hs without progress.

The only rear message are:

[01676 info 'LocalVC' connID=vc-user-a178 opID=3950c2b7] [PCM] Received NULL results from PropertyCollector::WaitForUpdatesEx due to timeout of 900 seconds
[01408 info 'LocalVC' connID=vc-user-afd9 opID=46b6235c] [PCM] Received NULL results from PropertyCollector::WaitForUpdatesEx due to timeout of 900 seconds
[01416 info 'RemoteDR' connID=dr-user-e7c2 opID=6c76dbce] [PCM] Received NULL results from PropertyCollector::WaitForUpdatesEx due to timeout of 900 seconds
[01676 info 'RemoteVC' connID=vc-user-bfb6 opID=12056074] [PCM] Received NULL results from PropertyCollector::WaitForUpdatesEx due to timeout of 900 seconds

vCenter: vCenter 5.0. U1 - 623373

SRM: SRM 5.0.1

Storage: VNX5300

SRA: EMC VNX SRA for VMware vCenter SRM 5 (v 5.0.1) with Navisphere CLI 7.31.33 and EMC MirrorView Enabler for VNX SRA 5.0.23

Thanks,

Reply
0 Kudos
5 Replies
gh0stwalker
Enthusiast
Enthusiast

I've got the same issue except I'm trying a re-replication (mirroring is reverse of normal operation).

Have you checked that the VNX mirror is working OK? I suspect that this is my problem.

Reply
0 Kudos
kastlr
Expert
Expert

Hi Ciparelli,

welcome to the community.

I assume you do mean the "Replicate Recent Changes to recovery site" option which could be selected for tests and recovery operations.

If so, this isn't related to any communication with the vendor SRA.

In fact, that option is a VMware SRM task only, when selected no activity is initiated by the vendor SRA's.

With MirrorView/S it's save to run the test/recovery without selecting that option.

For SRM tests, the first time the MirrorView SRA's are used is during Step 4 "Create writable storage snapshot"

For SRM recovery, the MirrorView SRA's are used in Step 6 and 8.

HtH,

Ralf


Hope this helps a bit.
Greetings from Germany. (CEST)
Reply
0 Kudos
Ciparelli
Contributor
Contributor

Hi Ralf,

Thank you for your answer.

When i select the option "Replicate Recent Changes to recovery site" like you said, the replication stays at 90%, but when i don´t select that option, the test works OK. I attached some pictures.

In VMware they said it could be some problem with the understanding between the storage and the SRM. That SRM could not undestand when the end of the sync is. The LUN is of 100 GBs, and there are only 20 GBs used. The replication stays in that point up to 17 hs, so i think it isn´t a matter of time.

When i use the "Replicate Recent Changes to recovery site" option in the test, it stays at 90% in the first step.

When i make a recovery, it stays at 90% in the fist step to (Pre-Synchronise).

Reply
0 Kudos
Ciparelli
Contributor
Contributor

Hi gh0stwalker,

It seems the problem could be with something about the replication.

VMware said that the problem could be with the understanding between the SRM and the Storage, that SRM doesn´t understand when the end of the sync is.

We are working around that posibility.

Thank you for your answer.

Reply
0 Kudos
kastlr
Expert
Expert

Hi,

to be honest, I wouldn't trust VMware's statement on this problem.

I assume you're using MV/S, then there's no need to initiate a "sync" operation because the remote array is already in "sync".

As I said, this option isn't needed when using MV/S.

The following snippet is taken from the SRDF documentation, didn't find a similar statement in the VNX documentation.

SRM.jpg

I did run into a similar issue month ago in an EMC Symmetrix environment, when I remember right deinstalling and re-installing the SRA did solves that problem, but I might be wrong.

But in that early phase of the SRM activities NO commands are send to the MV SRA!

Regards,

Ralf


Hope this helps a bit.
Greetings from Germany. (CEST)
Reply
0 Kudos