Updated on: 23 March 2021

VMware Cloud Disaster Recovery is VMware's on-demand disaster recovery service that is delivered as an easy-to-use SaaS solution and offers cloud economics to keep your disaster recovery costs under control.

These release notes provide information about new product features, system requirements and software support, caveats and limitations, and any known or fixed issues related to the service. 

Contents

 

What's New

23 March 2021

  • Inter-region DR in VMware Cloud on AWS. Protect your virtual machines running in VMware Cloud on AWS across cloud regions using VMware Cloud Disaster Recovery. Deploy the DRaaS Connector on your VMware Cloud on AWS clusters to start replicating the virtual machines running there to a VMware Cloud DR instance in another VMware Cloud on AWS region. Use VMware Cloud DR's orchestrated recovery capabilities to perform DR tests and failovers in a VMware Cloud on AWS SDDC in the target region.
  • 2-host pilot light and recovery SDDCs. Lower your steady state DR costs by deploying an i3.metal 2-host VMware Cloud on AWS SDDC to serve as a pilot light cluster for VMware Cloud Disaster Recovery. For DR tests and failovers, scale up the pilot light SDDC into a full-sized recovery site by adding more clusters to it. After the test or failover, scale back down to the 2-host footprint by removing the additional recovery clusters.
  • New AWS regions. You can now protect and recover your vSphere virtual machines in the following additional AWS regions: Asia Pacific (Seoul), Europe (Stockholm), and South America (São Paulo).
  • Support for protected sites running vSphere 7.0 Update 1. You can now protect virtual machines in sites running vSphere 7.0 Update 1. Please refer to the VMware Product Interoperability Matrix for the latest information on interoperability of VMware Cloud Disaster Recovery with other VMware solutions.
  • Multi-instance support for increased scalability. Deploy multiple instances of the scale-out cloud file system and multiple recovery SDDCs in the target region to protect a large volume of virtual machine data and a large number of virtual machines. Orchestrate company-wide DR testing and failovers from a single, federated VMware Cloud DR management console spanning across all instances.
  • HIPAA BAA. A HIPAA Business Associate Agreement (BAA) is available for VMware Cloud Disaster Recovery to help healthcare organizations stay in compliance while ensuring DR protection of their critical applications.
  • Enhanced replication resiliency. Benefit from increased resiliency of the replication process against transient network outages and temporary unavailability of the cloud file system due to cloud upgrades. The progress of a replication job is now saved periodically so that it can continue from that point onwards when the transient situation is resolved.

21 January 2021

  • New AWS region. You can now protect and recover your vSphere virtual machines in the Asia Pacific (Tokyo) AWS region.

17 December 2020

  • New AWS regions. You can now protect and recover your vSphere virtual machines in the following additional AWS regions: Europe (Ireland), Europe (Paris), and Asia Pacific (Mumbai).
  • Support for I3en hosts in Recovery SDDC: You can now provision I3en hosts in your Recovery SDDC and use them for recovery operations.
  • Support for multiple vSphere clusters in Recovery SDDC: You can now add multiple vSphere clusters to your Recovery SDDC to increase your recovery capacity.
  • Faster recovery. Failover now happens faster as virtual machines are powered on in parallel in batch sizes that scale with the number of hosts in your Recovery SDDC.
  • Use vSphere tags to configure protection groups. You can now define which virtual machines should be members of a protection group based on their vSphere tags. When backing up, any virtual machines with the tags you specify are dynamically associated with the protection group and included in the snapshot.
  • Preserve vSphere tags on VMs upon Recovery. The recovery process now preserves tags on recovered VMs that were associated with those VMs on the original protected site. The tags and their associated categories must be pre-configured on the recovery SDDC for successful failover.
  • Data transfer optimizations for failback and VM restore. In situations where incremental data transfer based on snapshot data is not possible during a failback or VM restore operation, VMware Cloud Disaster Recovery now leverages the VM content that already exists on the restore destination to speed up the failback or VM restore.
  • Consistent handling of time zones in UI. All timestamps shown in the UI now display using the user’s browser time zone setting. Protection Group schedules are still based on the protected site’s time zone. When this time zone is different from the user’s browser time zone setting, the UI indicates the protected site's time zone for reference.
  • Show progress of Recovery SDDC deployment and snapshot replication. The UI now provides progress status for Recovery SDDC deployment and snapshot replication, listing all running and completed tasks associated with these operations.
  • Support for protected sites running vSphere 7.0. You can now protect virtual machines in sites running vSphere 7.0. Please refer to the VMware Product Interoperability Matrix for the latest information on interoperability of VMware Cloud Disaster Recovery with other VMware solutions.

20 October 2020 - Introducing VMware Cloud Disaster Recovery

Protect your vSphere virtual machines (VMs) to the cloud and recover them to VMware Cloud on AWS using VMware Cloud Disaster Recovery. Based on the scale-out cloud file system technology developed at Datrium, VMware Cloud Disaster Recovery helps lower the cost of disaster recovery by storing backups in cloud storage, and allows you to pay for recovery host capacity only when you want to conduct a disaster recovery test or perform a recovery.

