VMs are reported as managed by Site Recovery Manager

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 vCenter Site Recovery Manager 6.0.x
VMware vCenter Site Recovery Manager 5.8.x
VMware vCenter Site Recovery Manager 8.x
VMware vCenter Site Recovery Manager 5.1.x
VMware vCenter Site Recovery Manager 6.5.x
VMware vCenter Site Recovery Manager 5.5.x
VMware vCenter Site Recovery Manager 5.0.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.managedBy property. 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_VM table.
• 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 the managedBy tag 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

• Download the script (ManagedBy.ps1) attached to this article and copy it to an accessible folder.Open a PowerCLI session and connect to the vCenter Server by running the Connect-VIServer command. Change directory to the folder where you saved the ManagedBy.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 database

 

To manually clean up the incorrect entries in the vCenter Server database:

1. Stop the VMware vCenter Server Service.
2. Back up the vCenter Server database.
3. Using SQL Management Studio, run this script on the vCenter Server database:
    

   Note: 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 [VIM_VCDB].[dbo].[VPX_VM] t1
   inner join [VIM_VCDB].[dbo].[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

4. 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 [VIM_VCDB].[dbo].[VPX_VM] t1
   inner join [VIM_VCDB].[dbo].[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

5. To sync the two fields with VPX_VM_CONFIG_INFO, update the VPX_VM table using this script:

   echo "data : $hmsVms"
   update [VIM_VCDB].[dbo].[VPX_VM]
   set MANAGED_BY_EXT_KEY=t2.MANAGED_BY_EXT_KEY, MANAGED_BY_TYPE=t2.MANAGED_BY_TYPE
   from [VIM_VCDB].[dbo].[VPX_VM] t1
   inner join [VIM_VCDB].[dbo].[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

   The output reports the number of rows affected. Compare this number with the number of rows in the output of step 4, and ensure that the numbers match.

6. Start the VMware vCenter Server service.

After resolving the database discrepancy, run this workflow to ensure that your environment functions correctly:

1. Recovery from site A to site B.
2. Re-protect site B.
3. Recovery from site B to site A.
4. Re-protect site A.

Important: Upgrading to vCenter Server 5.0 Update 2 or vCenter Server 5.1 Update 1 does not resolve the issue. vCenter Server patches will only prevent the issue going forward. Virtual machines that are currently incorrectly showing the ManagedBy SRM flag must still be corrected by following the steps in this article even after the upgrade.

Note: If you are unable to run the recovery, please file a support request with VMware Technical Support and note this Knowledge Base article ID (2032366) in the problem description. For more information, see Filing a Support Request in Customer Connect (2006985).

Additional Information

To be alerted when this document is updated, click the Subscribe to Article link in the Actions box

 

For more information, see the Microsoft TechNet article Set-Execution Policy.

 

Note: The preceding link was correct as of September 12, 2014. If you find the link is broken, provide feedback and a VMware employee will update the link.

How to file a Support Request in Customer Connect
仮想マシンが Site Recovery Manager で管理されていると報告される
虚拟机报告为受 Site Recovery Manager 管理

Impact/Risks:

• If you attempt to edit the settings of real virtual machines which are marked as placeholder virtual machines, you see a warning and the icons change, and lose the ability to distinguish between protected (real) and placeholder virtual machines.

Note: Popup is expected behavior on virtual machines created by a test failover.