@stormi
This is a XOA machine on Ubuntu 22.04

From this ISO, the installation went fine
I will test further...

I still wanted to understand, is there anything wrong if I reboot from inside the VM not with XOA? Although it is written that when all shutdowns and reboots are enabled, they must be performed with XOA so that the system understands (although it is strange to me, if there is a guest-tool in the system, then XCP should understand everything that happens in the VM itself) or not?
And yet, is it possible to reboot from inside the VM itself? It will just reboot, in my opinion, HA won't even have time to work here, or even if it does, it will send a command to start the machine, but it will boot anyway
I have auto-reboot on which machines in the scheduler at night, it is necessary.

@olivierlambert
I also wanted to ask just about HA and auto reboot to VM
If HA is enabled on the VM

and auto reboot is enabled in the guest system

Then nothing bad should happen? Because there will be an attempt to start the VM, but it will reboot anyway and just start

@olivierlambert
I understood everything now what the problem was. HA is not included. As I understood it in this case, the VMs would be turned off automatically and not locked, right?
The only thing of course remains the question that dave.opc asked

@Andrew
I read this) that's why I wrote about the fact that you can not enable HA on each VM, but use this function only for automatic transfer of the master
Well, okay, you've strayed from the subject, we still have another problem...

@Andrew said in can't start vm after host disconnect:

I'll have to look into HA a little more and it's issues. It's simple to turn on, but has a few complications/consequences in normal use...

And which ones, for example? Can we just not enable it in the VM settings, then we will only have the master transfer functionality? I forgot that it doesn't work if HA is turned off)
But the rest of the situation when the machines are hanging on and nothing can be done with them is it still a bug? They should just turn off.

@Andrew Your situation is even worse. When your master disappeared, did you also lose control of the pool? Although the master should be transferred to another host automatically if it is unavailable for a long time? Why is this not happening? I didn't really understand when you deleted the host on which these VMs were running from the pool, after that your VMs started on the second host?

In general, it seems that these are very serious bugs, having a fault-tolerant system scheme, we essentially lose it because of this behavior.

@Danp said in can't start vm after host disconnect:

xensource.log

If you search for this error, which is also in XOA, then here is a piece that relates to this.

@Danp So I wrote The power supply is broken. Replaced, the server is working. He appeared again in the pool and these VMs began to start normally.

In which log exactly and what should I look for with such a problem?

@Danp In XOA, we only see this when starting the VM

SR_BACKEND_FAILURE_46(, The VDI is not available [opterr=['HOST_OFFLINE', 'OpaqueRef:03e275e3-56df-477d-b940-5ba78247ce2f']], )

The situation has now been resolved. We started this server, the power supply failed. But I would like to understand the situation in order to prevent such a situation in the future, because the server might not start at all...
as I understand it, is this still abnormal behavior of the system?
Otherwise, it turns out that we have backup servers and can quickly restore VM operation on them, but we cannot do this because of this lock, which we could not just remove...