Storage policy protection groups are subject to limitations.
Protecting Virtual Machine Templates
Datastores that are compliant with protected storage policies should not contain virtual machine templates.
Protecting Virtual Machines with RDM Disks
Datastores that are compliant with protected storage policies should not contain virtual machines with RDM disks.
Protecting Virtual Machines and Licensing Limits
- Virtual machines that are not initially protected due to licensing limits are not protected even after you modify consistency groups and virtual machines to meet the licensing limit.
- Virtual machines that are not initially protected due to licensing limits are not protected even after you install a license for a larger number of virtual machines.
Duplicate Tags in Enhanced Linked Mode Environments
In an environment that uses Enhanced Linked Mode, if a temporary network partition occurs between vCenter Server instances, it is possible to create a tag on one site and to create another tag with the same name on another site. You might then tag one set of datastores on one site with the first tag, and another set of datastores on the other site with the second, identical tag. Because Site Recovery Manager looks up tags by name rather than by ID, when the network partition is removed, the datastores on both sites appear to be tagged with the same tag. If you delete one of the duplicate tags, Site Recovery Manager might remove protection from the consistency groups that reside in the datastore that bore that tag. The virtual machines in those consistency groups lose their protection and the recovery settings for the virtual machines are deleted.
To avoid this situation, resolve tag conflicts before creating storage policy protection groups and configuring virtual machine recovery settings. If you encounter this situation after you have already created storage policy protection groups, shut down the protected site temporarily and resolve the tag conflict.
Changing Array States Between Recovery and Reprotect
After running a recovery plan but before running reprotect, if you change the state of an array device, for example to fix issues with reversal of replication, and you initiate a rescan of the storage devices, Site Recovery Manager can stop unexpectedly. If this occurs, you must recreate the corresponding protection groups and recovery plans.
Associating Nonreplicated Datastores with Storage Policies
It is possible to associate a nonreplicated datastore with a storage policy that you include in a storage policy protection group. However, Site Recovery Manager does not protect the virtual machines that reside on a nonreplicated datastore, even if that datastore is associated with a storage policy that is included in a storage policy protection group. If you run a recovery plan that includes that protection group, any virtual machines that have files on a nonreplicated datastore appear with errors in the protection group and are not recovered.
Datastores Spanning Multiple Consistency Groups
- If no other datastores backed by the consistency group are part of the storage policy, the protection group might skip the consistency group.
- The protection group might not report problems related to the datastores.
- Virtual machines using datastores that span consistency groups are in a nonprotected state even if the virtual machines use the correct storage policy.
- The datastores that span multiple consistency groups will appear to be nonreplicated and are not protected by the storage policy protection group. Those datastores might disappear when Site Recovery Manager migrates the protection group to the recovery site.
Protecting the Same Consistency Groups in Both Array-Based Replication and Storage Policy Protection Groups
If you tag a replicated datastore and associate it with a storage policy, you can include the storage policy and its associated consistency groups in a storage policy protection group. It is also possible to include a datastore group that contains the tagged datastore in an array-based replication protection group. Therefore, consistency groups can end up being included in both an array-based replication protection group and in a storage policy protection group.
When a storage policy protection group and an array-based replication protection group both attempt to protect the same consistency group, the array-based replication protection group takes the ownership of the consistency group and the virtual machines that it contains. The storage policy protection group marks the consistency group and virtual machines in an error state. In this situation, you must remove the consistency group from one of the protection groups.
- To keep the consistency group in the array-based replication protection group, disassociate the affected virtual machines from the storage policy. Also disassociate the consistency group from the storage policy. This removes them from the storage policy protection group.
- To keep the consistency group in the storage policy protection group, edit the array-based replication protection group to remove the datastore and virtual machines. This automatically resolves the error in the storage policy protection group.
Changing the Protection Status of Consistency Groups and VMs During and After a Recovery
You can change the protection status of the consistency groups and VMs that are part of a storage policy protection group by tagging and untagging the datastores, or associating and disassociating VMs with storage policies. When you change the protection status of the VMs and consistency groups and a planned migration or disaster recovery are not running, Site Recovery Manager updates the protection status of the VMs and consistency groups in the SPPG.
If you change the protection status of the VMs and consistency groups during a planned migration or disaster recovery that uses the storage policy protection group, the Site Recovery Manager user interface might show changes on the protection site, but the recovery workflow cannot be updated properly, and the recovery might fail.
To ensure a successful recovery process, you must not change the protection status of the VMs and consistency groups in an SPPG during a planned migration or disaster recovery of the SPPG. More precisely, the window when protection changes are not supported starts from the first time a recovery plan containing the SPPG enters Recovery In Progress state, until the same plan reaches Recovery Complete state.
You cannot add consistency groups or virtual machines to a storage policy protection group if you have successfully or unsuccessfully run a recovery plan that contains that protection group. Do not add new consistency groups or virtual machines to a storage policy protection group in the Recovered or Partially Recovered states. You can add new consistency groups or virtual machines to an existing storage policy protection group that has never been included in a recovery plan run, or that has only been included in test recoveries.
When you have run a recovery plan that contains a storage policy protection group, you must include any new consistency groups or virtual machines in a new storage policy protection group. Remove new consistency groups or virtual machines from the recovered storage policy protection group before you add them to a new storage policy protection group. Site Recovery Manager only supports the protection of an object in a single protection group.
Requirements for Resource Inventory Mappings
Storage policy protection groups have specific requirements and limitations on how to set the resource inventory mappings. For more information, see Inventory Mappings for Storage Policy Protection Groups.
