06-06-2018 10:34 AM
06-06-2018 10:34 AM
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?
06-11-2018 11:50 AM
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:
06-12-2018 06:21 PM
To fail back to on-premises, a method that seems to work in a simple lab environment -- although not ideal -- is:
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).