Compliance checks scan recovery plans to verify and validate all configurations and mappings between a protected site and a recovery SDDC.
Each recovery plan provides continuous compliance checks to ensure that all plan configurations and mappings are valid before you run a plan. Compliance checks run regularly every 30 minutes.
Compliance checks also make sure that the specified protection groups are live on the protected site and are replicating successfully to the target recovery SDDC. A plan can become out of compliance if any of its conditions become violated because of environmental or plan configuration changes.
Failing compliance checks transition a recovery plan into a degraded health state of warning or critical. When a plan fails a compliance check, an email is sent to the recipients configured in the VMware Live Cyber Recovery settings. Health checks run on a per-plan basis. Some plans can have an OK health status, while others can be in degraded states at the same time.
As a recovery plan is created, tested for compliance, and run, VMware Live Cyber Recovery maintains detailed logs of all the actions that were performed, the plans that were completed, and the compliance checks on those plans. You can generate and download these reports as a PDF or have them emailed on an automated schedule.
Compliance state for a plan does not restrict failover or test operations. Even if a plan is non-compliant in some areas, you can still run as a failover or test failover plan.
To view plan compliance, click the Show button. To run the compliance report on demand, click the small refresh button at upper-right of the Continuous compliance box.
You can view the Compliance column in the list of recovery plans to quickly identify plans that are out of compliance:
Recovery plan compliance reports check for the following configurations and mappings:
Protected Site
Connection to source site |
Checks the presence and availability of all source vCenters referenced in the plan and checks connectivity of the vCenter. |
Replication health |
Checks the relationship between source and destination replication to make sure replication is possible. |
Datastores exist on source site |
Checks for the existence and health of all source datastores defined in the plan. Datastore capacity is checked as part of snapshot replication health. |
Protection group replication schedule |
Checks the snapshot retention for protection groups referenced by the plan. If snapshot retention for protection groups in the plan is less than 90 days, this item is flagged. If you are using the Fast Restore Using VMware vSAN Local Snapshots feature, we recommend that vSAN protection groups have snapshot schedules configured with a retention policy that matches that of the protection groups in VMware Live Cyber Recovery. |
Networks exist on source site |
Checks the existence of all source DNS servers and gateways listed in plan. |
Resource pools exist on source site |
Checks the existence of all source resource pools listed in the plan. If a cluster resource pool is mapped for either source or destination, the compliance check ensures that the Distributed Resource Scheduler (DRS) is activated. |
Folders exist on source site |
Checks for the existence of all source folders listed in the plan. |
Protection groups are healthy |
Each recovery plan compliance verifies the existence and live status of protection groups referenced by the plan on the source site. Recovery plan compliance checks indicate if any VMs in the snapshot were not snapshotted, according to the protection group configuration. For example, if you configure a protection group to quiesce all VMs before taking a snapshot, and some VMs were not quiesced, then the recovery plan compliance report indicates the mismatch.
Protection group health compliance is also evaluated by these factors:
|
Snapshot parity | Checks to make sure that at least one snapshot exists for every VM referenced in the plan. |
Clusters exist in source site and cluster name |
Checks if all clusters referenced in the plan exist on the destination site, and checks to verify the name of the cluster as configured in the plan. If the cluster name changes or is deleted, then the plan is out of compliance. To be compliant, the name in the plan must match both the source and destination cluster name. |
Recovery Site
Connection to failover site |
Checks to ensure that there is network connectivity to the recovery site (a recovery SDDC), and checks connectivity to all destination vCenters referenced in the plan..
If you delete a recovery SDDC, then all compliance checks for that deleted SDDC are skipped. The plan compliance check will be healthy, but the plan cannot be run until the new recovery SDDC is added. Without having a recovery SDDC in place, a positive compliance report does not indicate DR readiness. It only means that the source site and protection group configuration is healthy. In order to ensure full compliance and DR readiness, you must deploy and fully configure all resources in an on-demand recovery SDDC and run a new compliance report to confirm DR readiness. |
vCenter server registered in failover site |
Checks to ensure that the vCenter server on the recovery SDDC is registered with VMware Live Cyber Recovery. The compliance check also verifies all vCenter authentication access and version compatibility, to make sure that source and destination vCenters are both accessible and version-compatible. Additionally, the compliance check ensures that a sufficient number of network ports are available in the vSwitch. |
Datastores exist on failover site |
Checks for the existence and health of all destination datastores defined in the plan. Datastore capacity is checked as part of snapshot replication health. Also checks that ds01 datastore is in a healthy state by checking for its existence, its maintenance mode status, free space statistics, and mounting and accessibility from hosts. |
Protection groups can be recovered in failover site |
Checks to ensure that all protection groups listed in the plan can successfully be failed over. Also ensures that at least one snapshot exists for every VM referenced in the plan. |
Networks exist on failover site |
Checks the existence of all destination DNS servers and gateways listed in plan. If you have defined IP address mappings, compliance checks report the presence of VMs without vSphere tools installed as warnings. |
Resource pools exist on failover site |
Checks the existence of all destination resource pools listed in the plan. If a cluster resource pool is mapped for either source or destination, the compliance check ensures that the Distributed Resource Scheduler (DRS) is activated. |
Folders exist on recovery site |
Checks for the existence of all destination folders listed in the plan. |
Tags in protection group queries exist in recovery vCenter |
Checks to ensure that any vSphere tags and tag categories associated with your protected VMs also exist on the destination recovery SDDC. |
Clusters exist in recovery site and cluster name |
Checks if all clusters referenced in the plan exist on the destination site and checks to verify the name of the cluster as configured in the plan. If the cluster name changes or is deleted, then the plan is out of compliance. To be compliant, the name in the plan must match both the source and destination cluster name. |
VMs can be restored in recovery vCenter |
Checks to ensure that there are sufficient snapshots that can be used to recover VMs in the plan.
For all VMs referenced in the plan, the compliance check also verifies:
|
Orchestration
IP address mapping |
If you have defined IP address mappings in a plan, compliance checks report the presence of VMs without vSphere tools installed as warnings. |
Recovery steps |
This compliance check ensures that all recovery steps can be run successfully without interference with other recovery steps. For example, it checks to determine if a named VM in a recovery step plan is actually in the protection group and can be recovered, and checks if elements and resources and items required to perform the steps can be found. |
Script server recovered before script actions |
Checks that the script server is configured to be recovered before any scripts are launched. This compliance check also verifies the user-supplied credentials required to run any custom scripts specified in the plan. |
Ransomware Recovery
Item | Compliance Check Description |
---|---|
VMware Tools |
Checks to see if the correct version of VMware Tools (11.2) is installed on the VM. If VMware Tools is missing or at a lower version, this item is flagged. |
Carbon Black integration status |
Checks the connection to Carbon Black Cloud Integrated security and vulnerability analysis. If VMware Live Cyber Recovery cannot connect with Carbon Black Cloud, then this item is flagged. |
Carbon Black workload appliance health |
Checks the health of the Carbon Black Cloud workload appliance. |
Protection group snapshot retention |
Checks the snapshot retention for protection groups referenced by the plan. If snapshot retention for protection groups in the plan is less than 90 days, this item is flagged. |
Other Checks
VMC site health |
Checks that VMware Cloud on AWS is healthy and reachable |
VMC refresh token validity |
Checks that the refresh token used for CLI operations is valid. |