Re: [Qemu-stable] [PATCH] vl: allow "cont" from panicked state

[Paolo Bonzini]

Il 21/08/2013 17:23, Eric Blake ha scritto:
>> Upon learning of a panic, management (if configured to do so) can pick a
>> variety of behaviors: leave the VM paused, reset it, destroy it.  In
>> addition to all of these behaviors, it is possible dumping the VM core
>> from the host.
> 
> s/possible dumping/possible to dump/
> 
> and yes, libvirt wants to do just that, as one of its <on_crash>
> mappings, since it could do the same for Xen.
> 
>>
>> However, right now, the panicked state is irreversible, and can only be
>> exited by resetting the machine.  This means that any policy decision
>> is entirely in the hands of the host.  In particular there is no way to
>> use the "reboot on panic" option together with pvpanic.
>>
>> This patch makes the panicked state reversible (and removes various
>> workarounds that were there because of the state being irreversible).
>> With this change, management has a wider set of possible policies: it
>> can just log the crash and leave policy to the guest, it can leave the
>> VM paused.  In particular, the "log the crash and continue" is implemented
>> simply by sending a "cont" as soon as management learns about the panic.
>> Management could also implement the "irreversible paused state" itself.
>> And again, all such actions can be coupled with dumping the VM core.
> 
> Yes, this makes sense.
> 
>>
>> Unfortunately we cannot change the behavior of 1.6.0.  Thus, even if
>> it uses "-device pvpanic", management should check for "cont" failures.
>> If "cont" fails, management can then log that the VM remained paused
>> and urge the administrator to update QEMU.
> 
> Is that the best we can do?  Is there any sort of QMP introspection that
> libvirt can do, where we can know UP FRONT what level of panic support
> is provided by the qemu binary and the machine type being run in that
> binary?

No, this is not possible unfortunately.  The only possibility that comes
to mind would be to rename the pvpanic device, e.g. to "isa-pvpanic",
and forget about "-device pvpanic" on 1.6.x.  A hack, I know.

To support 1.5, libvirt should simply be ready to react to unanticipated
GUEST_PANICKED events.  reboot-on-panic will simply be broken for 1.5
and Linux 3.10+ guests. :(

>> +++ b/vl.c
>> @@ -637,9 +637,8 @@ static const RunStateTransition 
>> runstate_transitions_def[] = {
>>      { RUN_STATE_WATCHDOG, RUN_STATE_RUNNING },
>>      { RUN_STATE_WATCHDOG, RUN_STATE_FINISH_MIGRATE },
>>  
>> -    { RUN_STATE_GUEST_PANICKED, RUN_STATE_PAUSED },
>> +    { RUN_STATE_GUEST_PANICKED, RUN_STATE_RUNNING },
> 
> Is 'cont' the only viable way to escape PANICKED, or is it also
> reasonable to support 'stop' as a way to transition from PANICKED to
> PAUSED?  That is, management may want to make the state reversible but
> still leave the guest paused, so this patch may be incomplete.

No, there is no way to move from PANICKED to PAUSED.  Libvirt has its
own statuses (PAUSED, CRASHED etc.) and substatuses.  You don't really
care about the QEMU state: both the PAUSED_PANICKED and CRASHED_PANICKED
substatuses map to QEMU's GUEST_PANICKED state.  Simply, libvirt will
not allow a "virsh resume" for <on_crash>preserve</on_crash>, and will
allow it for a hypothetical new <on_crash>pause</on_crash> element.

BTW, any chance "coredump-destroy" and "coredump-restart" can be
preserved just for backwards compatibility, and a new coredump='yes/no'
attribute introduced instead?  Because coredump-pause and
coredump-preserve would make just as much sense.