Zhang Chen <zhangc...@gmail.com> writes:
> On Sat, Feb 3, 2018 at 3:49 PM, Markus Armbruster <arm...@redhat.com> wrote:
>
>> Zhang Chen <zhangc...@gmail.com> writes:
>>
>> > From: zhanghailiang <zhang.zhanghaili...@huawei.com>
>> >
>> > If some errors happen during VM's COLO FT stage, it's important to
>> > notify the users of this event. Together with 'x-colo-lost-heartbeat',
>> > Users can intervene in COLO's failover work immediately.
>> > If users don't want to get involved in COLO's failover verdict,
>> > it is still necessary to notify users that we exited COLO mode.
>> >
>> > Signed-off-by: zhanghailiang <zhang.zhanghaili...@huawei.com>
>> > Signed-off-by: Li Zhijian <lizhij...@cn.fujitsu.com>
>> > Signed-off-by: Zhang Chen <zhangc...@gmail.com>
>> > Reviewed-by: Eric Blake <ebl...@redhat.com>
>> [...]
>> > diff --git a/qapi/migration.json b/qapi/migration.json
>> > index 70e7b67..6fc95b7 100644
>> > --- a/qapi/migration.json
>> > +++ b/qapi/migration.json
>> > @@ -869,6 +869,41 @@
>> > 'data': [ 'none', 'require', 'active', 'completed', 'relaunch' ] }
>> >
>> > ##
>> > +# @COLO_EXIT:
>> > +#
>> > +# Emitted when VM finishes COLO mode due to some errors happening or
>> > +# at the request of users.
>> > +#
>> > +# @mode: which COLO mode the VM was in when it exited.
>> > +#
>> > +# @reason: describes the reason for the COLO exit.
>> > +#
>> > +# Since: 2.12
>> > +#
>> > +# Example:
>> > +#
>> > +# <- { "timestamp": {"seconds": 2032141960, "microseconds": 417172},
>> > +# "event": "COLO_EXIT", "data": {"mode": "primary", "reason":
>> > "request" } }
>> > +#
>> > +##
>> > +{ 'event': 'COLO_EXIT',
>> > + 'data': {'mode': 'COLOMode', 'reason': 'COLOExitReason' } }
>>
>> Standard question when I see a new event: is there a way to poll for the
>> event's information? If not, why don't we need one?
>>
>>
> Your means is we'd better print the information to a log file or something
> like that for all qemu events?
> CC Eric Blake <ebl...@redhat.com>
> any idea about this?
Events carrying state change information management applications want to
track are generally paired with a query- command. While the management
application is connected, it can track by passively listening for state
change events. After (re)connect, it has to actively query the current
state.
Questions?
>> Remember, management applications might miss events when they lose the
>> connection and have to reconnect, say because the management application
>> needs to be restarted.
>>
>> > +
>> > +##
>> > +# @COLOExitReason:
>> > +#
>> > +# The reason for a COLO exit
>> > +#
>> > +# @request: COLO exit is due to an external request
>> > +#
>> > +# @error: COLO exit is due to an internal error
>> > +#
>> > +# Since: 2.12
>> > +##
>> > +{ 'enum': 'COLOExitReason',
>> > + 'data': [ 'request', 'error' ] }
>> > +
>> > +##
>> > # @x-colo-lost-heartbeat:
>> > #
>> > # Tell qemu that heartbeat is lost, request it to do takeover procedures.