VMware Cloud on AWS makes rapid recovery at scale possible with its "live mount" capability, which enables fast power-on of the recovered VMs in VMware Cloud on AWS without a long data rehydration process. A fully-featured SaaS-simple disaster recovery orchestrator is built-in to minimize the need for manual effort during recovery. The service is tightly integrated with VMware Cloud on AWS for efficient recovery and a consistent operational experience without error-prone VM format conversions.

For more information, visit our blog and FAQ.

Features of VMware Cloud Disaster Recovery include:

  • Available in US West (Oregon), US East (N. Virginia), US East (Ohio), US West (N. California), Europe (London), Asia Pacific (Sydney), Canada (Central), Asia Pacific (Singapore), and Europe (Frankfurt).
  • Option to maintain a small, pre-provisioned "pilot light" SDDC to run foundational components and further speed recovery
  • Continuous disaster recovery health checks every 30 minutes for increased reliability
  • End-to-end and daily data integrity checks of backup copies
  • Deep history of immutable snapshots for recovery from ransomware attacks
  • Audit-ready, detailed disaster recovery reports
  • Delta-based failback

System Requirements and Software Support

  • VMware vSphere Compatibility. VMware Cloud Disaster Recovery is currently supported with on-premises vSphere 7.0, vSphere 6.7 and vSphere 6.5. For more information, go to the VMware Product Interoperability Matrices: https://www.vmware.com/resources/compatibility/sim/interop_matrix.php#interop&700=
  • DRaaS Connector VM Requirements. To deploy the DRaaS Connector VM, make sure that the vSphere site where you intend to deploy it has the following resources for the VM:
    • CPU: 8 GHz (reserved)
    • RAM: 12 GiB (reserved)
    • Disk: 100 GiB vDisk
    • Network connectivity: Between DRaaS Connector and vCenter Server and ESXi hosts, and between the DRaaS Connector and VMware Cloud Disaster Recovery
  • Browser support:
    • Windows: Google Chrome, Firefox, Windows Edge (latest versions)
    • MacOS: Google Chrome, Firefox (latest versions)

Caveats and Limitations

The following section lists current VMware Cloud Disaster Recovery caveats and limitations as of release date.

  • VMware Cloud Disaster Recovery does not support the following:
    • VMs created by vSphere vApp(s)
    • Fault Tolerant VMs
    • Shared disks
  • Only the clusters added to your SDDC using the VMware Cloud Disaster Recovery UI can be used in DR plans. If a cluster is added to your SDDC from the VMware Cloud Services console, it will appear in the VMware Cloud Disaster Recovery UI with a status of Unconnected and cannot be used in your DR Plans. Additionally, you should only delete clusters using the VMware Cloud Disaster Recovery UI. 
  • For protected sites with more 1000 VMs, you might experience some responsiveness issues with the VMware Cloud Disaster Recovery UI, such as slow loading of pages or windows when previewing protection group VM membership, creating and editing DR Plans, and during plan compliance checks.
  • VMware Cloud Disaster Recovery does not create backups of VM templates. If you include a VM template in a protection group, it will not be included in snapshots.
  • Recovery of VMs with an attached ISO does not include the ISO during backup or failover/failback. 
  • If a VM is being protected by VMware Cloud Disaster Recovery and also being backed up by another VM backup solution that uses vSphere Storage APIs for Data Protection (VADP), and both solutions take a snapshot of the VM at exactly the same time, the snapshot will still be taken but that VM will not be included in the VMware Cloud Disaster Recovery snapshot.
  • VMware Cloud Disaster Recovery does not support an internet proxy server between the DRaaS Connector and the cloud.

Stable SDDC Configuration

To ensure the health and availability of the VMware Cloud Disaster Recovery Service Offering, do not change the following SDDC settings. Changing any of these settings could interfere with and potentially disrupt the delivery and functioning of the service. 

  • Do not change SDDC default firewall rules. Changing the SDDC firewall could interrupt access from the SDDC to the SCFS or Orchestrator components. By default, when your SDDC is deployed its network will contain a set of pre-configured firewall rules which begin with the "CloudDR-SystemRule-" prefix. These firewall rules should not be deleted. SDDC Firewall rules with this prefix cannot be edited or deleted in the VMware Cloud Disaster Recovery UI, but these rules can be edited and deleted in the VMware Cloud on AWS console UI. So, do not change or delete any of these SDDC firewall rules.
  • Do not rename your SDDC once you have deployed it. 
  • Do not change network configuration on the proxy VM.

Virtual Desktop Infrastructure Support

VMware Cloud Disaster Recovery can provide disaster recovery protection for VMs that run on Virtual Desktop Infrastructure (VDI), as well as the other types of software needed to enable the virtual technologies (e.g., Active Directory, connection servers, etc.). In this release, the following are not supported for VDI:

  • AppVolumes Writable Volumes
  • Modifying AppVolumes AppStacks once failed over
  • Modifying the Horizon Golden Master image once failed over.

