| VMware Cloud Disaster Recovery | 12 JAN 2022 Check for additions and updates to these release notes. |
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 VMware Cloud Disaster Recovery (commonly called VCDR or VMware Cloud DR) product features, system requirements and software support, caveats and limitations, and any known or fixed issues related to the service.
17 December 2021
6 December 2021
14 October 2021
ISO 27001/27017/27018: VMware Cloud DR has achieved the International Organization for Standardization (ISO) certificate, supporting 27001, 27017, and 27018 standards. Please visit the VMware Cloud Trust Center to learn more and download ISO certificates.
5 October 2021
Purchase through Managed Service Providers (MSP): Purchase VMware Cloud DR through your preferred Managed Service Provider (MSP) and use Cloud Partner Navigator (CPN) to onboard and access the service. Your MSP will handle the billing, support, and activation of VMware Cloud DR deployment for you.
2 September 2021
30-minute RPO: Confidently protect your most critical virtual machines running on your on-premises datacenter with VMware Cloud DR by configuring protection schedules with Recovery Point Objectives (RPOs) as low as 30 minutes, so that the risk of data loss from unforeseen DR events is minimized. VMware vCenter Server and ESXi on the source site should be upgraded to 7.0 Update 2c-vcdr to enable 30-minute RPOs. See documentation on caveats for this feature.
31 August 2021
Purchase online using credit card: Get started quickly with your VMware Cloud DR evaluation by purchasing online using a credit card as your payment method.
4 August 2021
27 July 2021
Disaster Recovery in VMware Cloud Launchpad. Accelerate your Disaster Recovery implementation with step-by-step guidance, relevant tools and a rich set of resources using VMware Cloud Launchpad. Click on "Learn More" under "Disaster Recovery" to navigate to launch your DR journey. This experience is available to everyone without requiring login to VMware Cloud.
16 July 2021
Pilot deployment for AWS Seller of Record. You can now try VMware Cloud DR as a "pilot" before committing to a term subscription, even when you have purchased it with AWS as seller of record. Pilot deployments are charged at a fixed hourly rate and include 5 TiB of protected capacity and 25 protected virtual machines. Any usage beyond these limits will incur charges at the applicable per-TiB overage and per-VM on-demand rates. Once you are done with your evaluation, create a 1-year or 3-year committed term subscription to seamlessly convert this to a standard deployment and continue using the service. Please refer to the VMware Cloud DR pricing page for additional details.
23 June 2021
7 May 2021
CSA Trusted Cloud Provider: VMware Cloud DR is now a Cloud Security Alliance (CSA) Trusted Cloud Provider and registered as a Security, Trust, Assurance and Risk (STAR) Level One service. CSA is an organization dedicated to defining best practices to help ensure a secure cloud computing environment. STAR Registry is a publicly accessibly registry that documents the security and privacy controls. You can find the VMware Cloud DR STAR Register listing, including the downloadable CAIQ here.
27 April 2021
The following new features are available or in preview for the new release:
Definitions
Available: Feature now available for use by applicable customers. May not be available in all AWS regions.
Preview: Feature released in preview to gather feedback. May not be available to all applicable customers or in all AWS regions*.
*We cannot guarantee that features marked as ‘Preview’ will become available within any particular time frame or at all. Make your purchase decisions only on the basis of features that are Available.
23 March 2021
21 January 2021
17 December 2020
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 DR 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 DR include:
WHATS NEW
NEW Failback failed with error "unable to locate VM Configuration information"
In some cases a failback operation failed due to some of the VMs being in an invalid state.
Workaround: Open vCenter on the Recovery SDDC and delete those VMs in the failback that are in an invalid state. Then, retry the failback operation.
The following section lists current VMware Cloud DR caveats and limitations as of release date.
To ensure the health and availability of the VMware Cloud DR 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.
VMware Cloud DR 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:
FIXED Non-responsive UI
In one environment the VMware Cloud DR UI was flashing and then fading to white and could not load properly. This was due to a misalignment between the orchestrator UI and certain AWS APIs. This has been fixed.
FIXED Send support bundle malfunction
Previously, some customers experienced issues being able to successfully submit a WMare Cloud DR support report. This has been fixed.
FIXED Protection groups membership issue finding VMs after VMware Cloud DR November release upgrade
After upgrading to the VMware Cloud DR November release, some protection group queries did not function properly, and thus could not find VMs to match the queries. This has been fixed
FIXED Amazon Linux release fixes CVE-2021-41864 and CVE-2021-43527
VMware Cloud DR is now updated to reflect security fixes identified by the Common Vulnerabilities and Exposures (CVE) organization.
FIXED Failover failed to complete due to insufficient storage resources
In one situation, a user experienced issues with completing a failover operation, with an error message stating insufficient volume capacity to complete the request. This has been fixed.
FIXED User with more than one seller of record was unable to create new subscription
If a user tried to create a new subscription, and the billing account details for the seller was not used by the service when getting offers for the new subscription, the user could not create the subscription. This issue has been fixed.
FIXED Remote access process failed after upgrade
In some environments, after upgrading VMWare Cloud DR a backend process for remote access was failing. This has been fixed.
FIXED Snapshot replication failure
In some situations, snapshot replication would fail due to resource contention issues. This has been fixed.
FIXED Default management gateway rule for Recovery SDDC opened HTTPS access to VMware Cloud on AWS vCenter
Some VMware Cloud DR organization owners might have received security notification from VMware Cloud indicating that their recovery SDDC management gateway has a firewall rule allowing unrestricted access to vCenter. This patch corrects the issue by replacing the rule with two new rules that restrict HTTPS traffic to vCenter from only VMware Cloud DR components. The fix removes this management gateway firewall rule that previously allowed vCenter access to Any. (For information about SDDC firewall rules, see Create a Firewall Rule for Public IP Addresses Accessing vCenter.)
NEW Unable to dismiss notifications in the Global Console
In the VMware Cloud DR Global Console, a user is unable to dismiss notifications when clicking on the small bell icon in the upper right of the UI. Clicking "Dismiss" also does not clear the notification, and the notification is still present when the user clicks the Bell icon the next time.
NEW Global Console notifications not listed in chronological order
In the Global Console, when a user clicks on the small bell icon in the upper right of the UI, the list of notifications are not always ordered chronologically.
NEW Default Winows ZIP utility not unpacking guest file restore downloads
if you perform a restore guest file operation using the Windows default zip utility (from the Windows File Explorer), the downloaded ZIP file downloaded does not contain any content. This issue only applies to the Windows OS default system unzip utility.
Workaround: Use 7ZIP or WinRAR utility on Windows systems for guest file restore operations.
NEW High-frequency snapshot task terminated due to vMotion issue
In some cases during a high-frequency snapshot backup operation, when a vMotion is also in progress, the backup may be terminated. In this situation, the vMotion operation leaves the VM in an Invalid State.
Workaround: If this occurs, unregister the VM from the ESXi host and re-register it.
NEW Failback failed with error "unable to locate VM Configuration information"
In some cases a failback operation failed due to some of the VMs being in an invalid state.
Workaround: Open vCenter on the Recovery SDDC and fixt hose VMs that are in an invalid state. Then, retry the failback operation. A VM can be invailde due to severeal reasons, such as removed data store, a missing or corrupted VMX file, or other reason. As a last restort, you can delete and rebuild the VM.
NEW DRaaS Connector cannot reach vCenter on 172.77.x.x
The DRaaS Connector cannot reach vCenter or ESXi hosts on private customer networks on subnet 172.17.x.x. For example, if the protected site vCenter IP address is 172.17.10.10, the DRaaS Connector cannot connect to it.
Workaround: Contact VMware Support if you need the DRaaS Connector to connect to a private network within this address.
NEW Delete Recovery SDDC Error
In some instances when a user deletes a Recovery SDDC, an error sometimes displays, even if the deletion was successful.
If you see this behavior, please contact VMware support to confirm that the Recovery SDDC was deleted successfully.
DRaaS Connector offline and inoperable after being powered off more than two weeks
If you power off a DRaaS Connector for more than 2 weeks, it will show as offline and potentially stop functioning.
Workaround: If your DRaaS Connector is powered off more than two weeks, shows as offline and is not usable, contact VMware support for assistance, or deploy a new connector.
Two-host Recovery SDDC deployments not supported with VMware Cloud SDDC software version 1.15
You cannot deploy a 2-host Recovery SDDC for a VMware Cloud SDDC running software version 1.15.
vSphere warning during DRaaS Connector deployment
When deploying the DRaaS Connector as an OVA in the vSphere client, vSphere will display an error stating that the connector OVA contains advanced configuration options and warns the user to proceed with caution. The mentioned advanced configuration is used by VMware Cloud DR to distinguish Connector VMs from customer VMs.
Workaround: You can ignore this message and safely deploy the DRaaS Connector in your vSphere environment.
A VM with tags belonging to a protection group that uses only name or folder queries will not retain tag information after failover, and no compliance check is flagged
If a VM with tags is backed up in a protection group using either a name pattern or folder membership query (but no tag query), the DR Plan compliance checks does not warn if the tags on the VM exist on the Recovery SDDC. When failover occurs, the VM will be recovered, but tag information will not be applied, and the tag will no longer exist on the VM.
Workaround: You can make sure that the tags on the VM exist on the Recovery SDDC, or make sure the protection group also uses a tag query that matches the tag on the VM.
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, re-deploy a new DRaaS Connector to replace it.
Networking may be disabled when manually restoring a VM back to a source site (protected SDDC), if the original VM was deleted.
When restoring an individual VM back to a protected VMware Cloud on AWS SDDC using a manual snapshot restore, if the original VM still exists in the SDDC vCenter, then you can restore the VM normally. If the original VM was deleted, you might need to manually reconfigure networking for that VM.
Workaround: If the virtual NIC on the restored VM becomes disconnected when you power on the VM, delete the NIC and then re-add the NIC to bring the VM back to a connected state.
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.
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.
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.
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.
