[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH V4 10/16] qmp event: Add COLO_EXIT event to noti
Re: [Qemu-devel] [PATCH V4 10/16] qmp event: Add COLO_EXIT event to notify users while exited COLO
Tue, 6 Feb 2018 20:44:41 +0800
On Tue, Feb 6, 2018 at 5:53 PM, Markus Armbruster <address@hidden> wrote:
> Zhang Chen <address@hidden> writes:
> > On Tue, Feb 6, 2018 at 3:27 PM, Markus Armbruster <address@hidden>
> >> Zhang Chen <address@hidden> writes:
> >> > On Sat, Feb 3, 2018 at 3:49 PM, Markus Armbruster <address@hidden>
> >> >> Standard question when I see a new event: is there a way to poll for
> >> >> 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
> >> > like that for all qemu events?
> >> > CC Eric Blake <address@hidden>
> >> > 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.