Tonight I found myself in an unlikely situation but one I’ve been in (and got out of) before. Fortunately, past me didn’t document how he got out of it, so I had the pleasure of climbing into the rabbit hole again.
The scenario-
Zerto VPG move stuck during promoting phase. VPGs can be force removed with PowerShell but this leaves the VM in ESXi / vCenter inventory. The VM can be deleted from ESXi inventory but is then left as an orphaned VM in vCenter with remove from inventory unavailable, since the VM is still managed by the Zerto replication plugin.
The escape path involves a bit of manual DB editing. A backup / snapshot / LEEERRRROOOOYYYY is customary at this stage.
SSH to the vCSA
Enter a Bash shell
shell
Connect to the Postgres DB
/opt/vmware/vpostgres/current/bin/psql -d VCDB -U postgres
Find the orphaned VM’s ID-
SELECT id FROM vpx_vm WHERE file_name like '%VMNAME.vmx%';
Take note of this value
Remove locks on VM- (supend vm- to VM ID in above step to get vm-yourIDhere)
DELETE from vpx_disabled_methods WHERE ENTITY_MO_ID_VAL = 'vm-111';
Fun side note- the VM ID can be verified with PowerCLI-
Get-VM -Name VMNAME | Select name,ID
Exit the Postgres shell
\q
Exit the Bash shell
exit
Restart VPXD
service-control --restart vmware-vpxd
The stubborn VM can now be deleted from vCenter!
If that PowerCLI prompt is still handy, the VM can be removed like so-
Get-VM -Name VMNAME | Remove-VM
This worked like a charm!
Glad it helped, this was a tricky little number for sure!
Thanks. This helped me too.
Please update the procedure adding %% otherwise the SELECT will not find the ID
from SELECT id FROM vpx_vm WHERE file_name like ‘VMNAME.vmx’;
to SELECT id FROM vpx_vm WHERE file_name like ‘%VMNAME.vmx%’;
Glad it helped.
Well spotted on the SQL query omission, I’ve updated the article- thanks!