Search the VMware Knowledge Base (KB)
View by Article ID

VMs are reported as managed by Site Recovery Manager (2032366)

  • 28 Ratings
Language Editions

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.

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 My VMware (2006985).

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.

Additional Information

To be alerted when this article is updated, click Subscribe to Document 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.

See Also

Update History

10/17/2012 - Added note to resolution 4/26/2013 - Added resolved by vCenter Server 5.1U1 and vCenter Server 5.0U2 11/27/2014 - Added SRM 5.1 to Products

Language Editions

ja,2102385;zh_cn,2150477

Attachments

Request a Product Feature

To request a new product feature or to provide feedback on a VMware product, please visit the Request a Product Feature page.

Feedback

  • 28 Ratings

Did this article help you?
This article resolved my issue.
This article did not resolve my issue.
This article helped but additional information was required to resolve my issue.

What can we do to improve this information? (4000 or fewer characters)




Please enter the Captcha code before clicking Submit.
  • 28 Ratings
Actions
KB: