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

Known Issues

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

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

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

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

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

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

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

  • 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