Forum Discussion

Bryan Hall's avatar
Bryan Hall
Brass Contributor
Jun 06, 2018

Azure Site Recovery failover/failback with in-guest iSCSI?

What is the behavior of ASR-protected VMs (VMware) with in-guest iSCSI disks?  In this scenario, ASR would be used for DR, not migration (yet).

 

I understand that protection of such disks result in the creation (and attaching) of VHDs when failed over, (and if there is connectivity to the iSCSI target over the VPN/ExpressRoute, it may get duplicate disks).

 

What I'm really wondering is what is the expected behavior on fail-back?  Are the delta changes written back to the source VM's original iSCSI disks?  Is a new disk attached (I doubt that's the case)?  Does something else happen?  Or is it not supported?

azure
  • Bryan Hall's avatar
    Bryan Hall
    Brass Contributor
    Jun 11, 2018

    I gave it a try and in my testing, the resultant new disk in Azure is not re-protected back to the original iSCSI disk.  I guess since it's a new disk, Azure excludes it and does not recognize it as the same disk as the iSCSI.  At least that has been my experience during testing.

     

    I suppose in a migration it does not matter, and as Disaster Recovery, it serves its purpose on failover to Azure; but it definitely makes it more difficult to fail back to on-premises.  The only options that I see to get that data back to the source are:

    • Export the disk and then somehow deal with copying back the data to the iSCSI disk.  This would be really painful for extremely large disks.
    • Copy the data somehow (if you know what was changed) and copy it to the iSCSI disk.
    • Delete the source VM and let ASR recreate it on re-protect.   (I haven't tried this yet.  I'm not sure if we'd still run into the situation where the iSCSI-converted-to-VHD disk is considered a new disk and is excluded, or if ASR will recreate the VM with the disk.
  • Bryan Hall's avatar
    Bryan Hall
    Brass Contributor
    Jun 13, 2018

    To fail back to on-premises, a method that seems to work in a simple lab environment -- although not ideal -- is:

    1. Delete the source VM (maybe unregistering the VM will work, but I didn't try that).
    2. Re-protect the Azure VM.  (it still needs to be be registered with ASR.)
      • The Config Server/Master Target Server will create a new VM and replicate the disks, including the VHD that had been converted from iSCSI (on the failover to Azure).
    3. After protection has completed full synchronization, fail back to on-premises.

    The new VM will be created in ESX with the hostname of the VM.  In my test, the VMDK (of the iSCSI disk) will be mounted, while the iSCSI target's volume was offline, even though there was connectivity to the target.  Aside from choosing the Master Target server, VCenter and 

     

    The iSCSI volume can then be mounted, and the data copied from the VMDK to the iSCSI volume, if needed.  Alternatively, keep it as a VMDK.

     

    This definitely isn't ideal, as it makes the failback process much more difficult since enough space for the iSCSI disk is now needed on the VMFS datastore, and the entire VM needs to be fully replicated back to on-premises.  However, it does still serve its purpose by providing simple disaster recovery to Azure (it's just a little harder to get it back on-prem).

Resources