VMware Live Recovery Release Notes

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

What's New

6 August 2024

VMware Live Cyber Recovery

• Expanded capacity with support for up to four cloud file systems per-recovery SDDC. Enjoy expanded cloud storage capacity by adding additional cloud file systems to your VMware Live Cyber Recovery deployment. VMware Live Cyber Recovery now supports up to four cloud file systems that can be associated with a single SDDC, which provides the following benefits: 

  • Improved performance when running VMs live on the cloud file system during DR test and/or failover and ransomware recovery workflows.

  • Improved network performance by separating snapshot replication for large numbers of VMs across multiple cloud file systems and protected sites.

  • Simplified network topologies, because you only need to manage networking for one SDDC, rather than having to link multiple SDDCs together.

• Protect up to four logical sites in a single protected SDDC.  Expand your protected SDDC site coverage to include up to four protected sites on a single SDDC. Previously, each protected SDDC could only include a single protected site. With the introduction of support for up to four cloud files systems per recovery SDDC, you can now configure up to four protected sites to point to their own cloud file system.

• Fast restore with VMware vSAN local snapshots for faster ransomware recovery. Reduce ransomware recovery VM restore times by leveraging a new integration with vSAN Data Protection's local snapshot manager. If a protected site vCenter is using VMware vSAN Data Protection, the ransomware recovery workflow will automatically restore a local VM snapshot closest to the snapshot candidate used in ransomware recovery prior to beginning the recovery from cloud to protected site.  This can help avoid large, time consuming data transfers when recovering cleansed VMs to the original protected site.

• Sync back for optimized failback operations. Reduce DR failback times by performing 'sync back' operations after a failover to periodically transfer incremental, delta-based updates for failed-over workloads on a cloud file system. Sync back can reduce the time required for failback by minimizing the delta between the running VM workload in the recovery SDDC and the VM residing in the protected site.

• API tokens replaced by OAuth 2.0 Apps for inter-service authentication. VMware Live Cyber Recovery now leverages OAuth 2.0 apps to communicate with VMware Cloud Services backend services and VMware Cloud on AWS, replacing the former usage of API tokens. For current users, when your existing API tokens expire they will automatically be replaced with the new OAuth apps. For more information, see Authorize VMware Live Cyber Recovery.

• Advanced file system metrics for ransomware recovery. Improve VM snapshot selection accuracy in the ransomware recovery workflow by leveraging a more detailed file system analysis of VM snapshots.  By selecting the 'Advanced metrics' checkbox on guided restore point selection, you will find the original change rate and entropy details, plus many new metrics. New metrics include: the amount of new files that were created and modified on the VM, and the number of new files created with known or ransomware or suspicious file extensions. 

• Ability to delete a cloud file system. Enjoy a new self-help administrative option that eliminates the need to contact support for assistance. You now have the ability to delete a cloud file system within the VMware Live Cyber Recovery UI. Before you can delete a cloud file system, you must delete all protected sites associated with the cloud file system.

VMware Live Site Recovery

• Support VMware Live Site Recovery in offline mode and manage subscriptions across all use cases. You can now use the VMware Live Recovery global console to manage subscription quantities (VMs) between VMware Live Site Recovery in offline mode., connected mode, or for hyperscalers. The minimum version required to take advantage of offline mode is VMware Live Site Recovery 9.0.2.

19 March 2024

General Availability of VMware Live Recovery: VMware Live Recovery delivers powerful cyber and data resiliency for VMware Cloud Foundation. You can protect applications and data from modern ransomware and other disasters across VMware Cloud Foundation environments on-premises and in public clouds with flexible licensing for your changing business needs and threats.

VMware Live Recovery provides a variety of benefits, including:

1. Secure cyber recovery: industry-leading ransomware recovery-as-a-service with immutable snapshots, guided workflows, isolated “clean rooms” and embedded behavioral analysis.

2. Simplified consumption: single subscription that provides a full range of cyber and disaster recovery capabilities, as well as licensing flexibility for changing business needs and threats.

