If you are using Site Recovery Manager as a business continuity and disaster recovery solution for your vSphere resources, you can configure VMware Aria Automation to continue to manage the resources even if they are moved by SRM to a secondary location.

Workload mobility is currently supported for resources deployed on vSphere. The workload resources include virtual machines, disks, and VM network. Due to Site Recovery Manager limitations, first class disks are not included.

Workload mobility only works with SRM. If you relocate workloads using a non-SRM tool, VMware Aria Automation loses the ability to manage the resources regardless of the account site association and project workload mobility settings.

After resources fail over from the primary to the secondary site, the information about the resources on the secondary site are reconciled during data collection. The complete reconciliation process might take several collection cycles to complete. If errors are generated,

Before you begin

  • Ensure that the primary and secondary sites belong to the same project.
  • To understand how you can manage the resources after a failover, review the following considerations.
    Considerations Solutions
    After resources fail over from the primary to the secondary site, the information about the resources on the secondary site are reconciled during data collection. The complete reconciliation process might take several collection cycles to complete. If you encounter errors, you can review the SRM logs to identify the problem.
    Storage resources do not belong to a cloud zone after reconciliation on the new site. After failover, storage quotas might be inaccurate and the allocation of new disks might fail, depending on the new vCenter topology. None
    Some actions might not work on the secondary site if the policies are different from the primary site.

    For example, some tags might not exist on the new vCenter datastore and they are not reconciled when the resources are moved. If the resources are staying on the datastore on the secondary site, you must update the tags on the new vCenter to ensure ongoing compliance with your policies.

    An alternative solution is to mirror the sites, including the policies and tags.

    Most day 2 actions related to machines, disks, and VM networks are supported.

    The following day 2 actions are not supported on the secondary site.

    • Changing networks when you use the Update deployment action.

    Any action that consumes more resources, such as adding or resizing disks, are constrained by the available resources.
    First class disks are not supported due to Site Recovery Manager limitations. None
    If you do not reprotect the resources on the secondary site before you modify a resource as part of iterative development or general resource management, SRM generates an error and the resource is not moved when you fail back to the primary site.

    After failover, reprotect the resources on the secondary site to ensure that SRM is aware of the changes. Re-protecting ensures that the your resources can fail back to the primary site with minimal disruption.

    An alternative solution is to use an VMware Aria Automation Orchestrator plug-in that adds newly provisioned machines in Site Recovery Manager protection groups. The plug-in guide is available on the SRM documentation page.

    If iterative develop continues on the secondary site, any destroyed resources are not recoverable. If the move to the secondary site is temporary, consider halting any destructive actions until you fail back to the primary site.

Configure VMware Site Recovery Manager

Ensure that the resources managed by VMware Aria Automation are configured to support workload mobility. See the Site Recovery Manager documentation for more information.

  1. Identify your primary and secondary vCenter instances.
  2. Create a protection group for the resources.
  3. Create a recovery plan for the resources.

Associate the primary and secondary accounts in VMware Aria Automation

VMware Aria Automation must be aware of the alternative cloud accounts used by SRM for the protection group and recovery plan.

The alternative accounts must belong to the same project as primary account.

  1. In Automation Assembler, select Infrastructure > Connections > Cloud Accounts and ensure that the primary and the secondary cloud accounts are configured.
  2. Open the primary account and locate the Site Association section.
  3. Click Add and select the secondary cloud account.
  4. To support migrating back to the primary site, turn on the Bidirectional toggle.
  5. Click Save.