[libvirt] [PATCH] qemu: fix one reboot scenario

[Michal Privoznik]

On 07.11.2016 17:19, Michal Privoznik wrote:
> On 03.11.2016 19:11, Maxim Nestratov wrote:
>> Both qemuDomainReboot and qemuDomainShutdownFlags do the following if
>> they were called to reboot:
>> 1. use agent and call qemuAgentShutdown
>> 2. then if the above function doesn't succeed, try qemuMonitorSystemPowerdown
>>
>> When the first step is called, it resets fakeReboot flag, while the second one,
>> opposite to that, sets it. Thus, in case we tried to use agent to reboot a
>> guest and failed for some reason, we end up with fakeReboot flag set. After that,
>> as qemuMonitorSystemPowerdown function was called, libvirt is notified with POWERDOWN.
>> The problem is that there is no callback routine set for it. The lack of monitor event
>> reaction leads to incorrect logic and guest doesn't restart or reboot correctly.
>> The patch simply sets domainPowerdown monitor callback to qemuProcessHandleShutdown as
>> powerdown event processing is actually equal to shutdown.
>>
>> Signed-off-by: Maxim Nestratov <mnestratov at virtuozzo.com>
>> ---
>>  src/qemu/qemu_process.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
>> index 04b25fe..0de9fa5 100644
>> --- a/src/qemu/qemu_process.c
>> +++ b/src/qemu/qemu_process.c
>> @@ -1630,6 +1630,7 @@ static qemuMonitorCallbacks monitorCallbacks = {
>>      .diskSecretLookup = qemuProcessFindVolumeQcowPassphrase,
>>      .domainEvent = qemuProcessHandleEvent,
>>      .domainShutdown = qemuProcessHandleShutdown,
>> +    .domainPowerdown = qemuProcessHandleShutdown,
>>      .domainStop = qemuProcessHandleStop,
>>      .domainResume = qemuProcessHandleResume,
>>      .domainReset = qemuProcessHandleReset,
>>
> 
> Huh, this event was never ever handled. How did we even manage that?

Oh, now looking into the qemu code, maybe we don't want this to be
handled after all. POWERDOWN event is emitted on ACPI powerdown event,
which means that guest is still running and hence we don't want to
mangle our internal state (i.e. set it to SHUTDOWN).

> 
> ACK

I'm sorry, but I have to discard my own ACK. We need a different fix for
the scenario you're seeing.

Michal