[ovirt-users] oVirt 4.0.3 (Hosted Engine) - High Availability VM not restart after auto-fencing of host.

[Gianluca Cecchi]

On Fri, Sep 16, 2016 at 3:13 PM, Michal Skrivanek <
michal.skrivanek at redhat.com> wrote:

>
> On 16 Sep 2016, at 15:05, Gianluca Cecchi <gianluca.cecchi at gmail.com>
> wrote:
>
> On Fri, Sep 16, 2016 at 2:50 PM, Michal Skrivanek <
> michal.skrivanek at redhat.com> wrote:
>
>>
>> no, that’s not how HA works today. When you log into a guest and issue
>> “shutdown” we do not restart the VM under your hands. We can argue how it
>> should or may work, but this is the defined behavior since the dawn of
>> oVirt.
>>
>>
>> ​AFAIK that's correct, we need to be able ​
>> ​shutdown HA VM​
>> ​
>> ​ without being it immediately restarted on different host. We want to
>> restart HA VM only if host, where HA VM is running, is non-responsive.
>>
>>
>> we try to restart it in all other cases other than user initiated
>> shutdown, e.g. a QEMU process crash on an otherwise-healthy host
>>
>>
> Hi, just another question in case HA is not configured at all.
>
>
> by “HA configured” I expect you’re referring to the “Highly Available”
> checkbox in Edit VM dialog.
>

Yes


>
> If I run the "shutdown -h now" command on an host where some VMs are
> running, what is the expected behavior?
> Clean VM shutdown (with or without timeout in case it doesn't complete?)
> or crash of their related QEMU processes?
>
>
> expectation is that you won’t do that. That’s why there is the Maintenance
> host state.
> But if you do that regardless, with VMs running, all the processes will be
> terminated in a regular system way, i.e. all QEMU processes get SIGTERM.
> From the perspective of each guest this is not a clean shutdown and it
> would just get killed
>
>
Yes, I was thinking about the scenario of one guy issuing the command (or
pressing the button) by mistake.
Thanks,
Gianluca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20160916/b63da31e/attachment-0001.html>