qemu-devel
[Top][All Lists]
Advanced

[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


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH V4 10/16] qmp event: Add COLO_EXIT event to notify users while exited COLO
Date: Tue, 06 Feb 2018 10:53:11 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Zhang Chen <address@hidden> writes:

> On Tue, Feb 6, 2018 at 3:27 PM, Markus Armbruster <address@hidden> wrote:
>
>> Zhang Chen <address@hidden> writes:
>>
>> > On Sat, Feb 3, 2018 at 3:49 PM, Markus Armbruster <address@hidden> 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 <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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]