This is a follow-up to my last blog post.
In the KB, VMware states that the issue is resolved in vCenter 6.0u2 but that if you still see the issue you will need to look at the database tables.
My user informed today that the issue re-occurred after vCenter was patched over the weekend. I cracked open SQL Management Studio and tested the below queries:
|
1 2 |
select id,name from vpx_vm_config_info; select id,name from vpx_entity; |
The problem with these is that you have to manually compare the two lists. I use this query (in SQL Management Studio) to give me the VMs that have a mismatch between the two tables:
|
1 2 3 4 5 6 |
select cid, ConfigInfoName from ( select c.id as cid, c.name as ConfigInfoName, e.id as eid, e.name as EntityInfoName from vpx_vm_config_info c, vpx_entity e where c.id = e.id and c.name <> e.name ) as subquery |
This will give you the ID and the “Correct” name of the VM
The KB gives you this sample statement to update the names:
|
1 2 3 |
UPDATE VPX_ENTITY SET name = "name in vpx_vm_config_info" WHERE id = "mismatch_vm_name id"; |
I have 400 VMs to update, I didn’t want to do them one-at-a-time, so I found a statement that will update the VPX_ENTITY entries based on the corresponding vpx_vm_config_info entry if the names do not match
|
1 2 3 4 5 6 7 8 9 10 11 12 |
update vpx_entity set vpx_entity.name = vpx_vm_config_info.name from vpx_entity inner join vpx_vm_config_info on vpx_entity.id = vpx_vm_config_info.id where vpx_entity.name <> vpx_vm_config_info.name |
I bounce vCenter after this SQL so that I can see the VMs get loaded in with the expected name.