Re: [Qemu-devel] [PATCH V4 10/16] qmp event: Add COLO_EXIT event to notify users while exited COLO

[Zhang Chen <zhangckid@gmail.com>]

On Tue, Feb 6, 2018 at 5:53 PM, Markus Armbruster <armbru@redhat.com> wrote:

> Zhang Chen <zhangckid@gmail.com> writes:
>
> > On Tue, Feb 6, 2018 at 3:27 PM, Markus Armbruster <armbru@redhat.com>
> wrote:
> >
> >> Zhang Chen <zhangckid@gmail.com> writes:
> >>
> >> > On Sat, Feb 3, 2018 at 3:49 PM, Markus Armbruster <armbru@redhat.com>
> wrote:
> >> >> 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 <eblake@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?
> >>
> >
> >
> > If I understand correctly, maybe we need a qemu events general history
> > mechanism
> > to solve this problem,
> > because lots of qemu events can't resend the current state. Yes, when the
> > "management application"(like libvirt)
> > lose the connection to qemu,  management application can't get the
> > information after reconnect.
>
> Events can't resend the current state, but query commands can.
>
> Designing of an "events general history mechanism" could well be
> non-trivial.  Its implementation might not be simple, either.  Query
> commands, on the other hand, are well understood and easy to implement.
>

OK, I got it.
I will add a new query command for COLO state in next version.
Thanks your comments.

Zhang Chen