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

[Daniel P. Berrange]

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.
> > > > ---
> 
> [...]
> 
> > > I don't think we should emit this event for the guest agent channel. It
> > > has a separate one and the channel is reserved for libvirt anyways, so
> > > client applications should use the guest agent event for this.
> > 
> > I don't really agree with that. I don't see any compelling reason
> > to special case the guest agent channel - it just creates extra
> > work for client apps who want to see events for all channels. There
> > is no harm in having the guest agent trigger both events, the old
> > special case one, and the new general purpose one.
> 
> My reasoning is that the clients are not supposed to connect to the
> channel where the guest agent communicates and thus should not receive
> any events using this event type.
> 
> The guest agent event is designed so that it can report errors of the
> guest agent (e.g. reporting invalid reply, timeout etc.) whereas this
> does not apply to regular channels where libvirt does not care at all
> what the state of the guest application is or which protocol they talk.
> 
> The way libvirt uses the guest agent channel makes it special from point
> of view of other apps, since libvirt always hogs it and apps are
> supposed to use libvirt api. This does not apply to generic channels.
> (E.g, spice channels are special in the very same way).

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.


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/ :|