3. Unified service experience: centralized visibility and monitoring of ransomware recovery and disaster recovery across on-premises and public clouds, with access to respective management consoles.

VMware Live Recovery offers ransomware recovery and disaster recovery leveraging two technology stacks:

• VMware Live Cyber Recovery (formerly known as VMware Cloud Disaster Recovery)

• VMware Live Site Recovery (formerly known as VMware Site Recovery Manager)

Existing VMware Cloud DR customers will automatically get upgraded to VMware Live Recovery without further action. Existing VMware Site Recovery Manager customers can choose to purchase VMware Live Recovery when they are ready to access all new features and capabilities. For further information, refer to the FAQ and the announcement blog.

Fixed Issues

• VMware Live Cyber Recovery: Transit Connect issues occurred when multiple SDDC groups exist across multiple AWS regions

  Previously, when setting up Transit Connect with SDDC group of one or more SDDCs and some SDDCs being in different AWS regions, VMware Live Cyber Recovery would only attach to a single AWS region, and so only SDDCs in that single region would have a Transit Connect private connection. SDDCs in the other regions would not receive the private connections.

  Workaround: For any existing Transit Connect configurations on your protected site that are in this situation, you will need to reconnect the SDDC group in the VMware Live Cyber Recovery UI. (New Transit Connect configurations do not need this workaround.)

  1. Open the VMware Live Recovery UI.

  2. From the left navigation, select Settings and then click Private Network Connection.

  3. In the Private network connection dialog box, under Transit Connect SDDC groups, click Connect next to any SDDC groups (with protected SDDCs) that show a status of "Available."

  4. Close the dialog. Wait about 10 minutes. 

  5. Open the Private network connection dialog box again to check that the SDDC group status shows as  "Connected," which means it is using VMware Transit Connect for a private connection.

• VMware Live Cyber Recovery: "API Token Expiration Notice" from VMware Cloud Services safe to ignore

  VMware Live Cyber Recovery has replaced API tokens with OAuth 2.0. However, over course of the next 6-12 months, existing customers might receive "API Token Expiration Notice" from VMware Cloud Services. You can ignore this message, and you do not need to recreate an API token. 

Known Issues

• NEW High-frequency quiesced snapshots in VMware Live Cyber Recovery not functioning due to incompatibility with VMware ESXi

  If you have configured high-frequency snapshots with quiescing in VMware Live Cyber Recovery, the quiescing feature is not working due to incompatibility issues VMware ESXi.

  Action: You should disable quiescing in all high-frequency snapshots in your VMware Live Cyber Recovery protection groups until the issue is fixed. VMware by Broadcom will alert customers when the issue is resolved.

• The offline key dialog does not open when you click Enter an offline license key

  When using an Enhanced Linked Mode environment, opening the Connect to VMware Live Recovery wizard and selecting the peer vCenter makes the Enter an offline key menu unusable. Clicking Enter an offline license key does not open the dialog for the offline key.

  Workaround: Open the Site Recovery UI on the remote site and run the wizard from there.

• VMware Live Site Recovery does not automatically propagate the offline key to a newly added vSphere Replication pair

  If you add vSphere Replication to a VMware Live Site Recovery pair which uses offline mode, Live Site Recovery does not automatically activate 1 minute RPO for the newly added vSphere Replication pair.

  Workaround: Remove the assigned offline key and create a new offline license key for the site pair. See, Remove the offline mode license for VMware Live Site Recovery and Set up offline mode for VMware Live Site Recovery.

• Converting from online mode to offline mode does not erase the cloud connection info

  If you switch from online mode to offline mode, the Summary page of VMware Live Site Recovery displays errors that VMware Live Site Recovery functionality is deactivated.

  Workaround: Restart the VMware Live Site Recovery service.

