[Qemu-devel] QMP event on reboot when -no-reboot is set

[Qemu-devel] QMP event on reboot when -no-reboot is set

[Dirk Braunschweiger]

Hey Guys,

I want to get a qmp event when the qemu does a shutdown due to the 
-no-reboot flag. Looking at the code I realized that the -no-reboot flag 
just changes any reset request to a shutdown request.
Does anybody already patched qemu to emit some kind of reboot event to 
the qmp socket?

If no one already patched it, would you accept such a patch? Or is a 
non-wanted feature?

Best regards,
Dirk Braunschweiger

Re: [Qemu-devel] QMP event on reboot when -no-reboot is set

[John Snow]

On 11/16/2016 09:01 AM, Dirk Braunschweiger wrote:
> Hey Guys,
>
> I want to get a qmp event when the qemu does a shutdown due to the
> -no-reboot flag. Looking at the code I realized that the -no-reboot flag
> just changes any reset request to a shutdown request.
> Does anybody already patched qemu to emit some kind of reboot event to
> the qmp socket?
>
> If no one already patched it, would you accept such a patch? Or is a
> non-wanted feature?
>
> Best regards,
> Dirk Braunschweiger
>

Is the existing "STOP" event insufficient for some reason? Is it 
important to distinguish between a 'real' stop and a stop that was 
originally intended to be a reboot?

If you can elaborate on that case, you have a good chance of amending 
the event spec to add some new events.

--js

Re: [Qemu-devel] QMP event on reboot when -no-reboot is set

[Dirk Braunschweiger]

On 2016-11-16 17:29, John Snow wrote:
> On 11/16/2016 09:01 AM, Dirk Braunschweiger wrote:
>> Hey Guys,
>> 
>> I want to get a qmp event when the qemu does a shutdown due to the
>> -no-reboot flag. Looking at the code I realized that the -no-reboot 
>> flag
>> just changes any reset request to a shutdown request.
>> Does anybody already patched qemu to emit some kind of reboot event to
>> the qmp socket?
>> 
>> If no one already patched it, would you accept such a patch? Or is a
>> non-wanted feature?
>> 
>> Best regards,
>> Dirk Braunschweiger
>> 
> 
> Is the existing "STOP" event insufficient for some reason? Is it
> important to distinguish between a 'real' stop and a stop that was
> originally intended to be a reboot?
> 
> If you can elaborate on that case, you have a good chance of amending
> the event spec to add some new events.
> 
> --js


Hi John,

the stop event is not sufficient. I want to restart the VM if the guest 
initiates a reboot. The user of the VM expects that the VM is startet 
again after he/she clicks on reboot ;)
I want to use the --no-reboot flag to stop qemu and restart it on 
another vm host or to start it with another configuration (more/less 
RAM/CPU, a bigger HDD, etc...)

Best regards,
Dirk

Re: [Qemu-devel] QMP event on reboot when -no-reboot is set

[John Snow]

On 11/17/2016 03:17 AM, Dirk Braunschweiger wrote:
> On 2016-11-16 17:29, John Snow wrote:
>> On 11/16/2016 09:01 AM, Dirk Braunschweiger wrote:
>>> Hey Guys,
>>>
>>> I want to get a qmp event when the qemu does a shutdown due to the
>>> -no-reboot flag. Looking at the code I realized that the -no-reboot flag
>>> just changes any reset request to a shutdown request.
>>> Does anybody already patched qemu to emit some kind of reboot event to
>>> the qmp socket?
>>>
>>> If no one already patched it, would you accept such a patch? Or is a
>>> non-wanted feature?
>>>
>>> Best regards,
>>> Dirk Braunschweiger
>>>
>>
>> Is the existing "STOP" event insufficient for some reason? Is it
>> important to distinguish between a 'real' stop and a stop that was
>> originally intended to be a reboot?
>>
>> If you can elaborate on that case, you have a good chance of amending
>> the event spec to add some new events.
>>
>> --js
>
>
> Hi John,
>
> the stop event is not sufficient. I want to restart the VM if the guest
> initiates a reboot. The user of the VM expects that the VM is startet
> again after he/she clicks on reboot ;)
> I want to use the --no-reboot flag to stop qemu and restart it on
> another vm host or to start it with another configuration (more/less
> RAM/CPU, a bigger HDD, etc...)
>
> Best regards,
> Dirk
>

Is there also a reason why live migrating the VM is undesirable and you 
want to wait for a perceived more opportune moment?

Regardless;

what you might consider doing is amending the "STOP" event to include a 
new optional parameter, like "reason" or so that can include some extra 
information about why a VM was stopped.

One of those reasons can be an intercepted --no-reboot event; maybe 
REASON=INTERCEPTED_REBOOT as a suggestion.

--js