can't start vm after host disconnect
-
Correct, NO master = NO pool management (the VMs keep running).
- If HA is enabled, another master is elected automatically.
- If HA is not enabled, each member waits for the master to return.
I deleted the dead host (old master) because cause even when I marked it as dead (from the new master) the VMs from it would not restart and the backups were still trying to communicate with it. Deleting it from the pool seemed the only way, or at least the quickest, to restore functionality.
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...
-
@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. -
@alex821982 Here are the HA docs.
-
You need to think about data coherency. As a human, you know that your server was physically dead (PSU dead). But from XAPI perspective, what if it was just the management network dead? The VM will continue to run correctly, but there's no way for XAPI to know it. So if you decide to boot the VM again, maybe it will corrupt the data (having the VM run at 2 places with the same disk: catastrophic corruption).
That's why, by default, it prevented you to start the VM because it couldn't contact the host that might have still the VM running, leading to catastrophic corruption.
In HA, there's an extra mechanism (storage heartbeat), helping to make a better decision (at the cost of auto fencing host that couldn't join the HA SR).
-
@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... -
@olivierlambert
what about when system doesn't know that host if offline, but i know for sure that host is down, and i need manual control over starting/copying vm.
why then in those command exists --force, if it's not helping in anyway? -
@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 -
@olivierlambert
I also wanted to ask just about HA and auto reboot to VM
If HA is enabled on the VMand 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
-
If HA is enabled, then the pool should elect a new master (if it's the master), and restart all the VMs.
But be careful with HA: if your SR access is blocked (eg a network issue on your SR), all the host will auto fence and reboot.
-
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. -
Can you be more specific about what do you expect in terms of behavior?
-
@olivierlambert
with HA enabled, if Windows VM will reboot from windows system scheduler - is this ok? Will this affect somehow on VM? -
No, from the XCP-ng point of view, the VM is still running without any interruption.
