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.
