Troubleshooting VCF Automation deployment mapping and SFTP backup failures after VMware Live Recovery reprotect operations

Products

• VCF Automation

Issue/Introduction

In VMware Cloud Foundation (VCF) environments using VMware Live Recovery (LVR) for disaster recovery, you may observe the following symptoms following failover and reprotect operations:

• Deployments in VCF Automation incorrectly map to placeholder virtual machine (VM) stubs at the source site rather than the recovered, operational VM.

• Add Disk operations on placeholder stubs fail due to missing SCSI controller mappings, resulting in orphaned disk objects.

• Deployment loss occurs when you create new deployments to rectify mapping issues.

• Configuring an SFTP Backup Target for VCF Automation from VCF Fleet Management fails at the Synthetic Check stage.

• The following error appears in the platform snapshots:

  Error Code: LCMVMSP10035
  Synthetic checker on the application platform failed.
  Synthetic check failed. Please refer to Broadcom Knowledge Base Article
  https://knowledge.broadcom.com/external/article/389510 for
  remediation details.,"platform-snapshots : unable to find VM: ServerFaultCode: The object 'vim.VirtualMachine:vm-<ID>' has already been deleted or has not been completely created"

Environment

• VCF Automation 9.1

• VCF Operations 9.x

• VMware Live Recovery (LVR) 9.0.x

Cause

This issue occurs due to an unsupported integration of VCF Automation with VMware Live Recovery. During a failover, LVR preserves the VM configuration, MAC address, and GUID, but it does not preserve the Managed Object ID (MOID). Because VCF Automation and vIDB components rely on the MOID, they are incompatible with LVR replication, which leads to a VM MOID mismatch within the vmsp-platform component.

Additionally, a race condition exists within the VCF Automation inventory collection. If the LVR Reprotect operation replaces the original powered-off VM with a placeholder stub (which generates a new UUID) before a full inventory collection cycle completes, the system fails to reliably detect the workload migration to the recovery site.

Resolution

For disaster recovery of VCF Automation, the supported architectural design requires deploying a new instance on the recovery site and restoring it from a known good backup, rather than using VMware Live Recovery replication.

This issue is under review with Broadcom Engineering.

Workarounds:

To maintain deployment consistency and mitigate orphaned objects, perform the following steps:

1. Wait for an Inventory Cycle: After a failover event, wait at least 25–30 minutes before initiating the Reprotect operation to allow a full inventory collection cycle to complete across both sites.

2. Trigger a Manual Inventory Sync: If necessary, manually trigger an inventory data collection for the impacted Cloud Accounts in VCF Automation immediately after the failover.

3. Validate Mappings: Ensure Folder and Resource Mappings in the LVR Site Pair are explicit, as stale or missing nested folder mappings can delay placeholder creation.

4. Remediate Orphaned Objects: If an action such as adding a disk was previously attempted against a placeholder stub, manually remove the resulting orphaned disk objects from the datastore.

5. Site Association: For persistent deployment update issues, utilize Site Association. Note that this may require tearing down the All Apps organization to enable the link.

6. MOID Patching: To resolve the VM MOID mismatch within vmsp-platform preventing SFTP backups, open a support ticket with Broadcom referencing KB article 424785 to patch the VCF Automation VM MOID.

Additional Information

• Customers experiencing this issue are encouraged to subscribe to this article to receive updates regarding the permanent fix. How to subscribe to Knowledge Base articles