know that Flexclone is required to DRP test with VMware SRM but is it possible with VMware SRM to test the practice without FlexClone via the use of scripts launched by SRM (SnapMirror break, VMs 's snapshots becoming accessible in read/write, inventories VMs ,...) ?
SRM testing is designed in this way that it does not touch SnapMirror relationship at all - hence the need for FlexClone licnense to create writeable clones off target SnapMirror volumes, spinning off "dummy" VMs, etc. All that a) does not impact your primary site, b) does not break / quiesce remote replication whilst testing.
Whether you can accomplish this without FlexClone license is a subject to discussion. Almost certainly depending on the size of your environment & extensiveness of testing you can do something, but surely it will be far more complex than just pressing a test button within SRM GUI (e.g. you may think about doing LUN clonning or simply doing a full copy of some VMs for testing, etc.)
What you can always do with or without FlexClone is an actual SRM fail-over - this will break SnapMirror, shut down your primary VMs and bring up DR replicas in a full read-write mode. This however is in my opinion "THE fail-over" vs. "fail-over testing" & implications in a production environment are quite substantial (some downtime, no protection whilst testing, all clients need to have access to the DR site to work & manual fail-back). [edit: the last bit is not strictly true as I just found out - TR-3671 describes the steps to do a "reverse fail-over" by reversing SnapMirror & SRM relationships]
I'm not mixing up two things (I know that FlexClone prevent to break the snapmirror replication) : my question only concern the possibilites for testing without FlexClone.
Indeed, may be we can do this with "fail-over testing", if it possible in failover scenario to not automatically shutdown primary VMs and map them to a bubble network (never mind for the snapmirror replication) ?
1) Within SRM plan you have to explicitly request shutting down primary VM, so if you don't do that they will just stay up.
2) You can set different IP addresses for VMs when they get failed-over - typically you do that if you have different subnet at DR (often the case), but this can be also used for pointing VMs to an isolated network.