SRM Test snapshot VMs disappears

Hi Firoz,

When you run a test recovery from SRM, the image access mode it uses is Logged Image Access and the journal history is maintained. However, when you run an actual failover from SRM it uses Direct Image Access mode and the journal history is lost. This behaviour is by spec and also occurs when you move to Direct Image Access directly from RP.

Regards,

Rich

thanks forshr for the reply. I understand this concept but when we do a test SRM snapshot i do have an option to change the logged access to direct access and this works with the same fundamentals as it erases the history. With enabling direct access it no longer requires journal space and while finishing the test it also gives an option to undo all the writes.

But my question is still unanswered and the VMs just disappears the movement i enable direct access.

regards

Firoz

This is by spec also. You need to perform an SRM clean-up after the test recovery.

Hi

3 days. The VM hosts SQL DB on it and I am expecting high writes during this tests. 20% space which gets allocated from the journal gets 100% full within a day and the only way I can get away with this is by enabling direct access on the SRM snapshot created and continue with the test for multiple days without the fear of log space getting full. And at the end of the testing I can clean up. We are not doing failover, its the test snapshot I am talking about.

You think by enabling direct access the test snapshot should disappear? I don't think so because we were able to do multiple tests in the pasts with direct access being enable and for many days.

thanks forshr.

I understand that i can incre the proportion of image access log >20% but i dont want to do that for 2 reasons. (1) EMC as per there guidelines do not recommend. (2) If I happen to do test SRM snap for larger volume which may include multiple applications some heavy IOs some less and if I want to run the snapshot for 2-3 days which usually is in our environment, then how am i supposed to cope up with that.

I am trying to get away with the work around of manually increasing the image access log. Not sure if my understanding about enabling direct access is correct when i want to use it on an SRM test snapshot but if enabling direct access is not the right method then what else have I got incase my customer wants to do testing for multiple days on test snapshot.

Hi Firoz,

One of the side effects of enabling direct image access is the loss of history from the journal including the SRM generated bookmark post disabling image access.

You could revert back to using logged image access and increase the size of your copy journal to proportionately increase the size of the image access log and/or increase the image access log %. Note that increasing the proportion of image access log (> 20%) requires the copy to be disabled.

Regards,

Rich

The side-effect of initiating direct image access is 1) loss of PiT history from the journal as I've already stated, 2) replication is paused and marking is initiated at the source copy journal.

The alternative to this is to use logged image access and perform the changes I have suggested which many other customers have done, which is to increase the size of the journal and if necessary also increase the size of the image access log area. The 'do not recommend' guideline I am not familiar with, but I suspect this relates to the proportionate reduction in PiT rollback history which can be counteracted by increasingly the journal size.

thanks Forshr

I wouldnt care about the effects of initiating direct image access but is that an option?? I mean i can't figure out why do I have an option of enable direct access when SRM Test snapshot is successfully initiated and i can see it as an hyperlink on unisphere. As per EMC documentation, enabling direct access is to by pass all the writes from image access logs directly to the DR lun which allows testing for a longer duration with an option to undo all the writes when i want to clean the testing.

by the meantime do you have any document which gives step by step information on how I can increase the image access log size?

thanks and appreciate your quick response

You would have to take the CG(s) being protected by SRM in the PG(s) out of SRM external management control using the UI, CLI or REST API commands, change the CG(s) from logged image access mode to direct image access mode and then put the CG(s) back under SRM external management.

GUI

Exactly...this is what I do when my test SRM snapshot is successful but here the problem starts. after i enable the direct access while the snapshot being live on the host and during the process of giving the control back to SRM the VMs disappear and when I look at Manage recovery tab theres nothing listed.

Is this a problem or is this how it is supposed to react? I mean if it is supposed to react this way then what for do we have the enable direct access option?

How are to enabling direct image access mode? Are you using the UI to move from logged to direct image access mode or the CLI?

OK, so from the GUI you enable direct access from the recovery activity window by continuing the test.

If this is the case then the behaviour you are experiencing should not occur. I would recommend that you raise an SR and stipulate all off the related software versions as this could be an SRA related issue.

Have there been any RP or VMware software upgrades/changes in between the last successful test and this recent test?

finally....I am getting to hear what I wanted to. Yes I am facing this problem. I have checked all the compatibility from RPA firmware to SAN switch/storage firmware/SRA/VMware/HBA drivers and all seems compatible.

I see the VMs disappearing the moment I enable direct access from the recovery activity window by continuing test.

I had done this test 2 times in the past last year with no issues but recently we had face this trouble and couple of times. so its very very strange.

I have simulated this test yesterday to capture RP and SRM logs and got SR raised.

I will share the findings.