• You are unable to apply an offline license key generated using an old change request key

  If you generate a change request key and close the Enter an offline license key dialog before applying the license, you are unable to use that license key to activate offline mode.

  Workaround: Generate a new license key using the latest change request key and apply the license before closing the Enter an offline license key dialog.

• The Connect to VMware Live Recovery button is missing from the VMware Live Site Recovery UI

  The Enter an offline key dialog is located inside the Connect to VMware Live Recovery wizard. If you disconnect from VMware Live Recovery cloud services, the Connect to VMware Live Recovery button disappears from the VMware LIve Site Recovery UI, and you are unable to activate offline mode.

  Workaround: Navigate to the Home view in the VMware Live Site Recovery UI, and click Setup Connection to open the Connect to VMware Live Recovery wizard.

• The Live Site Recovery Appliance Management Interface does not allow you to connect to VMware Live Recovery

  If you are using an offline mode license with VMware Live Site Recovery and attempt to connect to VMware Live Recovery cloud services from the Appliance Management Interface nothing happens.

  Workaround: Remove the offline license from the VMware Live Site Recovery UI before connecting to VMware Live Recovery cloud services.

• NEW VMware Live Cyber Recovery: High frequency snapshot failure with internal error

  On some protected sites running ESXi 7.x, some high-frequency snapshots were failing with this error: "VM continually failing with error "Internal error: Non-BaseSnapshotMismatch and non-FullSyncRequired fault (SystemError)".

  Workaround: Contact VMware by Broadcom support for assistance.

• NEW VMware Live Cyber Recovery: Private network connect dialog box shows Transit Connect status of 'Ready. Not used by any site.' when in fact it is being used by sites.

  In some cases, when you configure a protected site with private network connection using Transit Connect, the Private network connection dialog box shows a status of 'Ready. not used by any site.', even though Transit Connect is being used by one or more sites.

  When you try to Unset a private connection, the list of sites might appear empty and not show the actual sites using Transit Connect. 

  If you attempt to Disconnect a Transit Connect SDDC group, the Disconnect button is incorrectly enabled, even though you cannot disconnect an Transit Connect SDDC group with a protected site using a private network connection.

  Workaround: To determine which protected SDDC sites are using Transit Connect, from the VMware Live Cyber Recovery UI go to the protected site and on the Details panel, Connection type should be listed as VMware Transit Connect.

  If you need assistance, contact VMware by Broadcom Support.

• NEW VMware Live Cyber Recovery: Unresponsive ESXi hosts

  In one environment, ESXi hosts become unresponsive with hostd failing or hanging when NFC operations such as backup or replication jobs are executed on disks with an IO filter attached. This issue is resolved in vSphere ESXi 7.0 U3l (build number 21424296).

  Workaround: Ensure that your protected site is running vSphere ESXi 7.0 U3l (build number 21424296) or above.

• VMware Live Recovery Global Console notifications not listed in chronological order

  In the VMware Live Recovery Global Console, sometimes 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.

• The VMware Live Recovery agent is slow to establish connection to vSphere Replication

  If you deploy vSphere Replication to a vCenter Server after the Site Recovery Manager instances were paired and connected to VMware Live Recovery, the VMware Live Recovery might not be applied immediately to vSphere Replication.

  Workaround: Wait for at least 7 minutes before activating VMware Live Recovery.

• Subscription activation can take up to 6 hours to appear in the VMware Live Recovery Global Console

  Even though subscriptions are activated upon delivery of the invite link to users in their welcome email, it can take up to 6 hours after activation for the VMware Live Recovery subscriptions to become available in Global Console.

• Disconnecting VMware Live Site Recovery from the cloud does not remove the entry from the Live Site Recovery UI

  When you disconnect VMware Live Site Recovery from the cloud, the Live Site Recovery user interface still shows active cloud connection. You must use the Live Site Recovery Appliance Management UI to check the connection status.

  None.

