On Tue, Feb 6, 2018 at 5:53 PM, Markus Armbruster <arm...@redhat.com> wrote:
> Zhang Chen <zhangc...@gmail.com> writes: > > > On Tue, Feb 6, 2018 at 3:27 PM, Markus Armbruster <arm...@redhat.com> > wrote: > > > >> Zhang Chen <zhangc...@gmail.com> writes: > >> > >> > On Sat, Feb 3, 2018 at 3:49 PM, Markus Armbruster <arm...@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 <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? > >> > > > > > > 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
