I've seen a few people looking at ways to optimize their disk utilization, and a few times people have looked at putting VMs onto datastores that are replicated and have VMs protected by SRM, even if they do not want or intend to protect these new VMs.
This is a Very Bad Idea ™ for a number of reasons – first of all it will create administrative burden. You'll get alerts and warnings about unprotected VMs that you'll need to address and this may cause confusion or cause people to do… unanticipated things.
In speaking with our developers I realized a further issue above and beyond the fact that it's generically a poor idea: Beyond that, a new feature of SRM 5 is the "planned migration" workflow where data consistency is paramount. During a planned migration SRM will first power off all the VMs in a protection group, do a final synchronization of the data between the protected and recovery sites' arrays, and unmount the datastore at the primary site.
Only when this last step is successful will SRM carry on to start the recovery at the secondary site. As mentioned, the goal of planned migration is to ensure a consistent set of data, so having a quiescent and consistent datastore is paramount.
If there are unprotected VMs on the datastore that are not part of a protection group involved with the planned migration, SRM will be unable to unmount the datastore cleanly and at *best* the planned migration will fail and halt in its state until the datastore can be unmounted. This will cause serious delays with your RTO until you can clean up the datastore for a proper unmount. So yet another reason to keep your storage correctly laid-out!
