Error: "The virtual machine is not configured for replication" due to unresponsive hbrsrv service and backend file locks

Products

• VMware vSphere ESXi

Issue/Introduction

• Replication tasks for multiple virtual machines are hanging or stuck (typically at 20%).
• Unable to remove protection for VMs with the error: "The virtual machine is not configured for replication."
• Manual deletion of target VM folders fails due to file locks.
• Site Recovery UI may report an HTTP 500 Internal Server Error when retrieving remote site data.
• Error in hbrsrv.log: Database file doesn't exist while performing distdb route.

• From the logs located in the /var/log/hbrsrv.log

  2026-06-29T19:02:43.495Z In(166) hbrsrv[45206494] [Originator@6876 sub=Main groupID=GID-[UUID_2] opID=[UUID_4]-HMSINT-5545] [1] While performing distdb route for path '/vmfs/volumes/[UUID_3]/VM_name/groupdb.db'
  2026-06-29T19:02:43.495Z In(166) hbrsrv[45206494] [Originator@6876 sub=Main groupID=GID-[UUID_2] opID=[UUID_4]-HMSINT-5545] [2] Ignored error.
  2026-06-29T19:06:38.477Z Wa(164) hbrsrv[45206549] [Originator@6876 sub=Main groupID=GID-[UUID_2] opID=[UUID_1]-HMSINT-125] HbrError for (groupId: "GID-[UUID_2]") stack:
  2026-06-29T19:06:38.477Z In(166) hbrsrv[45206549] [Originator@6876 sub=Main groupID=GID-[UUID_2] opID=[UUID_1]-HMSINT-125] [0] Database file doesn't exist.
  2026-06-29T19:06:38.477Z In(166) hbrsrv[45206549] [Originator@6876 sub=Main groupID=GID-[UUID_2] opID=[UUID_1]-HMSINT-125] [1] While performing distdb route for path '/vmfs/volumes/[UUID_3]/VM_name/groupdb.db'
  2026-06-29T19:06:38.478Z In(166) hbrsrv[45206549] [Originator@6876 sub=Main groupID=GID-[UUID_2] opID=[UUID_1]-HMSINT-125] [2] Ignored error.

Environment

vSphere Replication 9.x

Cause

1. Unresponsive Replication Service: The Host-Based Replication service (hbrsrv) on the target ESXi host has become unresponsive. While the service may appear to be running, it maintains active file locks on the backend datastores, preventing cleanup or reconfiguration tasks.
2. Stale Lookup Service Registrations: Residual entries in the vCenter Lookup Service from legacy or inactive SRM appliances can conflict with current sessions, leading to UI communication failures (HTTP 500).
3. Task Deadlocks: Stale task threads in the vCenter Server vpxd service can prevent the UI from accurately reflecting the current replication state.

Resolution

Step 1: Release Backend File Locks on Target Host

Connect to the target ESXi host via SSH and restart the replication management service.

Try a graceful restart:

/etc/init.d/hbrsrv restart

If the restart command hangs or times out, force-stop and start the service:

/etc/init.d/hbrsrv stop

/etc/init.d/hbrsrv start

Step 2: Clear Stale vCenter Tasks

Restart the vCenter Server vpxd service to clear any orphaned tasks or threads associated with the hanging replication jobs.

Connect to the vCenter Server Appliance (VCSA) via SSH.

Restart the service:

service-control --restart vpxd

Step 3: Cleanup Stale Configurations via CLI

If the VM still shows as protected in the UI but cannot be managed, use the ESXi command line on the source host to force-disable replication.

Identify the VMID of the affected virtual machine:

vim-cmd vmsvc/getallvms

Check the replication state:

vim-cmd hbrsvc/vmreplica.getState <VMID>

Force-disable the replication config:

vim-cmd hbrsvc/vmreplica.disable <VMID>

Step 4: Resolve UI HTTP 500 Errors

If the UI issues persist:

Power off any inactive legacy SRM appliances.

Use the vCenter Managed Object Browser (MOB) at https://<vcenter_fqdn>/lookupservice/mob to unregister stale service endpoints for legacy SRM/vSphere Replication appliances.