This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

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

19 September 2024

  • VMware Cloud Director Availability is now part of VMware Live Recovery. You now have a simplified method of purchasing and managing your VMware Cloud Director Availability licenses with VMware Live Recovery. After purchasing VMware Cloud Director Availability 4.7.3 from a VMware Live Recovery SKU, you can download both the software and a license key for VMware Cloud Director Availability from the Broadcom Support portal, and then apply the license to your deployment. This purchasing and licensing capability is supported for VMware Cloud Director Availability 4.7.3.

16 September 2024

  • VMware Live Cyber Recovery’s ransomware recovery solution changing identity providers for the Carbon Black integration. VMware Live Cyber Recovery will begin authenticating with Carbon Black using Carbon Black’s native identity provider. There is no change to the Carbon Black integration, so you can continue enjoying enterprise-class, embedded threat analysis within the ransomware recovery workflow.  New users who want to access the Carbon Black Cloud console are required to create a Carbon Black account.  See VMware Live Cyber Recovery documentation for more details on account creation.

  • Upgrade notes for this release:

    • For existing users who have activated integrated ransomware recovery services with Carbon Black, no action is required. This upgrade automatically converts your Carbon Black configuration to use the new identity service.

      Note: Any newly created policies or edits to existing policies in Carbon Black will need to be reapplied after the upgrade is complete.

    • For new ransomware recovery users who want to use integrated ransomware recovery services with Carbon Black, but have not yet configured the Carbon Black integration, ransomware services will be temporarily disabled while your VMware Live Cyber Recovery version is upgraded to this release. Please contact technical support to request an accelerated upgrade.

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.

  • Virtual machine disk UUIDs preserved after failover and failback. VMware Live Cyber Recovery now preserves virtual machine disk UUIDs after failover to a recovery SDDC on VMware Cloud on AWS and then failback to a protected site.

  • 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:

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 (version 8.0 U3b required)

    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, unless you are running VMware ESXi 8.0 U3b.

    Note: Quiescing high-frequency snapshots is not supported for VMware Cloud on AWS protected SDDCs.

    Action: You should disable quiescing in all high-frequency snapshots in your VMware Live Cyber Recovery protection groups until you upgrade to VMware ESXi 8.0 U3b. If you do take a quiesced high-frequency snapshot and you aren't running VMware ESXi 8.0 U3b, then VMware Live Cyber Recovery will take a, non-quiesced snapshot.

  • 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.

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