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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]