Virtual machines recovered in VLCR may fail to boot due to inconsistent LVM metadata

Products

• VMware Live Recovery

Issue/Introduction

• Booting the RHEL virtual machines on the recovery site may fails after a sucessull failover using VLCR.
• In some cases, you may see missing volume group part of LVM within OS on the recovery site after failover.
• The Guest OS may boot to emergency mode after recovery. 
• The RHEL VMs with LVM were either cloned or deployed from a same template. 
• Windows machines which uses LDM configuration may also be affected. 

Environment

VMware Live Cyber Recovery 7.27.x

Cause

Linux/Windows VMs configured with LVM are cloned or deployed from the same template have identical LVM UUIDs. Any changes made to LVM disks (for example, adding a virtual disk to LVM) necessitates an update to the LVM metadata information. LVM tracks these updates using revision sequence numbers.

During VLCR backup, if both the source and the cloned VMs are backed up simultaneously using hot add, LVM revisions differ between the VMs being hot added. DR Connector assumes that the two VMs' disks are in the same LVM volume group and updates the LVM metadata automatically. If this LVM update occurs, the LVM metadata is inconsistent in the backup copy.

Resolution

This issue is fixed in VLCR version 7.27.5. 

If you are experiencing the above symptoms and cannot wait for the upgrade, please contact VMware by Broadcom support to implement the workaround and provide a time window of ~1 hour to complete the workflow.

Note: The workaound requires all the replication tasks to be stopped for all the protection groups, as the step involves rebooting the connector VM/s.