Today I worked with a customer who have vms reported with SRM icon and as power ON state (), this appear after he tried to edit the VMs setting for any active VMs in the Primary site and that is part of the Recovery Plan.
The customer environment was pretty straight forward, storage base replication with a Compellent, multiple PG and RP.
When we tried to edit the configuration also we got the following message:
Solution Site Recovery Manager manages the selected virtual machine. You should not modify the virtual machine directly. Use the management console of the solution to make changes. Proceed with the operation?
Well this may be a spected behavior if he is trying to make change to vms on the DR site, but this was not the case.
In the review we found on the vmware site the article 2032366 with point to the related/same error https://kb.vmware.com/s/article/2032366
Here are my lesson learned trying to apply this article:
You must apply all the 2 step to fix the issue, if you only apply just the first one using the PowerCli you will get the same error at the next time you tried to edit any VMs settings that may have mismatch of configuration.
If you have already run the clean script and you tried to run it again you will get a not signed error and will not run, in this case I re-download the script (2032366_ManagedBy_power cli script.zip) and run it in other location, after this you will see the correct state on the vCenter interface, but you will need to continue with the database manual clean up. (Remember to have a backup of the DataBase before any changes and stop the vcenter services)
Since this VMware KB was not updated, the Data base example used its for a SQL one and not for a vPostgress. Thanks to Sean Whitney post (http://www.virtually-limitless.com/vsphere-6-0/interacting-with-the-vpostgres-database-in-vsphere-6-0/) I was able to connect to the DataBase, now the next challenge was how…
So after couple of hour trying to run the database script we end of the following scripts respectively to the one on the article:
1. This script finds virtual manchie IDs whose manager_by_ext_key and manage_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;
2. To obtain the number of affected virtual machines to cross-check against the output in step 3, 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;
3. 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;
Restart the vcenter and wala! Everything is working and we were able to manage the solution with out the pop pop and changes vms setting without any cosmetic issue.
Hope this information its useful.