VM Migration Failure Which Results the VM in "ERROR" State

Problem

Post live migration of VM, the Nova API/DB shows the VM status as ERROR, although the VM continues running successfully on the target hypervisor.

Environment

• Private Cloud Director Virtualization - v2025.4 and Higher
• Self-Hosted Private Cloud Director Virtualization - v2025.4 and Higher
• Componen: Compute Service

Cause

This issue occurs due to inconsistencies between the Nova database and the actual hypervisor state during/after migration. Different underlying issues can cause this problem. Below are the common causes:

• Stale file locks on storage volumes.
• Database state mismatch between Nova conductor and compute host.
• Scheduler exceptions (e.g., NoValidHost) after migration completes.

Diagnostics

1. Stale file locks on storage volumes

• Migration fails with volume/lock errors.
• The /var/log/pf9/ostackhost.log from the source compute host:

• Confirm Cinder volume status:

2. Database state mismatch between Nova and hypervisor

• The openstack server show reports ERROR or wrong hypervisor, but VM is running on a different host.
• The /var/log/pf9/ostackhost.log from the source compute host:

• Check Nova DB entry vs actual hypervisor:

• Verify if the VM is running on the above mentioned hypervisor and its state:

3. Scheduler exceptions (e.g., NoValidHost) after migration

• Migration logs show NoValidHost, but VM still boots/migrates at the hypervisor level.
• The nova-scheduler logs :

Resolution

To restore consistency and recover the VM:

• Set the VM state to Active

• Start the VM:

Validation

• Confirm the VM is now in ACTIVE state:

• Ensure it is hosted correctly:

Additional Information

• This procedure is safe: it resets Nova’s recorded state without modifying VM disk or memory.
• Always validate using virsh command that the VM is running before resetting state.
• For frequent issues, investigate root causes in Nova conductor, scheduler, and Cinder logs.