It is recommended to prepare for failover by configuring the servers in the DR site before failing over. Since the DR Pod will be in a demoted state, the Pure Volumes will be read-only. This will allow devices and paths to be discovered and configured reducing the Recovery Time Objective in the event of a failover.
Failover can be tested by simply promoting the DR Pod. This will not interrupt the replication and when testing is completed the DR Pod can be demoted, discarding changes. This means that the same script used to promote the DR Pod and online VM and Databases in a real emergency can be used to test the Pod promotion. See the Test Failover section of the whitepaper: ActiveDR Solution Overview White Paper.
To reverse the replication link, demote the Production Pod, and promote the DR Pod. With the DR Pod promoted, the act of demoting the Production Pod with the skip quiesce option, will automatically start the replication from the DR Pod to the Production Pod.
Note: The act of demoting any Pod creates an .undo-remote snapshot of the Pod that is placed in the destroyed bucket. This snapshot is used to undo a demotion if done accidentally and it will be automatically eradicated in 24 hours. If testing failover more often than once every 24 hours, this destroyed snapshot will need to be manually eradicated before the Pod can be demoted. This .undo-remote Pod can be cloned so that any data written but not replicated can be recovered.
Hyper-V
While Hyper-V can be run as a stand-alone Windows Server, this is not a common practice for production deployments. In production, to provide High Availability, server nodes are usually joined together into a Microsoft Cluster using Failover Cluster Manager or PowerShell. A Microsoft Cluster can have two types of disk resources; Cluster Disk Resources, and Cluster Shared Volumes (CSV).
The image above shows both a Cluster Disk Resource assigned to a File Server Role, and three Cluster Disk Resources configured as Cluster Shared Volumes (CSV) in Failover Cluster Manager.
A Cluster Disk Resource is a disk that has been added to the cluster, as a disk resource. A Cluster Disk Resource, like any standard cluster resource, can only be online on one cluster node at a time. Some examples of a Cluster Disk Resource use case are: a disk quorum, a File Server Role, and an Always On SQL Failover Cluster Instance Role.
A CSV is a clustered disk that is promoted or assigned into a Cluster Shared Volume. A CSV is assigned a mount point under "C:\ClusterStorage" and is accessible to every node of the cluster. That enables virtual machines to be live migrated independently of each other since many virtual machines can be placed on a single CSV and each virtual machine can be brought online on any of the physical cluster nodes.
Note: It is important that Cluster Disks and Cluster Roles, which includes highly available virtual machines, are taken offline before demoting the Pod.
When configuring ActiveDR with Hyper-V using Virtual Machine's on CSVs, the DR Cluster, or standalone Hyper-V Server should be preconfigured and tested before an outage occurs to reduce the Recovery Time Objective in the event of an outage. The DR Cluster can be online, or kept offline in order to save power. If the DR Cluster is online, the Virtual Machines and their CSVs should be offline when not testing failover.