You can view a history of VMware Live Cyber Recovery resolved issues here.
| Title | Description |
|---|---|
| Fixed: Failback operation failure with internal error |
In one user environment, running a failback operation failed with an internal error for multiple VMs in a recovery plan. This has been fixed. |
| Fixed: DRaaS Connector deployment failed on Photon OS |
DRaaS Connector deployment failed on Photon OS due to some Docker networking issue (docker bridge network 172.17.0.0 in their DNS network). This has been fixed. |
| Fixed: Automatic firewall configuration fails on a protected VMware Cloud on AWS SDDC that has no default network created |
Previously, when setting up a protected site for a VMware Cloud on AWS SDDC, and chose to have network firewall rules created automatically, it was possible that the SDDC did not have a default network created yet, which caused the protected site set up to fail. This has been fixed. |
| Fixed: Conflicts if using 172.17.0.1/16 address range |
VMware Cloud ServicesVMware Cloud Services uses 172.17.0.1/16 for its Docker Engine default bridge network. Previously, if your protected site networking environment used this IP address range, you could have had issues connecting to vCenter and ESXi, and potentially fail to register the DRaaS Connector. This has been fixed. |
| Fixed: Number of VMs that can concurrently have their IP address customized during failover |
Previously, the maximum number of VMs that could concurrently have their IP addresses changed during failover operations was only 2. Now, up to 18 VMs can concurrently have their IP addresses changed during failover. |
| Fixed: Non-incremental restore required when performing multiple recovery operations on same VM |
When you performed a failback from a snapshot (or a single VM restore), and then performed a subsequent failback from a snapshot that existed at time of the first failback, VMware Live Cyber Recovery required a longer, non-incremental restore to complete the failback. This has been fixed and the non-incremental restore is no longer required in this scenario. |
| Fixed: Direct Connect AZ Limitation |
Previously, Direct Connect was only supported for protected sites which are using a cloud file system that resides in the same Availability Zone (AZ) where the VMware Live Cyber Recovery orchestrator is deployed. This has been fixed and now you can use Direct Connect for protected sites that reside in a different AWS region than where VMware Live Cyber Recovery is deployed. |
| Fixed: Multiple snapshots missing VMs |
In one environment, some snapshots were missing VMs, due to an ESXi host being disconnected and unreachable, preventing successful snapshot replication for some VMs. This has been fixed. |
| Fixed: Compliance check warnings about VM tags not defined in protection group |
Some users were seeing a recovery plan compliance check warning when some protected VMs had tags that are not part of the protection group tag query. This check has been removed. |
| Fixed: Unable to change network isolation during ransomware recovery |
When a customer tried to run a recovery plan for ransomware without integrated analysis enabled, they were unable to change network isolation levels. This has been fixed. |
| Fixed: Snapshot job failures |
Some snapshot jobs were failing with a "VDDKInteral Error: VM endAccess failed VixDiskLib_EndAccess failed. Internal error: Unknown error [1]". This has been fixed. |
| Fixed: Snapshot job queue backed up |
In one situation, snapshot jobs were backing up and being delayed due to duplicate VMs belonging to multiple protection groups. This has been fixed. |
| Fixed: DRaaS Connector health switched from Good to Critical several times |
In one protected site, the DRaaS Connector health was switching back and forth between Good and Critical. This was due to some DNS servers that were unreachable, so the health check had to wait for a long time for the request to timeout, causing the issue. This has been fixed. |
| Fixed: Failed snapshot job |
In one environment, a snapshot job failed due to DNS issues on the customer protected site. This has been fixed. |
| Fixed: Recovery SDDC deletion failure |
In one situation, a user was unable to delete a recovery SDDC. This has been fixed. |
| Fixed: Compliance check failure |
In one customer environment, recovery plan compliance checks were failing due to an unresponsive backend service. This has been fixed. |
| Fixed: Failure to delete recovery SDDC |
In one situation, a user tried to delete a recovery SDDC but the operation failed. The user was then unable to delete an attached datastore because they could not unmount it from the SDDC. This has been fixed. |
| Fixed: Failure to attach an existing SDDC for recovery |
In one user instance, VMware Live Cyber Recovery failed to add an existing SDDC for recovery due to some overlapping network segments with stale firewall rules on VMware Cloud. This has been fixed. |
| VMs still appeared after deleting a protection group |
In one situation, when a user deleted a protection group, the VMs still appeared in the UI under the VMs list. This has been fixed. |
| Fixed: Compliance check failure |
Compliance check was failing for one recovery plan due to the timeout of a backend process. This has been fixed. |
| Fixed: Unable to deploy a recovery SDDC |
Unable to deploy recovery SDDC due to a failure to get a list of connected AWS accounts in the UI. This only happened if there were many of AWS accounts connected to the organization. This has been fixed. |
| Fixed: Ransomware recovery failed when network isolation level did not create successfully |
While running a recovery plan for ransomware recovery, the network isolation level specified in the plan failed to get created by the system, causing the plan to fail. This has been fixed. |
| Fixed: Error when multiple users sent support bundles at the same time |
An unknown error occurred when multiple users sent support bundles simultaneously. This has been fixed. |
| Fixed: Recovery plan incorrectly marked with critical health compliance check |
In one situation, VMware Live Cyber Recovery failed to schedule the next check of the health monitor, so the health of a recovery plan was changed to critical. This has been fixed. |
| Fixed: API token expiration message hidden |
Previously, an API token expiration was not easy to find under the Monitoring → Events tab. Now, an API Token Expiration notification is part of the SLA Status page. |
| Fixed: Cloud file system filling up caused connector download failure |
In some situations, the cloud file system was filling up due to unused software images, causing the DRaaS Connector download to fail. This has been fixed. |
| Fixed: Degraded disk read performance for some VM workloads |
On an earlier version of VMware Live Cyber Recovery, some Windows workloads showed degraded disk read performance. This has been fixed. |
| Fixed: Double billing error |
Double billing occurred when the billing file was overwritten as background processes were reset on upgrades. This has been fixed. |
| Fixed: API token registration failed |
An API Token could not be registered due to changes in the Organization name used for the deployment. This has been fixed. |
| Fixed: First time ingest while running recovery plan failed after 12 hours |
Running a test recovery plan on a first time ingest failed after 12 hours. This has been fixed. |
| Fixed: Failure to display protection group list |
Previously, the VMware Live Cyber Recovery UI failed to display a recovery plan's protection groups list, taking longer than usual to retrieve the information. This has been fixed. |
