vCenter Server services fail to start due to stale VM entries in the database
search cancel

vCenter Server services fail to start due to stale VM entries in the database

book

Article ID: 427895

calendar_today

Updated On:

Products

VMware vCenter Server

Issue/Introduction

When attempting to start the VMware vCenter Server Appliance (VCSA) services, the vpxd service fails to initialize or hangs during the startup sequence. Users are unable to access the vSphere Client.
Upon reviewing the vpxd.log (located at /var/log/vmware/vpxd/vpxd.log), you may see the initialization process stop immediately after loading inventory fields:
vpxdInvtvm::load LoadFieldsFromDb() ] took 29 ms.
This behavior typically occurs when the database contains references to orphaned virtual machines that were hosted on an ESXi host that has since been decommissioned

Environment

Product: VMware vCenter Server
Versions: 8.x

Cause

Stale entries for  virtual machines remain in the VPX_ENTITY and VPX_VM tables despite the physical host no longer exists. During the vpxd startup, the service attempts to map these orphaned IDs to compute resources; when the mapping fails to find the parent host, the service initialization terminates or hangs.

Resolution

To resolve this issue, you must manually remove the orphaned VM entries from the vCenter Database.

Backup vCenter: Take a file-based backup or an offline snapshot of the vCenter Server Appliance before proceeding.


SSH to vCenter: Log in to the VCSA via SSH using the root account.


Stop the vpxd service

service-control --stop vpxd


Access the Database:

/opt/vmware/vpostgres/current/bin/psql -d VCDB -U postgres

Identify the Orphaned VM ID:
Run the following query to find the ID of the orphaned virtual machine

select * from VPX_VM m where not exists (select 1 from VPX_HOST h where m.HOST_ID = h.ID
Note the ID of the orphaned entry (e.g., ID 9).

Delete Records:
Execute the following commands in order, replacing 9 with your specific VM ID identified in Step 5. You must follow this order to satisfy database constraints:

delete from VPX_COMPUTE_RESOURCE_DAS_VM where VM_ID=9;
delete from VPX_COMPUTE_RESOURCE_DRS_VM where VM_ID=9;
delete from VPX_COMPUTE_RESOURCE_ORC_VM where VM_ID=9;
delete from VPX_VM_SGXINFO where VM_ID=9;
delete from VPX_GUEST_DISK where VM_ID=9;
delete from VPX_VM_VIRTUAL_DEVICE where ID=9;
delete from VPX_VM_DS_SPACE where VM_ID=9;
delete from VPX_NON_ORM_VM_CONFIG_INFO where ID=9;
delete from VPX_NORM_VM_FLE_FILE_INFO where VM_ID=9;
delete from VPX_VDEVICE_BACKING_REL where VM_ID=9;
delete from VPX_VIRTUAL_DISK_IOFILTERS where VM_ID=9;
delete from VPX_VM_STATIC_OVERHEAD_MAP where VM_ID=9;
delete from VPX_VM_TEXT where VM_ID=9;
delete from VPX_VM where ID=9;
delete from VPX_ENTITY where ID=9;

Exit and Restart:
\q to exit the database, then start the services:

service-control --start vpxd

Additional Information

This is a manual database intervention. In most scenarios, ensuring hosts are placed in Maintenance Mode and the cluster is healthy before decommissioning can prevent orphaned vCLS entries. If the service still fails to start, verify that all dependent services (such as vmdir and vapi-endpoint) are also running