• If you are using vSphere Replication with a VMware Live Recovery license and try to configure a replication without enhanced capabilities, you see an incorrect RPO in the Configure Replication wizard

  When you start configuring or reconfiguring a replication without enhanced replication capabilities and you are running vSphere Replication with a VMware Live Recovery license, the RPO slider starts at 1 minute. While the minimum RPO for vSphere Replication with a VMware Live Recovery is 1 minute, the minimum RPO for replications without enhanced capabilities is 5 minutes.

  Workaround: Adjust the RPO slider to a minimum of 5 minutes.

• vSphere Replication issues for VMware Live Site Recovery degraded and suspended modes remain after returning to operational mode

  You entered VMware Live Site Recovery degraded or suspended mode, returned to operational mode and the vSphere Replication issues remain. The problem is observed due to a delay in clearing the issues.

  Workaround: Wait one hour or restart the vSphere Replication Management server.

• VMware Live Cyber Recovery - IP addresses being blocked when PCI DSS is enabled

  If you enable PCI DSS in your environment, VMware Live Cyber Recovery access lists will also be enabled, even if you do not select to enable it, which will block any IP address not added to the list. Importantly, in this situation you will not be able to use VMware Live Cyber connectors or the VMware Live Cyber Recovery UI.

  Workaround: Make sure that you add all relevant IP addresses for VMware Live Cyber Recovery components to you VMware Live Cyber Recovery access lists, and ensure that all management access IP addresses are configured prior to enabling PCI DSS.

• Unable to access VMware Live Cyber Recovery after upgrade, flickering UI

  In some cases after users upgrade to this release, the user sees a flickering VMware Live Cyber Recovery dashboard for a moment and then a broken login page. 

  Workaround: If you encounter this error after your VMware Live Cyber Recovery upgrade, contact VMware support for assistance. 

• VMware Live Cyber Recovery failback issues for committed plans that were failed over prior to upgrade

  Users with recovery plans containing folder-based protection groups ,who committed those plans after failover, have experienced issues failing back those plan after upgrading to the 2 February 2024 release.

  Workaround: If you experience issues failing back recovery plans that were committed before the upgrade, contact VMware support.

• VMware Live Cyber Recovery failback incorrectly succeeded when VM disk slot IDs were changed after failover, resulting in unhealthy VMs.

  Currently, VMware Live Cyber Recovery does not support failback of a VM that has had its disk slot IDs changed (or any disk geometry changes) after failover while running on the recovery SDDC. In this situation, disk slot IDs were changed but the failback succeeded when it should have failed.

• NEW VMware Live Cyber Recovery - VMX file parameters “workingDir” and “sched.swap.dir” prevent VM power-on after failover

  Currently, if the following parameters “workingDir” and “sched.swap.dir” are present in a protected VM's VMX file, and then you attempt to failover that VM, the VM will not power on after failover.

  Workaround: Ensure that your protected VM VMX file does not have the paramaters “workingDir” and “sched.swap.dir”. If a VM is in this situation after failover, ensure the VMX file does not have the “workingDir” and “sched.swap.dir” parameters, take a new snapshot of the VM, use that snapshot in your recovery plan, and then retry failover.

• NEW VMware Live Cyber Recovery connector health shows as critical

  If your Cyber Recovery connector health shows as critical, and the connector is no longer working, it is possible that someone deleted the connector OAuth app used in VMware Cloud Services to allow inter-component communication.

  Workaround: If the Cyber Recovery connector OAuth app (named 'VCDR connector server-to-server OAuth app') is deleted from your organization, contact VMware Support for assistance.

• NEW VMware Live Cyber Recovery: SDDC groups that have no member SDDCs do not appear in the Private Network Connection dialog box.

  When configuring a private connection in VMware Live Cyber Recovery, any SDDC groups that do not contain any SDDC members will not appear in the Private network connection dialog box.

  Workaround: Add your protected SDDCs to an SDDC group. Once the SDDC is fully connected to the SDDC group, the group will appear in the Private network connection dialog box.

