When you run a recovery plan for disaster recovery, you have the option to run failed-over VMs live on the cloud file system, or you can have VMs fully migrated to the vSAN datastore on the recovery SDDC.

VM storage configuration for a plan provides two options for failed-over VMs:
  • Run VMs live on the cloud file system. After failover, VMs run live directly on the cloud file system, which offers a faster failover time for better RTO. Another benefit of running VMs on the cloud file system is that subsequent failback operations are also faster, resulting in less downtime. Some VMs recovered on the cloud file system might require performance that is better suited to vSAN. After a recovery plan operation completes, you can selectively Storage vMotion workloads to the vSAN datastore to improve performance. If you Storage vMotion the VMs manually, it can cause a longer failback process for those VMs.

    Another benefit of using the cloud file system for disaster recovery operations is that it you will likely require fewer, and potentially less expensive, host types to operating during disaster recovery. You only have to size and scale your SDDC for CPU and memory to avoid adding hosts to meet requirements for vSAN capacity, which is often the constraint for sizing of an SDDC.

  • Full storage migration to recovery SDDC. Performs a full Storage vMotion migration from the staging datastore to the SDDC vSAN datastore as the final step of running a plan.

    Using this option increases RTO, as the plan cannot be committed or finished until all Storage vMotion operations are complete. At scale, this can take hours or days. Without committing a successful failover plan, even with all VMs up and running, you cannot then run a failback operation until the initial Storage vMotion is complete. Also during failback operations, there will be a longer failback outage to recover workloads that have been migrated to vSAN. Fully migrated VMs provide higher IOPS performance, which is suitable for VMs that require higher performance, such as database VMs. This option might require more hosts on the cluster, depending on the size of the VMs.

Best practice: If you have some workloads that you want to recovered on vSAN for performance reasons, create separate protection groups and recovery plans for those VMs. When you run a recovery plan and select the target datastore for recovery, all VMs in the plan and all associated protection groups recover to the same datastore. You cannot selectively recover VMs to one datastore or the other when running a plan.
Best practice: Do not delete an SDDC from VMware Cloud if VMs are running live on the cloud file system. When deleting an SDDC from the VMware Cloud UI, ensure that there are no live VMs on the cloud file system. Deleting the SDDC will cause subsequent failovers to fail.
Recovery plan for disaster recovery VM storage runtime settings

Caveats for Running VMs Live on the Cloud File System

The following restrictions apply when running VMs live on the cloud file system:
  • Configuration changes made to a VM running live on the cloud file system will not persist if VM is migrated to the vSAN datastore and then failed back. When a VM is failed over to the cloud file system, any changes made to the VM such as renaming the VM, CPU, memory updates, are retained on the VM after failback. If the VM is migrated to the recovery SDDC vSAN datastore, those configuration changes will not persist if the VM is failed back to the protected site. In this situation, failback reverts the VM to the original configurations at the time of the first failover.
  • Other backup software might increase the VMDK file size of a VM running live on the cloud file system, causing failback to fail. If a VM running live on the cloud file system is also being backed up by other software, the other software might increase the VM VDMK file size past an allowable size, which could cause failback of that VM to fail.
  • Manually performing a storage vMotion of a VM from a vSAN datastore to the cloud file system is not allowed. Manual vMotion a VM from a vSAN datastore to the cloud file system is not supported.

VMs List Indicates VMs Running Live on a Cloud File System

The Virtual Machines list shows all protected VMs, with a column to indicate if the VM is running live on the cloud file system:

The virtual machines list showing if VMs are running live on the cloud file system.

The Cloud File System Datastore and the SDDC Datastore

When you fail over VMs using the Run VMs live on the cloud file system option, you are running those VMs on the recovery SDDC datastore named ‘ds01’.

The cloud file system datastore named ds01 as seen in the SDDC vSphere client.

When you fail over VMs using the ‘Full storage migration to SDDC’ option, VMs are initially staged on the 'ds01' datastore, and then are migrated to the SDDC vSAN datastore named ‘WorkloadDatastore’.

The recovery SDDC datastore named WorkloadDatastore as seen in the vSphere client.

If you start by running VMs live on the cloud file system, but decide later that you want faster performance, you can migrate the VM to the WorkloadDatastore on the recovery SDDC.

Currently, you can only migrate a complete VM from the cloud file system ds01 datastore to the Workload datastore. If you only migrate some disks of the VMs but not all of them, then the VM cannot be failed back to the protected site.

For more information, see Migrate a VM from the Cloud File System to the SDDC Datastore.