SRM Warnings appear when replication VMs are in an SDRS cluster and automated Storage vMotion fails
Article ID: 429237
Updated On:
Products
Issue/Introduction
Manual Storage vMotion may succeed but automated Storage vMotion will not proceed and instead you see the warnings below:
- WARNING: Both datastore '{srcDs}' and datastore '{dstDs}' are replicated datastores as reported by Site Recovery Manager. Migrating the VM from datastore '{srcDs}' to '{dstDs}' will result in an additional replication overhead. Do not proceed unless you want this VM to be replicated and protected later in Site Recovery Manager.
- WARNING: Migrating the VM from datastore '{srcDs}' to datastore '{dstDs}' may lead to a potential loss of the VM because these datastores are not replicated as part of the same consistency group. Do not proceed unless you are able to sync the underlying storage device for datastore '{dstDs}' manually after Storage vMotion is complete. Until this manual sync is complete, you may not be able to recovery this VM using Site Recovery Manager in case of a disaster.
Environment
vCenter 8.x
vCenter 9.x
Live Recovery 9.x
Cause
All these conditions must be true to trigger the issue
- VMs are running on storage volumes in an SDRS cluster.
- Array-based replication is in use
- SRM is protecting the VMs.
Resolution
The first warning refers to architecture wherein replication is configured 1:1 for volumes at the source and destinate site. This means that migrating the VM to a different datastore will result in a complete new copy of the VM being created on the corresponding destination datastore. vSphere will not clean-up/delete the old one and a complete new copy will create unnecessary replication traffic/overhead. This would not occur if all volumes at the source site were replicating to a single, large datastore, for example.
The second warning may occur because migrating a VM to a datastore outside its consistency group introduces unknown risks. SRM organizes replicated datastores into consistency groups depending on several factors. While this list and division cannot be manually adjusted, it can be influenced by 2 chief factors: Extents on the datastores themselves, and whether VMs have files that 'straddle' multiple datastores. This could mean that some virtual disks are replicated from one datastore to its corresponding datastore at the destination site and one or more of it's remaining disks not only reside on other volumes at the source site, but are also being replicated to datastores corresponding to those at the destination site. Combine this with a violation of what SRM has calculated as its consistency groups and the risk introduced by migrating the VM is deemed too great to proceed.
The main recommendation is to architect the replication topology to avoid the above scenarios and/or forego the use of automated Storage Migrations in SDRS where array-based replication is in play.
Additional Information
https://techdocs.broadcom.com/us/en/vmware-cis/live-recovery/live-site-recovery/9-0/how-do-i-protect-my-environment/creating-and-managing-protection-groups/about-array-based-protection-groups-and-datastore-groups/how-site-recovery-manager-computes-datastore-groups.html
Feedback