• NEW VMware Live Cyber Recovery API token showing as valid, while Health reports missing roles

  In VMware Cloud Services console, an API token for VMware LIve Cyber Recovery can show as valid even if the Health reporting shows an error that the API token is missing one or more of the required roles (Protection Admin, Recovery SDDC Admin, Orchestrator Admin). If someone removes one of these roles from the API token, the token can still show as valid, even though Health reports an error with the token. 

• NEW VMware Live Cyber Recovery: When a script VM fails to execute during failover, script changes are not undone during rollback

  In VMware Live Cyber Recovery, during a failover of a recovery plan with a script VM configured, if the script fails for some reason on a VM, when you attempt to roll back the failover, that script is never called for that VM. The script should be called with "--rollback" but is not.  

• VMware Live Cyber Recovery failover terminated after membership change leaves protection group in bad state

  During the failover of a VMware Live Cyber Recovery recovery 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.

• VMware Live Cyber Recovery protection groups with empty folders must be mapped properly in a recovery plan, or a failover will fail

  In VMware Live Cyber Recovery, 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 recovery plan, or else that plan fails to complete during a failover.

• After failover in VMware Live Cyber Recovery, do not deactivate change block tracking (CBT) on any VMs on the SDDC

  Changing CBT on VMs in your SDDC prevents the VM from being failed back in a timely manner with VMware Live Cyber 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 VM snapshot on the SDDC, and do not change CBT settings for any VMs.

• VMs created on virtual hardware version 20 not supported in VMware Live Cyber Recovery

  In VMware Live Cyber Recovery, VMs created on virtual hardware version 20 are not supported for failover or failback.

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

• In VMware Live Cyber Recovery recovery plans, some special characters not supported in vSphere inventory object names

  VMware Live Cyber Recovery does not support the following non-ASCII 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.

• In VMware Live Cyber Recovery, unable to set default data store for a failback recovery plan when a mapped host is not part of a cluster

  In VMware Live Cyber Recovery, if a mapped compute resource (such as a host) in a failback recovery plan is not part of a cluster on an on-premises 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.

• VMware Live Cyber Recovery failover in a large scale environment failed with errors during VM power-on

  In some cases, a VMware Live Cyber Recovery failover was failing during recovery or while recovered VMs were being powered-on.

  Workaround: Retry the failover operation.

• Re-adding a removed VMware Live Cyber Recovery connector not supported

  If you remove a VMware Live Cyber Recovery connector from a protected site, you cannot re-add the connector to a different protected site.

  Workaround: Re-deploy a new Cyber Recovery connector to replace it.

• A VMware Live Cyber Recovery 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

  In VMware Live Cyber Recovery, 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 recovery 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.

• vSphere warning during VMware Live Cyber Recovery connector deployment

  When deploying the VMware Live Cyber Recovery 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 Live Cyber Recovery to distinguish connector VMs from customer VMs.

  Workaround: You can ignore this message and safely deploy the Cyber Recovery connector in your vSphere environment.

• Two-host Recovery SDDC deployments in VMware Live Cyber Recovery not supported with VMware Cloud SDDC software version 1.15

  In VMware Live Cyber Recovery, you cannot deploy a 2-host Recovery SDDC for a VMware Cloud SDDC running software version 1.15.

• VMware Live Cyber Recovery connector offline and inoperable after being powered off more than two weeks

  If you power off a VMware Live Cyber Recovery connector for more than 2 weeks, it will show as offline and potentially stop functioning.

  Workaround: If your Cyber Recovery 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.

• Delete Recovery SDDC Error in VMware Live Cyber Recovery

  In some instances when a user deletes a Recovery SDDC in VMware Live Cyber Recovery, an error sometimes displays, even if the deletion was successful.

  Workaround: If you see this behavior, please contact VMware support to confirm that the Recovery SDDC was deleted successfully.

• VMware Live Cyber Recovery connector cannot reach vCenter/ESXi on 172.17.x.x

  The VMware Live Cyber Recovery 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 Cyber Recovery Connector cannot connect to it.

  Workaround: Contact VMware Support if you need the Cyber Recovery Connector to connect to a private network within this address.

