Here is a scenario you might encounter with one of your customers, in using Azure Site Recovery (ASR) for Business Continuity and Disaster Recovery (BCDR).
Let’s say there is an environment, running on Hyper-V which contains 80 Virtual Machines. Let’s also make the assumption that the majority of these VMs are running the Windows Server 2012 R2 Operating System, and are using the default disk configuration with Basic Disks.
Now let’s throw into the mix some File Servers that are using dynamic disks and striped volumes.
When we combine striped volumes with Windows Server 2012 R2, we encounter some issues.
Firstly, ASR is able to successfully replicate the File Server. The issue occurs when performing a failover. When performing a failover (either a Test Failover, or Planned/Unplanned Failover), the disks that made up the stripped volume are not accessible and are not automatically brought online.
As we can see in the Disk Management console, the non-striped basic disks were not affected (they are both online and accessible). But the disks that were a part of the striped volume are not.
We need to modify the current SAN policy from within the target Virtual Machine.
NOTE: The following steps need to occur from within the target VM, and not from the Hyper-V host.
- Log into the VM, and open an elevated Command Prompt
- Type: DiskPart (and hit Enter)
- Type: SAN (and hit Enter)
In order to ensure that all disks are brought online and are accessible (i.e. Read/Write), we need to set the SAN policy to “OnlineAll”.
- Type: SAN POLICY=ONLINEALL (and hit Enter)
After this change has been applied, it can take up to 30 minutes before the changes are synchronized to the Recovery Services vault. Once this has occurred, performing a failover (either a Test Failover, or Planned/Unplanned Failover), the dynamic striped disks will be brought online and be accessible as expected.
Credit: A big thank you goes out to the Raf Nijs from Simac ICT Netherlands for providing the details for this blog post.