[libvirt] [PATCH] qemu: Emit domain events for all virtio-serial channels

[Matt Broadstone]

On Fri, Nov 11, 2016 at 5:58 AM, Daniel P. Berrange <berrange at redhat.com> wrote:
> On Fri, Nov 11, 2016 at 11:41:42AM +0100, Peter Krempa wrote:
>> On Fri, Nov 11, 2016 at 10:33:11 +0000, Daniel Berrange wrote:
>> > On Fri, Nov 11, 2016 at 11:27:07AM +0100, Peter Krempa wrote:
>> > > On Fri, Nov 11, 2016 at 10:18:00 +0000, Daniel Berrange wrote:
>> > > > On Fri, Nov 11, 2016 at 11:13:19AM +0100, Peter Krempa wrote:
>> > > > > On Mon, Nov 07, 2016 at 15:48:35 -0500, Matt Broadstone wrote:
>> > > > > > Presently domain events are emitted for the "agent lifecycle" which
>> > > > > > is a specialization on virtio-serial events specific to the channel
>> > > > > > named "org.qemu.guest_agent.0". This patch adds a generic event for
>> > > > > > "channel lifecycles", which emit state change events for all
>> > > > > > attached channels.
>> > > > > > ---
>> > >
>> > > [...]
>>
>> > These events are not solely useful for knowing when to connect to the
>> > channel. An application which relies on the QEMU guest agent because
>> > of the libvirt API calls it makes, may wish to know when the guest
>> > agent is running, so it can avoid making libvirt APIs that use it.
>> >
>> > eg, the app can disable the ability to quiesce filesystems until it
>> > sees the event that the agent is running.
>> >
>> > So I don't really see the guest agent as so special that we must not
>> > allow these events to be seen by apps - it just creates extra work
>> > for apps to force them to pointlessly register two event callbacks.
>>
>> My point was that the guest agent may still be connected but
>> disfunctional from libvirt's point of view. The Agent lifecycle callback
>> should report this, while the channel callback should not.
>>
>> Such apps will need two callbacks anyways.
>
> It depends on what they wish to report. The QEMU guest agent is not the
> only one that is special from an app POV too - the SPICE guest agent is
> another one that apps cannot directly connect to, but which would still
> report events via the channel lifecycle event. There may be others later
> too, so I'm really not seeing a reason to special case the QEMU guest
> agent in any way.
>
> Regards,
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

I'm inclined to agree with Daniel here. Having a generic callback for
all paths here doesn't actually adversely affect anything, and is
arguably more "correct" in terms of reporting. Rather think of it this
way: this current behavior accurately models what I see when
monitoring the domstatus file.

Matt