• VMware Live Cyber Recovery high-frequency snapshot task terminated due to vMotion issue

  In some cases during a VMware Live Cyber Recovery 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.

• When an ESXI host in maintenance mode, it can interfere with VMware Live Cyber Recovery high-frequency snapshots and VM recovery

  For vCenter clusters enabled for VMware Live Cyber Recovery high-frequency snapshots, if the ESXi hosts in the cluster are in maintenance mode, it is possible that snapshot replication and failover/restore operations could fail.

  Workround: Before you begin snapshot replication and perform any failover or restore operations in a high-frequency snapshot cluster, move any VMs that running on hosts in maintenance mode out of the protected site vCenter cluster. These VMs can be moved back into the cluster when the hosts are out of maintenance mode.

• Benign VMware Live Cyber Recovery replication errors on protected site vCenter

  During some VMware Live Cyber Recovery snapshot replication jobs, vCenter on the protected site might display errors or failures related to replication, but there is actually nothing wrong with the replication. For example, you might see errors with "LWD" in the name, such as "Perform LWD-based snapshot sync | Cannot complete the operation. See the event log for details. Failed to transport." even though the job completed successfully in VMware Live Cyber Recovery.

  Workaround: It is safe to ignore such errors in the vCenter UI. As a best practice, you should use the UI to view replication-related errors, rather than the vCenter UI.

• Default Windows ZIP utility not unpacking guest file restore downloads in VMware Live Cyber Recovery

  In VMware Live Cyber Recovery, 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 VMware Live Cyber Recovery guest file restore operations.

• VMware Live Cyber Recovery protection group size displays incorrectly after failback

  Protection group size in VMware Live Cyber Recovery might display inaccurately immediately after a failback, until the next snapshot for that protection group is taken.

• Multi-factor Authentication (MFA) for API tokens not supported with VMware Live Cyber Recovery

  Currently, you cannot enable MFA in your organization, and you should not generate a VMware Cloud Services API token if MFA is enabled. This limitation applies only to MFA for API tokens (My account > API Tokens), and does not apply to your organization authentication policy (Organization > Authentication Policy > Multi-Factor Authentication) or your VMware Cloud user account (My account > Security).

  Workaround: Do not enable MFA for API tokens in your VMware Live Recovery organization.

• VMware Live Cyber Recovery failback failed with error "unable to locate VM Configuration information"

  In some cases a VMware Live Cyber Recovery failback operation failed due to some of the VMs being in an invalid state.

  Workaround: Open vCenter on the Recovery SDDC and fix VMs that are in an invalid state. Then, retry the failback operation. A VM can be invalid due to several reasons, such as removed data store, a missing or corrupted VMX file, or other potential reasons. As a last resort, you can delete and rebuild the VM.

• Multi-region deployments of VMware Live Cyber Recovery currently do not support Security and Compliance Access lists and guest file recovery

  If you have a multi-region VMware Live Cyber Recovery deployment, Security and Compliance Access lists and guest file recovery will work for the first recovery region you activate, but these features will not work in any subsequently deployed regions.

• VMware Live Cyber Recovery might send benign 'Host cannot perform I/O' events

  VMware Live Cyber Recovery might infrequently send benign 'Host cannot perform I/O' events when there are no workloads running on the cloud file system. These messages can be ignored. In a future release, we will suppress these events.

• VMware Cloud Services "Global Console Admin" user role is not applied to the Managed Service Provider (MSP) user for VMware Live Cyber Recovery

  The VMware Cloud Services user role named "Global Console Admin", which is needed to view and create subscriptions for VMware Live Cyber Recovery, is currently not applied to the MSP user. However, the "Global Console Admin" role can be applied to the MSP tenant user, so that the MSP tenant user can view and create subscriptions.

