Replication Fails during Protection Group configuration due to unresolved devices.

Products

• VMware Live Recovery

Issue/Introduction

The SRM UI displays when attempting to configure protection on an existing Protection Group in VMware Site Recovery Manager (SRM) or Live Recovery, virtual machines that have been successfully configured for replication fail to  protect within the group.

The operation halts with the following DevicesNotResolved exception message related to inventory mapping due to baseline configuration tracking:

Unable to protect VM 'VM name' due to unresolved devices

Reviewing the lower-level environment log trace isolates the failure to a virtual network interface device signature (device key 4000)

 

-->    unresolvedDevice = (vim.vm.device.VirtualDevice) [
-->       (vim.vm.device.VirtualVmxnet3) {
-->          dynamicProperty = <unset>,
-->          key = 4000,
-->          deviceInfo = (vim.Description) {
-->             label = "Network adapter 1",

Environment

• VMware Cloud Foundation (VCF) 8.x

• VMware Site Recovery Manager (SRM) / Live Recovery 9.x

Cause

This issue is caused by a baseline configuration tracking inconsistency within the SRM/Live Recovery protection database.

When a virtual machine is introduced into a Protection Group, the site protection infrastructure executes a validation sweep to confirm that every hardware device has a designated resource mapping at the recovery site.

If the internal state database encounters an invalid or mismatched device signature check for the network interface, the validation engine drops the machine and registers a false-positive DevicesNotResolved exception.

Resolution

1. Log in to the vSphere Client managing the protected inventory.

2. Verify resource, folder, and network mappings at the recovery site before recreating the Protection Group.

3. From the main navigation menu, select Site Recovery and click Open Site Recovery.

4. Navigate to Protection Groups on the left inventory pane.

5. Rather than reconfiguring the failing policy, completely create a new Protection Group.

6. Move and assign the affected virtual machines directly into the newly created Protection Group.

7. Once protection status shows healthy across the workloads, safely remove and delete the old, inconsistent Protection Group.

Additional Information

For standard mapping troubleshooting, see Broadcom Support Knowledge Base Article 343304.