VMs are reported as managed by Site Recovery Manager (vPostgres Resolution)
search cancel

VMs are reported as managed by Site Recovery Manager (vPostgres Resolution)

book

Article ID: 343383

calendar_today

Updated On:

Products

VMware Live Recovery

Issue/Introduction

Symptoms:
  • After a failover and failback done previously, virtual machines in Production Site/Real virtual machines are reported as managed by VMware vCenter Site Recovery Manager (SRM)in the Summary tab.
     
  • When you click the virtual machine, you see this alert:

    This entity is managed by solution VMware vCenter Site Recovery Manager Extension. It is not recommended to modify it directly. Instead use the management console for the solution if you want to make changes.


Environment

VMware Site Recovery Manager 5.8.x
VMware Site Recovery Manager 5.5.x
VMware Site Recovery Manager 6.0.x
VMware Site Recovery Manager 6.1.x

Cause

Site Recovery Manager (SRM) uses the vm.config.managedBy property to claim certain virtual machines as placeholder virtual machines on the failover vCenter Server site. At the time of actual failover, these virtual machines become real (production) virtual machines.

To do this, SRM invokes a vm.reconfigure operation on the placeholder virtual machines to clean up the vm.config.managedByproperty. vCenter Server cleans up this property from its cache, but it is not cleared from the vCenter Server database table VPX_VM.

There are two properties that reflect the same value, vm.config.managedBy and vm.summary.config.managedBy, and the second property (vm.summary.config.managedBy) is not cleared from the VPX_VMtable.

If vCenter Server restarts for any reason or if there is a VM reconfiguration event (power ON/OFF), it reads the VPX_VM table and the vm.summary.config.managedBy property is populated with the old managedBy value, which incorrectly declares the real virtual machines as placeholder virtual machines.

Resolution

To resolve this issue:
  1. Manually identify and remove the managedBy tag from the virtual machines using the Power CLI script within the 2032366_ManagedBy_Power CLI script.zip folder attached with this article.
  2. Perform a manual cleanup of the incorrect entries in the vCenter Server database.
Identify and remove the managedBy tag from the virtual machines
To manually identify and remove themanagedBytag from the virtual machines:
  1. Install PowerCLI. To download PowerCLI, see the VMware vSphere PowerCLI page.
  2. Right-click PowerCLI and run as Administrator.
  3. Run this command:
Set-ExecutionPolicy -scope CurrentUser -ExecutionPolicy RemoteSigned
 
This allows the current user to run third-party signed scripts and cmdlets. Alternatively, you can omit the scope field and use-Unrestricted. However, this is less secure because anyone on that machine can run any cmdlet or script.
 
For more details, enter:
 
get-help Set-ExecutionPolicy -full
  1. Download the script attached to the Knowledge Base article VMs are reported as managed by Site Recovery Manager (2032366)and copy it to an accessible folder.
  2. Open a PowerCLI session and connect to the vCenter Server by running the Connect-VIServer command.
  3. Change directory to the folder where you saved theManagedBy.ps1script. To obtain an array of virtual machines, run the command:
$hmsVms = .\ManagedBy.ps1 -Cmd getVms -extKey "com.vmware.vcDr"
 
You can inspect the list, as well as add or delete virtual machines from the list.
  • To remove the managedBy reference from all the virtual machines in the list in $hmsVms, run the command:
.\ManagedBy.ps1 -Cmd Clear -VMs $hmsVms
 
  • To view the list of virtual machines, run this command:

$hmsVms
 
Note: Other available commands are:
  • help.\ManagedBy.ps1 -detailed:Displays detailed help.
  • getVMs: Gets the virtual machines managed by specific extension.
  • scanVMs: Returns a list of vCenter extension keys which manage some virtual machines.
  • clean: Removes the managedBy reference from the list of virtual machines.
  • set: Adds the managedBy reference.
Clean up incorrect entries in the vCenter Server Embedded database
 
Connect to vpostgres DB and perform these actions.
This script finds virtual machine IDs whose managed_by_ext_key and managed_by_ext_type fields are not in sync between the VPX_VM and VPX_VM_CONFIG_INFO tables:
 
select t1.ID, t1.MANAGED_BY_EXT_KEY, t1.MANAGED_BY_TYPE
from VPX_VM t1
inner join VPX_VM_CONFIG_INFO t2
on t1.ID = t2.ID
where t2.MANAGED_BY_EXT_KEY IS NULL and t1.MANAGED_BY_EXT_KEY IS NOT NULL
 
To obtain the number of affected virtual machines to cross-check against the output in step 5, run this query:
 
select COUNT(t1.ID)
from VPX_VM t1
inner join VPX_VM_CONFIG_INFO t2
on t1.ID = t2.ID
where t2.MANAGED_BY_EXT_KEY IS NULL and t1.MANAGED_BY_EXT_KEY IS NOT NULL
 
To sync the two fields with VPX_VM_CONFIG_INFO, update the VPX_VM table using this script:
 
update VPX_VM
set MANAGED_BY_EXT_KEY=t2.MANAGED_BY_EXT_KEY, MANAGED_BY_TYPE=t2.MANAGED_BY_TYPE
from VPX_VM t1
inner join VPX_VM_CONFIG_INFO t2
on t1.ID = t2.ID
where t2.MANAGED_BY_EXT_KEY IS NULL and t1.MANAGED_BY_EXT_KEY IS NOT NULL


Additional Information

Impact/Risks:
Ensure a back up of the database/ snapshot of vcenter is taken prior to performing the actions.