• OAuth app limit can prevent Cyber Recovery connector deployment for VMware Live Cyber Recovery

  Each time you deploy a Cyber Recovery connector, VMware Live Cyber Recovery also adds an OAuth app to your organization. Over time, your organization might reach its 200 maximum limit of OAuth apps, which can cause connector deployment to fail.

  Workaround: In the VMware Cloud Services console, delete older VMware Live Cyber Recovery OAuth apps. You can delete all OAuth apps except the most recent one.

• Running a VMware Live Cyber Recovery recovery plan might hang in the rare instance that it conflicts with a background space reclamation process.

  In some rare cases, running a VMware Live Cyber Recovery recovery plan might stall during the initial 'prepare cloud storage resources' stage, if this process occurs at the same time as a background space reclamation process. If you notice that running a recovery plan (either failover or failback) stalls in the first step, and if you notice that the cloud file system shows red in the Topology map, this means it is likely the plan has stalled and should be stopped.

  Workaround: Stop the recovery plan and try running it again.

• In VMware Live Cyber Recovery, performing repeated failback operations with the same snapshot triggers a non-incremental, full restore

  When you use the same snapshot for repeated failback or restore operations, it can trigger a longer, non-incremental restore. This issue occurs with both high-frequency snapshots (HFS) and standard-frequency snapshots (SFS). A full restore transfers the entirety of the VM contents from cloud snapshots, while an incremental restore only transfers the blocks which are different from the target snapshot. Incremental restore is more rapid, and preferred where possible, but some scenarios make a full restore required.

  Workaround: For information on how to avoid this situation, see here.

• VMware Live Cyber Recovery region selector incorrectly allows users to switch to a VMware Cloud Flex Storage region (if both services are in the same organization)

  For VMware Cloud organizations that have both VMware Live Cyber Recovery and VMware Cloud Flex Storage deployed, the VMware Live Cyber Recovery recovery region switcher incorrectly shows regions where VMware Cloud Flex Storage is deployed. If you attempt to switch a VMware Live Cyber Recovery recovery region to a VMware Cloud Flex Storage storage region, it fails.

  Workaround: Do not switch VMware Live Cyber Recovery region to a VMware Cloud Flex Storage region.

• Minor issues when using VMware Live Cyber Recovery ransomware recovery on the VMware Cloud Partner Navigator program

  If you are using VMware Live Cyber Recovery ransomware recovery on the VMware Cloud Partner Navigator, you will not see the Carbon Black Cloud service tile in your organization, and you are not able to launch the Carbon Black Cloud security console from the VMware Live Cyber Recovery UI. However, while threat alert investigation is not possible in the security console, detailed threat information is available in the VMware Cloud DR UI.

• VMware Live Cyber Recovery snapshot storage optimization sometimes results in higher capacity usage on the cloud file system

  In some situations, the way VMware Live Cyber Recovery optimizes snapshot storage can sometimes result in higher capacity usage on the cloud file system.

• VMware Live Cyber Recovery subscription prices not showing discounted rate.

  When creating a subscription for VMware Live Cyber Recovery in the Global Console, the prices and total amount being shown while creating the subscription do not represent any discounts that have been applied to the subscription. This issue only affects the display of the subscription prices, and when the purchase is completed and invoiced, the correct discounted rate is applied.

• After being upgraded to the VMware Live Cyber Recovery (VMware Cloud DR) July 2023 release, Cyber Recovery connector deployment fails

  For existing users, after being upgraded to the VMware Cloud DR July 2023 release, deploying the Cyber Recovery connector failed with the following error: "Failed to deploy OVF package. ThrowableProxy.cause A general system error occurred: Transfer failed.

  Workaround:

  Download the Cyber Recovery Connector OVA to your local site using something such as:

  wget https://vcdr-xx-xxx-xxx-xx.app.vcdr.vmware.com:443/protect/vmware-cloud-connector.ova

  Then, from the location where the OVA was downloaded, deploy the OVF in vCenter selecting the 'local file' option.

