When a host goes down, the VM does not start on another host.

[kurotan]

In the cluster settings, "Automatically power on vms" is enabled. In "Managemnt Placement" for each VM, "Auto" or "Failover" is set. The storage for each VM is set to NFS storage.

For the NFS storage, "Heatbeat target" is enabled. I thought that with the above settings, if the host on which the VM was running stopped, it would start on another host.

However, although the VM seemed to move to another host, it did not start. What is the cause?

By the way,I ran

virsh dominfo <vm name> and it said "Autostart" was disabled. Is this correct?

[Ranveer]

Hello Kurton,

I understood that this issue you resolved via below thread or is it different?
https://community.hpe.com/t5/hpe-morpheus-vm-essentials/after-host-goes-down-vm-does-not-start-automatically/m-p/7244501

[kurotan]

No, that's not the case.

The thread you refer to is a problem that occurred when the state of this thread was reached.

Note that if you reboot the hypervisor host (ubuntu) with the reboot command, the VMs that were running on that host would start on another host.

The problem in this thread occurred when the hypervisor host was forced to stop by pressing and holding the power button.

If my settings are correct, it seems that 8.06 has been released, so I would like to rebuild my environment and try again.

I would like any comments on whether my settings are correct.

[kurotan]

When I try to start the VM manually I get the following message:

virsh # start CentOS9-XCP01
error: Failed to start domain 'CentOS9-XCP01'
error: internal error: process exited while connecting to monitor: 2025-06-13T02:39:56.816448Z qemu-system-x86_64: -blockdev {"no
de-name":"libvirt-1-format","read-only":false,"discard":"unmap","cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":
"libvirt-1-storage","backing":null}: Failed to get "write" lock
Is another process using the image [/mnt/f9a16a99-546e-4697-aba2-dfa57be1674a/CentOS9-XCP01/hpevm_14-disk-0]?

[mnavada]

Hello Kurton,

This usually happens due to one of the following:

1. The VM is already running, but in a hung or invisible state

2. A stale QEMU process or libvirt lock is holding onto the image

3. A file descriptor was not released properly due to an unclean shutdown

4. Filesystem or NFS storage backend issues (less common in GFS2 setups)

Resolution Steps
1. Check if VM is Already Running

#virsh list --all
#ps aux | grep qemu
If found, kill the related QEMU process:

kill -9 <PID>

2. Check for Active Locks on the Disk File

lsof /mnt/f9a16a99-546e-4697-aba2-dfa57be1674a/CentOS9-XCP01/hpevm_14-disk-0
or

fuser /mnt/f9a16a99-546e-4697-aba2-dfa57be1674a/CentOS9-XCP01/hpevm_14-disk-0

If a process is holding the file, confirm what it is and terminate if appropriate.

3. Check for Libvirt Locks
Libvirt may use a lock manager. Check:

ls -l /var/lock/libvirt
You can safely delete stale locks if you're sure the VM is not running.

4. Force Cleanup of the VM (libvirt)
If everything else fails:

virsh destroy CentOS9-XCP01
virsh undefine CentOS9-XCP01
# Recreate the VM definition if needed using Morpheus GUI

## If still issues exists or if this solution didn't help, please email to "hpe-sw-trial-vmessentials@hpe.com" with detailed information and let us know your "availability" time to take remote session via MS-Team to assist you.