Known Issues

  • NEW vSphere 7.0 Update 1 Cluster (vCLS) virtual machines should be excluded from protection groups 

    Starting with vSphere 7.0 Update 1, vSphere Cluster Services (vCLS) is enabled by default and runs in all vSphere clusters. vCLS uses agent virtual machines to maintain cluster services health (vCLS VMs) which are created when you add hosts to clusters. These vCLS VMs must not be included in any protection groups. 

    Workaround: When creating a protection group, use an exclude pattern to filter out any vCLS VMs that exist (there are multiple vCLS VMs in a cluster). Also, make sure that if you have folder queries in the protection group that none of the chosen folders contain any vCLS VMs.
     

  • NEW Re-adding a removed DRaaS Connector not supported

    If you remove a DRaaS Connector from a protected site, you cannot re-add the connector. 

    Workaround: If you remove a DRaaS Connector from a protected site, you must re-deploy a new DRaaS Connector to replace it. 

  • NEW vCenter registration fails with unknown error

    During vCenter registration for an on-premises protected site, an "unknown error" is displayed in a dialog box and the operation fails. This issue could be related to time synchronization for the DRaaS Connector.

    Workaround: If you encounter this unknown error message when trying register vCenter for a protected site, follow these instructions: 

    Correct the NTP configuration on ESXi (hosts)

    1. From the vCenter UI, select ESXi host under Hosts and Clusters click View > Configure > System > Time Configuration > configure the NTP settings for the host. 

    Configure the DRaaS Connector VM to sync time with the ESXi host

    1. From the vCenter UI, select the DRaaS Connector VM, right-click, and select VM Options > VMware Tools > Synchronize Time with Host.
    2. Select the check "Synchronize at startup and resume" option.
  • NEW Cannot restore an individual VM back to the source site using the manual snapshot restore capability if the original VM was deleted

    When restoring an individual VM back to the protected site using the manual snapshot restore capability, if the original VM still exists in vCenter, then you can restore the VM normally. If the original VM is deleted, you will not be able to restore the VM. 

    Workaround: Do not delete the original VM.

  • NEW Unable to set default data store for failback DR Plan when a mapped host is not part of a cluster.

    If a mapped compute resource (such as a host) in a failback DR Plan is not part of a cluster on an on-premies failback site, the default datastore cannot be mapped in the plan. Because the VMs in the plan have nowhere to fail back to, compliance checks will flag that the default datastore cannot be set, and when the plan is run it will display an error and fail to restore the VMs in the plan. 

    Workaround: Create a new cluster on the on-premises protected site (if one doesn't exist) and then add the host to the cluster. Then you can edit the plan and map the default datastore for the failback plan.

  • NEW Failover in a large scale environment failed with errors during VM power-on

    In some cases, a DR Plan failover was failing during recovery or while recovered VMs were being powered-on.

    Workaround: Retry the failover operation. 

  • Some special characters not supported in vSphere inventory object names

    VMware Cloud Disaster Recovery does not support the following special characters in vSphere inventory object names (such as VMs, VM templates, hosts, clusters, networks, datastores):

    {   }   [   ]   \   %   @   " 
                

    Curly brackets, square brackets, backslash, percentage symbol, at symbol, and double quotation marks are not supported. 

    For example, if you use any of these special characters in VM names, the VM will not be included in any protection group snapshots.

    Workaround: Do not use these special characters in your vSphere object inventory names. 

  • VMs created on virtual hardware version 18 not supported

    VMs created on virtual hardware version 18 are not supported for failover or failback. 

    Workaround: Ensure that your VMs are running virtual hardware version 17 or earlier.

  • After failover to the VMware Cloud on AWS SDDC, do not disable change block tracking (CBT) on any VMs in the VMware Cloud on AWS SDDC

    Changing CBT on VMs in your SDDC prevents the VM from being failed back in a timely manner with VMware Cloud Disaster Recovery. Reverting to a VMware VM snapshot in the VMware Cloud on AWS SDDC causes CBT to reset, resulting in drastically slower failback (go to https://kb.vmware.com/s/article/71155 for more information).

    Workaround: Do not revert to a VMware VM snapshot in the VMware Cloud on AWS SDDC, and do not change CBT settings for any VMs.

  • Protection groups with empty folders must be mapped properly in a DR Plan, or a failover will fail

    If one of the folders is empty when a snapshot of a protection group is taken, you must explicitly map that empty folder to a failover target in a DR Plan, or else that plan fails to complete during a failover.

    Workaround: None.

  • Failover terminated after membership change leaves protection group in bad state

    During failover of a DR Plan, the folder membership and vCenter Server membership of the protection group are changed, and if a user terminates the DR plan failover after the membership change, the protection group is put into a bad state, rendering it unable to be edited or fixed.

    Workaround: If this occurs in your environment, contact VMware Support to correct the protection group membership.

check-circle-line exclamation-circle-line close-line
Scroll to top icon