• For VMware Live Cyber Recovery high-frequency snapshots, unable to vMotion VMs to different cluster and storage

  In VMware Live Cyber Recovery, if you have a protection group taking high-frequency snapshots on a protected SDDC running vSphere with Distributed Resource Scheduler (DRS), and then you attempt to Cross-vCenter vMotion one of those VMs to another cluster with DRS, the operation might not complete.

  Workaround: Either detach the high-frequency snapshot from the VM before you attempt to Cross-vCenter vMotion, or Cross-vCenter vMotion the VM to a specific host in the cluster (rather than just the cluster).

• In VMware Live Cyber Recovery, failback failure for multiple VMs being protected by high-frequency snapshots

  During a VMware Live Cyber Recovery failback, multiple VMs with high-frequency snapshots failed during VM recovery on the protected site, which caused VM failback to fail. Error message displayed:  fairly characteristic error would be this:

  "Failed to restore VM ([vsan-datastore] XxXxXx-32xx-15b1-1xxx-ecfx4xxxbd2ec/win10-36.vmx) (win10-36): VM restore failed. Internal error: DPS no-op sync failed"

  This was caused by exceeding the limit of 100 VMs being protected by high-frequency snapshots on a protected site. 

  Workaround: Do not exceed the limit of protecting more than 100 VMs per host with high-frequency snapshots. For more information, see the VMware Live Cyber Recovery Configuration Maximums.

• In VMware Live Cyber Recovery, using app-info collection with VMware Tools causing replication failures

  If you have enabled guest OS app-info collection using VMware Tools, this can result in app-info data getting stored in the VMX file, causing it to grow to a size >55KB. Because VMware Live Cyber Recovery does not allow backup of VMX files that are >55KB, snapshot replication can fail.

  Workaround: Disable app-info collection in VMware Tools.

• In VMware Live Cyber Recovery, failure to attach tags on some VMs during recovery

  In some circumstances, VMware Live Cyber Recovery may fail to attach tags to a subset of recovered VMs. If the tags are already attached to the VMs on the protected site before failback is performed, these tags will NOT be deleted.

  Workaround: The missing tags will need to manually be attached to the VMs.

• In VMware Live Cyber Recovery, I/O disruptions on cloud file system in the the Bahrain, Zurich, and Melbourne AWS regions

  VMware live Cyber Recovery might experience I/O disruptions on the cloud file system up to 3 minutes long that could lead to I/O timeouts for some VMs if your recovery region is activated in the Bahrain, Zurich or Melbourne AWS regions. This issue can occur during product upgrades or when handling backend component failures.

  Workaround: Do not use the Run VMs live on the cloud file system if your recovery region is activated in the Bahrain, Zurich and Melbourne AWS regions. Use the "Full storage migration to recovery SDDC" option for the VM Storage setting when you run a failover or failover test.

• In VMware Live Cyber Recovery, using different management CIDRs for recovery SDDCs attached to two separate cloud file systems not supported

  You cannot use different management CIDRs for recovery SDDCs attached to two separate cloud file systems.

  Workaround: If you are deploying recovery SDDCs for two separate cloud file systems, both SDDCs must share the same management CIDR.

Related Release Notes

To view related release notes, see:

• VMware Cloud DR Release Notes (now called VMware Live Cyber Recovery). Historical archive of VMware Cloud DR release notes.

• VMware Site Recovery Manager Release Notes. Current Site Recovery Manager add-on release notes.

  • VMware Aria Automation Orchestrator Plug-In for VMware Site Recovery Manager 9.0 Release Notes

  • VMware Aria Operations Management Pack for VMware Site Recovery Manager 9.0 Release Notes

• VMware VSphere Replication Release Notes. Current release notes for VMware vSphere Replication.

  • VMware Aria Automation Orchestrator Plug-In for vSphere Replication 9.0 Release Notes

  • VMware Aria Operations Management Pack for vSphere Replication 9.0 Release Notes