VM Fails to Start After Flavor Resize

Problem

After successfully resizing the flavor of the VM, it is unable to start.

Environment

• Private Cloud Director Virtualization - v2025.4 and Higher

• Self-Hosted Private Cloud Director Virtualization - v2025.4 and Higher

• Component: Compute Service

Cause

There is a transient desynchronization between the Compute service and the hypervisor, where the instance state in the database did not match the actual state on the compute node.

Diagnostics

1. Verify if the reported VM is present in the libvirt database on the compute host.

Host

$ sudo virsh list --all | grep <VM_UUID>

1. Review the /var/log/pf9/ostackhost.logs over the compute host for the impacted VM. It complains around the soft reboot of the VM after successful flavor resize, has not completely deleted the older allocations [from the old flavor].

/var/log/pf9/ostackhost.logs

INFO nova.compute.manager [[REQUEST_ID] [USER_NAME] service] [instance: [INSTANCE_ID]] Deleting allocations for old flavor on source node [COMPUTE_ID] after finish_resize failure. You may be able to recover the instance by hard rebooting it. 

1. The ostackhost.log also points to a mismatch in the instance count and intermittent "Instance not found” messages.

/var/log/pf9/ostackhost.logs

WARNING nova.compute.manager: While synchronizing instance power states, found 3 instances in the database and 2 instances on the hypervisor.
WARNING nova.compute.manager [instance: [INSTANCE_ID]]: Instance is unexpectedly not found. Ignore.

Resolution

• Perform a HARD REBOOT of the affected VM to force a resynchronization between Nova and the hypervisor, which will bring the VM back to a healthy state.

Validation

• Confirm the VM is now in ACTIVE state:

$ openstack server show -c status <VM_ID> 

• Ensure it is hosted correctly:

$ openstack server show -c OS-EXT-SRV-ATTR:hypervisor_hostname <VM_UUID>

• Ensure the VM is present in the active libvirt domains on the hypervisor.

Host

$ sudo virsh list --all | grep <VM_UUID>